On Wed, 1 Feb 2017 14:03:52 +0100 Laszlo Ersek <ler...@redhat.com> wrote:
> On 02/01/17 13:52, Laszlo Ersek wrote: > > On 02/01/17 12:37, Igor Mammedov wrote: > >> On Tue, 31 Jan 2017 20:17:02 +0200 > >> "Michael S. Tsirkin" <m...@redhat.com> 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. > > Sigh, this looks nasty. > > Considering specifically the DSDT <-> X_DSDT question, Mantis ticket > #1393 (which requires the mutual exclusion) went into 5.1B. In version > 5.1A, the mutual exclusion is not required. > > Unfortuantely, the FADT Major.Minor version, as reported through the > bytes at offsets 8 and 131 decimal in the table, is "5.1" for *both* > 5.1A and 5.1B. In other words, looking at just Major.Minor, it cannot be > determined with full precision whether the DSDT and X_DSDT fields should > be exclusive or not. :/ The same applies to 6.0 vs 6.0A > > Laszlo > >
