On Mon, 2011-05-30 at 15:43 +0100, Kevin O'Connor wrote:
> On Fri, May 27, 2011 at 10:27:14AM +0100, Ian Campbell wrote:
> > On Fri, 2011-05-27 at 02:20 +0100, Kevin O'Connor wrote:
> > > 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?)
>
> Yes - 0x510/0x511.
>
> [...]
> > 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.
>
> At some point, Xen will likely need "romfile" support (see
> src/paravirt.h) in order to support pulling in non-device option roms
What sorts of things live in those?
> and things like "bootorder" support. The "romfile" stuff just uses a
> list of ("name", size, data) 3-tuples to pass in arbitrary data to
> SeaBIOS. You may wish to consider supporting an interface like that
> from the start.
The datastructure I'm proposing above would only be used to propagate
information hvmloader itself has created (BIOS tables) through to
SeaBios. hvmloader doesn't have any insight into things like bootorder
etc so it wouldn't be able to create tables of that type.
The other stuff sounds like the sort of thing Xen would normally
communicate from the toolstack to the guest using xenstore, unless the
payloads are huge? The fw_cfg remains an option for this sort of data
too, if that turns out to make sense.
I'll be posting the next version of the patch shortly.
Thanks,
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home