On Fri, 2011-05-27 at 02:20 +0100, Kevin O'Connor wrote:
On Thu, May 26, 2011 at 04:13:37PM +0100, Ian Campbell wrote:
On Tue, 2011-05-24 at 22:44 -0400, Kevin O'Connor wrote:
On Tue, May 24, 2011 at 12:02:07PM +0100, Ian Campbell wrote:
Would that involve pulling a bunch of mainboard specific stuff from coreboot into SeaBIOS?
The idea - when it was last raised - was to provide raw info in a coreboot specific manor (via the "coreboot tables"), and then have SeaBIOS populate ACPI/SMBIOS/MPTable/etc. from that info. It was never pursued.
Speaking of coreboot tables... I also need to pass some start of day info into seabios (ACPI tables, e820 etc). Currently I just used a little ad-hoc data structure at a known physical address but I wonder if perhaps I should/could reuse the coreboot table datastructures? They are existing and well defined and I suppose they are pretty static, but I don't want to add any additional compatibility burden if you guys would rather avoid it.
Will Xen support the fw_cfg interface?
I don't think so, at least not in general. (fw_cfg is the qemu thing on ports 0x510/511, right?)
I don't think the qemu instance in a Xen domain has all the info it would need in order to provide the tables.
Another thing to consider would be if coreboot+SeaBIOS in place of hvmloader would be a fit. (I don't have a good feel for what hvmloader does to judge that.)
I think hvmloader contains a subset of coreboot's functionality. I've wondered about possibly using coreboot in the future, but I think that would be a separate project.
Using the coreboot tables in Xen seems a bit odd, but I can't say it would cause a problem.
The existing ad-hoc structure I've defined is: struct xen_seabios_info { char signature[14]; /* XenHVMSeaBIOS\0 */ u16 length; u32 acpi_rsdp; u32 mptable; u32 e820_nr; struct e820entry e820[128]; u8 checksum; }; so I was mainly thinking of e.g. CB_TAG_MEMORY along with CB_MEM_TABLE.
I think I'll stick with defining a structure myself, these things are all discoverable via signatures so we can always transition in the future.
Ian.