From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54372) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WSmrR-00047O-0x for qemu-devel@nongnu.org; Wed, 26 Mar 2014 08:23:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WSmrJ-000173-SW for qemu-devel@nongnu.org; Wed, 26 Mar 2014 08:23:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:13153) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WSmrJ-00016s-KX for qemu-devel@nongnu.org; Wed, 26 Mar 2014 08:23:05 -0400 Date: Wed, 26 Mar 2014 14:23:07 +0200 From: "Michael S. Tsirkin" Message-ID: <1395831215-5985-2-git-send-email-mst@redhat.com> References: <1395831215-5985-1-git-send-email-mst@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1395831215-5985-1-git-send-email-mst@redhat.com> Subject: [Qemu-devel] [PULL for-2.0 1/4] acpi: make SSDT 1.0 spec compliant when possible List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Peter Maydell , Laszlo Ersek , Anthony Liguori , Robert Hu The ACPI specification says: The ASL compiler can emit two different AML opcodes for a Package declaration, either PackageOp or VarPackageOp. For small, fixed-length packages, the PackageOp is used and this opcode is compatible with ACPI 1.0. A VarPackageOp will be emitted if any of the following conditions are true: . The NumElements argument is a TermArg that can only be resolved at runtime. . At compile time, NumElements resolves to a constant that is larger than 255. . The PackageList contains more than 255 initializer elements. Note: The ability to create variable-sized packages was first introduced in ACPI 2.0. ACPI 1.0 only allowed fixed-size packages with up to 255 elements. So the spec seems to say a fixed value up to 255 must always be used with PackageOp and not VarPackageOp, and some guests (windows up to win2k8) seem to interpret it like this. Let's do just this, choosing the encoding depending on the number of elements. Fixes 9bcc80cd71892df42605e0c097d85c0237ff45d1 (i386/acpi-build: allow more than 255 elements in CPON). https://bugs.launchpad.net/bugs/1297651 Reported-by: Robert Hu Cc: Laszlo Ersek Signed-off-by: Michael S. Tsirkin --- hw/i386/acpi-build.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c index f1054dd..7597517 100644 --- a/hw/i386/acpi-build.c +++ b/hw/i386/acpi-build.c @@ -1055,9 +1055,21 @@ build_ssdt(GArray *table_data, GArray *linker, { GArray *package = build_alloc_array(); - uint8_t op = 0x13; /* VarPackageOp */ + uint8_t op; + + /* + * Note: The ability to create variable-sized packages was first introduced in ACPI 2.0. ACPI 1.0 only + * allowed fixed-size packages with up to 255 elements. + * Windows guests up to win2k8 fail when VarPackageOp is used. + */ + if (acpi_cpus <= 255) { + op = 0x12; /* PackageOp */ + build_append_byte(package, acpi_cpus); /* NumElements */ + } else { + op = 0x13; /* VarPackageOp */ + build_append_int(package, acpi_cpus); /* VarNumElements */ + } - build_append_int(package, acpi_cpus); /* VarNumElements */ for (i = 0; i < acpi_cpus; i++) { uint8_t b = test_bit(i, cpu->found_cpus) ? 0x01 : 0x00; build_append_byte(package, b); -- MST