Re: [Xen-devel] [edk2] [PATCH RFC v2 3/7] OvmfPkg: define EFI_XEN_OVMF_INFO and extend XenInfo

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2013-11-25 at 12:00 -0800, Jordan Justen wrote:
> >> > +  UINT32 TablesNr;
> >>
> >> Could this be TableCount?
> >>
> >> Is "Tables" unused in this patch series? The purpose doesn't seem
> >> clear. (Perhaps an updated comment or commit message could help?)
> >>
> >
> > No, not yet. We need to reserve places for future usage though.
> > Otherwise we need to break this interface when we find out we need to
> > pass more information.

FWIW in the SeaBIOS world we pass a number of self describing BIOS
tables here. (specifically RSDP, MP table, PIR and the SMBIOS EP).

> What about when the next blob type needs to be transferred?

When I put the SeaBIOS version together my intention was that the length
field would serve as a proxy for the struct version should we ever need
to extend it.

>  How about
> something that E820 can fit into, and yet allow for more new blobs to
> be passed?
> 
> How about something like:
> #define XEN_HVM_INFO_SIGNATURE SIGNATURE_32 ('X', 'E', 'N', 'H')
> #define XEN_HVM_INFO_ADDRESS BASE_4KB
> #define XEN_HVM_INFO_VERSION 0
> 
> #define XEN_HVM_DATA_TYPE_E820 SIGNATURE_32 ('E', '8', '2', '0')
[...]

From the Xen side unless there is some strong reason to deviate I would
prefer to stick with something which is similar to the existing
interface to other BIOSes, which is what Wei has proposed, rather than
reinvent it in a per-BIOS way. Ultimately this stuff won't be exposed to
UEFI outside of the Xen support code.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel