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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Thu, 24 Sep 2015, Stefano Stabellini wrote:
> 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?

Mark, Christoffer and I had another chat.  Given that it is difficult to
provide a consistent set of tables to Dom0 (the Runtime Services version
could differ from the native tables version and that is not allowed by
the EFI spec), Mark would like to see EFI support being introduced in a
Xen specific manner in Dom0, so that it is very clear that it might
differ from the native EFI tables and spec.

This is what we need to do:

- xen_early_init() should be moved before efi_init() in
  arch/arm64/kernel/setup.c. This will cause the device tree parsing in
  xen_early_init to be changed because it will have to operate on the
  flatten device tree.
- xen_early_init should discover the EFI tables. It could do that via
  hypercalls or via device tree attributes under the Xen hypervisor node
  on device tree. The nodes under /chosen, described by
  Documentation/arm/uefi.txt, should not be reused.
- xen_early_init could call the efi initialization functions directly or
  could setup some data structures (to be defined) so that efi_init will
  later detect that we are running on Xen making the initialization
  slightly different.
- acpi will be initialized as usual


This is what Mark, Christoffer and I agreed, I hope that this plan works
for everybody else too.

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