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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 23 Sep 2015, Stefano Stabellini wrote:
> 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.

Looking again at the spec, it includes this line:

#define EFI_RUNTIME_SERVICES_REVISION EFI_SPECIFICATION_VERSION

the only way I can read it is that the EFI Runtime Services version
needs to match the EFI specification version.

Unfortunately it looks like that we cannot, according to spec, expose a
different version of Runtime Services.

Given that trying to emulate a set of Runtime Services which matches the
version of the ones on the host would be undesirable from Xen point of
view, would it be OK if we went ahead and added to the Xen-Dom0
interface on EFI, which we are about to introduce and document, that the
Runtime Services table pointer can be NULL?

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