Re: [Xen-devel] [PATCH v2 18/30] xen/x86: setup PVHv2 Dom0 ACPI tables

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 10/27/2016 07:13 AM, Roger Pau Monne wrote:
> On Wed, Oct 26, 2016 at 01:14:16PM -0400, Boris Ostrovsky wrote:
> > > > > > I've initially used a back-listing approach. We can always change this later
> > > > > > on.
> > > > > >
> > > > > > So I've ended up crafting a new MADT, XSDT and RSDP. Note that I'm not
> > > > > > crafting a new custom RSDT (and in fact I'm setting rsdt_physical_address =
> > > > > > 0 in the RSDP together with revision = 2). This is all placed in RAM stolen
> > > > > > from the guest memory map and marked as E820_ACPI, which means that the new
> > > > > > RSDP no longer resides below 1MB,
> >
> > As I mentioned in the other thread I am not sure this would be in
> > compliance with the ACPI spec.
> Right, the ACPI spec mandates that the RSDP must reside in the first 1 KB of
> the EBDA, or in the ROM regions between 0xE0000 0xFFFFF, but that's only
> when booted from a legacy BIOS, when booted from UEFI the RSDP can reside
> anywhere in memory, and the pointer must be fetched from a UEFI specific
> table. I would consider Xen to be similar to UEFI boot in that regard.

It is similar but not a true UEFI boot so we are violating the spec. 
Which, for example, means that standard Linux ACPI root discovery won't 
work.
I re-read this thread and I am not sure I understand why we can't keep 
host's RSDP descriptor. We are not mapping dom0 memory 1:1 (right?) so 
we can place our versions of RSDT/XSDT at the address that the 
descriptor points to.
Unless that address is beyond dom0 memory allocation so that could be a 
problem I guess.
-boris

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