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

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.

On Tue, Nov 26, 2013 at 2:16 AM, Ian Campbell <Ian.Campbell@citrix.com>
wrote:
> On Mon, 2013-11-25 at 12:00 -0800, Jordan Justen wrote:
>> 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.
Okay. That should work.
> 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.
Whoops. I asked if it followed a Xen convention, but then I missed
where you replied in the affirmative.

The biggest thing that bothers me is defining the addresses as 32-bit.
But, if this doesn''t worry you guys, then I guess it is unlikely to
change soon.

-Jordan

On Tue, 2013-11-26 at 08:46 -0800, Jordan Justen wrote:
> The biggest thing that bothers me is defining the addresses as 32-bit.
> But, if this doesn''t worry you guys, then I guess it is unlikely
to
> change soon.
I''d be happy with making them 64-bit.

Ian.