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 )
