Re: [Qemu-devel] [PATCH] hw/arm/virt: generate 64-bit addressable ACPI objects

[Laszlo Ersek <lersek@redhat.com>]

On 04/07/17 11:44, Ard Biesheuvel wrote:
> On 7 April 2017 at 10:36, Phil Dennis-Jordan <phil@philjordan.eu> wrote:
>> On 7 April 2017 at 21:11, Laszlo Ersek <lersek@redhat.com> wrote:
>>> On 04/07/17 10:55, Andrew Jones wrote:
>>>> On Thu, Apr 06, 2017 at 10:22:09PM +0100, Ard Biesheuvel wrote:

>>>>> @@ -712,7 +712,7 @@ static void build_fadt(GArray *table_data, BIOSLinker *linker,
>>>>>
>>>>>      /* DSDT address to be filled by Guest linker */
>>>>>      bios_linker_loader_add_pointer(linker,
>>>>> -        ACPI_BUILD_TABLE_FILE, dsdt_entry_offset, sizeof(fadt->dsdt),
>>>>> +        ACPI_BUILD_TABLE_FILE, xdsdt_entry_offset, sizeof(fadt->Xdsdt),
>>>>>          ACPI_BUILD_TABLE_FILE, dsdt_tbl_offset);
>>>>>
>>>>>      build_header(linker, table_data,
>>
>> I don't know what it's like in ARM-Land, but X64 Windows does not take
>> kindly to a zero DSDT pointer in my experience. It might make sense to
>> make the choice between DSDT and XDSDT conditional on whether the
>> pointer is actually above 4GB? Mind you, I don't even know if
>> Microsoft makes ARM variants of Windows generally available, and
>> whether they currently work in Qemu; the FOSS OSes are typically more
>> lenient.
>>
> 
> Documentation/arm64/acpi_object_usage.txt in the kernel contains this under FADT
> 
>    For the DSDT that is also required, the X_DSDT field is to be used,
>    not the DSDT field.
> 
> and so we should be using xdsdt anyway. *However*, this is all moot
> given that UEFI is in charge of populating these fields. What we
> generate here and what the guest sees are two different things that
> are almost completely disconnected when it comes to RSDP, RSDT/XSDT
> and the DSDT field in FADT.

Agreed; in ARM guests, there is no ACPI without UEFI, and UEFI handles
the above stuff internally. For UEFI guests, some of the linker/loader
commands have a somewhat indirect meaning.

Laszlo