Hi, On 02/09/13 11:48, Piker Alpha wrote: > Laszio, > > I'd like to make a suggestion. Use "Zero" instead of 0x00. This way iasl > you won't give you the: "6 Optimizations". > > -Pike
I'm not sure what you mean. The ASL below is a disassembly (iasl -d) from the AML generated by OVMF (dumped with acpidump in a guest, then decompiled). It's not meant to be recompiled to AML. Of course I did use iasl in ASL->AML direction (plus "hexdump -C" plus the grammar/opcodes in the ACPI spec) when working on the patch. I disabled all optimizations in iasl (-oa) when producing the binary input for hexdump: the AML had to be as basic as possible for compatibility (the patch addresses a compatibility problem anyway), and also so that it's easy to generate / understand (comment) in the OVMF source code. AML size or "interpretation speed" are secondary here, IMHO. Thanks Laszlo > > ------------------------------------------------------------------------ > *Van:* Jordan Justen <jljus...@gmail.com> > *Aan:* Laszlo Ersek <ler...@redhat.com> > *Cc:* edk2-devel@lists.sourceforge.net; dw...@infradead.org > *Verzonden:* vrijdag 8 februari 19:00 2013 > *Onderwerp:* Re: [edk2] [PATCH] OvmfPkg/AcpiPlatformDxe/Qemu.c: split > S3/S4 package contents into bytes > > I've come up with this alternate commit message text. Does it sound okay > to you? > > OvmfPkg/AcpiPlatformDxe: split S3/S4 package into bytes > > This should be more compatible with AML parsers in practice > since older versions of ACPICA's OS support would not accept > the previous OVMF format (despite being spec compliant). > (For example, on OpenBSD 5.2 it caused a kernel crash) > > ACPICA has fixed this issue in: > https://github.com/otcshare/acpica/commit/5869690a > > On Thu, Feb 7, 2013 at 10:20 AM, Laszlo Ersek <ler...@redhat.com > <mailto:ler...@redhat.com>> wrote: >> On 02/07/13 18:48, Jordan Justen wrote: >>> On Thu, Jan 24, 2013 at 4:32 AM, Laszlo Ersek <ler...@redhat.com > <mailto:ler...@redhat.com>> wrote: >>>> Such packages should be more compatible with AML parsers in practice: >>>> >>>> /* >>>> * Intel ACPI Component Architecture >>>> * AML Disassembler version 20090123 >>>> * >>>> * Disassembly of SSDT.aml, Thu Jan 24 13:23:26 2013 >>>> * >>>> * >>>> * Original Table Header: >>>> * Signature "SSDT" >>>> * Length 0x00000057 (87) >>>> * Revision 0x01 >>>> * Checksum 0x9D >>>> * OEM ID "REDHAT" >>>> * OEM Table ID "OVMF " >>>> * OEM Revision 0x00000001 (1) >>>> * Compiler ID "INTL" >>>> * Compiler Version 0x20090123 (537461027) >>>> */ >>>> DefinitionBlock ("SSDT.aml", "SSDT", 1, "REDHAT", "OVMF ", > 0x00000001) >>>> { >>>> OperationRegion (FWDT, SystemMemory, 0xDFB66F98, 0x00000030) >>>> Name (\_S3, Package (0x04) >>>> { >>>> 0x01, >>>> 0x00, >>>> 0x00, >>>> 0x00 >>>> }) >>>> Name (\_S4, Package (0x04) >>>> { >>>> 0x02, >>>> 0x00, >>>> 0x00, >>>> 0x00 >>>> }) >>>> } >>>> >>>> Testing: >>>> - Checked dmesg in an F18 guest, then selected hibernate and > verified the >>>> requested suspend type with a qemu debug patch. The above AML >>>> disassembly also originates from the F18 guest (acpidump + iasld -d). >>>> - Hibernated a Windows 8 Consumer Preview (Build 8250) guest, confirmed >>>> requested suspend type with the same qemu debug patch. >>> >>> The motivation for this change doesn't seem clear to me from the > commit message. >>> >>> Cleanup? Fixes hibernate for a few or all operating systems? >> >> Sorry for not having been clear enough. This patch changes how the same >> meaning is encoded in AML. >> >> The ACPI 5.0 spec describes the required package format for _Sx states >> in "7.3.4 System \_Sx states": >> >> All system states supported by the system must provide a package >> containing the DWORD value of the following format in the static >> Definition Block. [...] >> >> Then the spec explains the meaning of each of the four bytes. >> >> When I exported the packages as required the spec ("package with one >> DWORD element"), it broke a number of ACPI parsers (very likely, copies >> of various versions of the same ACPICA parser). The parse error has >> different consequences; under Linux it triggers verbose error messages & >> no support for entering _Sx states; on OpenBSD 5.2 it causes a kernel > crash. >> >> The reason for the parse error is that the ports of the ACPICA parser in >> question do not actually accept the ACPI 5.0 mandated "package with >> single DWORD element". They accept / require historical practice >> instead, which is "package with at least two Integer elements". >> >> The patch basically aims at bug compatibility with said parsers. >> >> ( >> >> I did post a fix for ACPICA so that it accepts both the "legacy format" >> and the spec-conformant format: >> >> - blurb: http://lists.acpica.org/pipermail/devel/2012-December/000405.html >> >> - patch: >> > http://lists.acpica.org/pipermail/devel/attachments/20121220/50519d70/attachment.ksh >> >> Ultimately the maintainer implemented >> <https://github.com/otcshare/acpica/commit/5869690a>. >> >> But we still need this patch for older guests that don't have (a port >> of) this ACPICA commit. >> >> ) >> >> Laszlo > > ------------------------------------------------------------------------------ > Free Next-Gen Firewall Hardware Offer > Buy your Sophos next-gen firewall before the end March 2013 > and get the hardware for free! Learn more. > http://p.sf.net/sfu/sophos-d2d-feb > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.sourceforge.net <mailto:edk2-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/edk2-devel > > ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
