qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH RFC] acpi: add reset register to fadt


From: Laszlo Ersek
Subject: Re: [Qemu-devel] [PATCH RFC] acpi: add reset register to fadt
Date: Wed, 1 Feb 2017 13:52:45 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0

On 02/01/17 12:37, Igor Mammedov wrote:
> On Tue, 31 Jan 2017 20:17:02 +0200
> "Michael S. Tsirkin" <address@hidden> wrote:
> 
>> On Tue, Jan 31, 2017 at 05:28:57PM +0100, Laszlo Ersek wrote:
>>> The ACPI 6.1 spec says,
>>>
>>> - DSDT: [...] If the X_DSDT field contains a non-zero value then this
>>>   field must be zero.
>>> - X_DSDT: [...] If the DSDT field contains a non-zero value then this
>>>   field must be zero.  
>>
>> But that's only 6.1. 6.0 and earlier did not say this.
>> The errata they wanted to address was:
>> 1393 In FADT: if X_DSDT field is non-zero, DSDT
>> field should be ignored or deprecated
>>
>> I would class this as a spec bug.
>>
> 
> The same applies to X_PM1a_EVT_BLK and co,
> for example 5.1 spec "This is a required
> field."
> 
> And looks like Windows implemented it as mandatory
> to boot perhaps to be compatible with 5.1 and earlier
> specs.
> 
> It appears fw would be forced to fill fields depending
> on table revision.

Sounds like a valid point.

I compared the FADT defintion between ACPI 5.1 and ACPI 6.1. Indeed, the
former says:

- FADT Major Version: 5; Major Version of this FADT structure, [...]
- DSDT: Physical memory address (0-4 GB) of the DSDT.
- X_DSDT: 64bit physical address of the DSDT.

the latter says:

- FADT Major Version: 6; Major Version of this FADT structure, [...]

- DSDT: Physical memory address of the DSDT. If the X_DSDT field
  contains a non-zero value then this field must be zero.

- X_DSDT: Extended physical address of the DSDT. If the DSDT field
  contains a non-zero value then this field must be zero.

I will ask on edk2-devel whether the
"MdeModulePkg/Universal/Acpi/AcpiTableDxe" maintainers can think of a
way to accommodate this.

Thanks
Laszlo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]