Re: [Xen-devel] Xen, ACPI and Linux

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 23 Sep 2015, Ian Campbell wrote:
> On Wed, 2015-09-23 at 01:18 -0700, Ard Biesheuvel wrote:
> > On 23 September 2015 at 01:12, Jan Beulich <JBeulich@xxxxxxxx> wrote:
> > > > > > On 23.09.15 at 02:49, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> > > > Regarding Runtime Services, the EFI spec doesn't allow a NULL pointer
> > > > to
> > > > the Runtime Services table, so Mark would like to see a proper
> > > > pointer
> > > > being passed there.  The function table could be populated with
> > > > hypercall wrappers in assembly, keeping the same interface to Xen
> > > > that
> > > > we have today in drivers/xen/efi.c. It should be part of the initial
> > > > patch series.
> > > 
> > > I'm confused by the "interface to Xen" part: Aren't we talking about
> > > what is being presented to Dom0?
> > > 
> > 
> > Yes we are.
> > 
> > > In any event, the versioning question that I raised earlier remains:
> > > Which version would you intend the Runtime Services table to carry
> > > - the host one, or a Xen set one? In the latter case, won't you risk
> > > wrong implications from the kernel looking at other version numbers
> > > (yes, with proper coding it ought to be possible to avoid such, but
> > > the multitude of version numbers in EFI doesn't exactly help to
> > > avoid mistakes)? While in the former case you'd have to deal with
> > > the table needing entries Xen may not know about.
> > > 
> > 
> > This is simply addressed by populating the fake EFI system table
> > according to the UEFI spec version field that you put in the header.
> > No reason at all to base this on whatever the host provides, it should
> > simply be a version that is supported by arm64 (2.00 or greater)
> 
> This doesn't address Jan's concern wrt the multiple other places UEFI
> exposes version numbers which may reflect the host and not this fake EFI
> table.

The Runtime Services table has its own version field. I think that
theoretically it could be different from the other version fields, but I
don't know if it ever happens with real hardware.

If we don't want to support the case where Runtime Services have a
different revision version than the other tables, then I think that
going for the NULL Runtime Services table pointer approach might be
better.

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