[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Fri, 2015-09-25 at 21:20 +0100, Stefano Stabellini wrote:
> 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.

My only question is whether, given this early init, we need to continue to
tie EFI and ACPI together in this way. Can't we detect ACPI directly
instead of EFI?

Ian.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.