[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [SeaBIOS] [Xen-devel] Re: [RFC] [PATCH 0/2] Basic SeaBIOS support for Xen HVM

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


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.