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.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home