On 16.05.2023 02:16, Stefano Stabellini wrote: > On Mon, 15 May 2023, Jan Beulich wrote: >> On 15.05.2023 10:48, Roger Pau Monné wrote: >>> Alternatively we might want to copy and use the RSDT on systems that >>> lack an XSDT, or even just copy the header from the RSDT into Xen's >>> crafted XSDT, since the format of the RSDP and the XSDT headers are >>> exactly the same (the difference is in the size of the description >>> headers that come after). >> >> I guess I'd prefer that last variant. > > I tried this approach (together with the second patch for necessity) and > it worked.
Which I find slightly surprising - a fully conforming consumer of the tables may expect an XSDT when xsdt_physical_address is set, and reject RSDT. We may still want to limit ourselves to this less involved approach, but then with a code comment clearly stating the limitation. Jan > --- a/xen/arch/x86/hvm/dom0_build.c > +++ b/xen/arch/x86/hvm/dom0_build.c > @@ -967,6 +967,10 @@ static int __init pvh_setup_acpi_xsdt(struct domain *d, > paddr_t madt_addr, > goto out; > } > xsdt_paddr = rsdp->xsdt_physical_address; > + if ( !xsdt_paddr ) > + { > + xsdt_paddr = rsdp->rsdt_physical_address; > + } > acpi_os_unmap_memory(rsdp, sizeof(*rsdp)); > table = acpi_os_map_memory(xsdt_paddr, sizeof(*table)); > if ( !table )