From patchwork Mon Mar 17 16:05:16 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Laszlo Ersek X-Patchwork-Id: 331073 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 2C2782C00B7 for ; Tue, 18 Mar 2014 03:07:44 +1100 (EST) Received: from localhost ([::1]:58848 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WPa4j-0004mL-Qc for incoming@patchwork.ozlabs.org; Mon, 17 Mar 2014 12:07:41 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57450) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WPa2m-0002f2-OO for qemu-devel@nongnu.org; Mon, 17 Mar 2014 12:05:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WPa2g-00018R-EL for qemu-devel@nongnu.org; Mon, 17 Mar 2014 12:05:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44754) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WPa2g-00018N-6d for qemu-devel@nongnu.org; Mon, 17 Mar 2014 12:05:34 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2HG5WUQ026721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Mar 2014 12:05:33 -0400 Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-46.ams2.redhat.com [10.36.116.46]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s2HG5JVp031980; Mon, 17 Mar 2014 12:05:26 -0400 From: Laszlo Ersek To: qemu-devel@nongnu.org, afaerber@suse.de, ehabkost@redhat.com, imammedo@redhat.com, mst@redhat.com Date: Mon, 17 Mar 2014 17:05:16 +0100 Message-Id: <1395072317-15679-2-git-send-email-lersek@redhat.com> In-Reply-To: <1395072317-15679-1-git-send-email-lersek@redhat.com> References: <1395072317-15679-1-git-send-email-lersek@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [for-2.1 PATCH v2 1/2] i386/acpi-build: allow more than 255 elements in CPON X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org The build_ssdt() function builds a number of AML objects that are related to CPU hotplug, and whose IDs form a contiguous sequence of APIC IDs. (APIC IDs are in fact discontiguous, but this is the traditional interface: build a contiguous sequence from zero up that covers all possible APIC IDs.) These objects are: - a Processor() object for each VCPU, - a NTFY method, with one branch for each VCPU, - a CPON package with one element (hotplug status byte) for each VCPU. The build_ssdt() function currently limits the *count* of processor objects, and NTFY branches, and CPON elements, in 0xFF (see the assignment to "acpi_cpus"). This allows for an inclusive APIC ID range of [0..254]. This is incorrect, because the highest APIC ID that we otherwise allow a VCPU to take is 255. In order to extend the maximum count to 256, and the traversed APIC ID range correspondingly to [0..255]: - the Processor() objects need no change, - the NTFY method also needs no change, - the CPON package must be updated, because it is defined with a DefPackage, and the number of elements in such a package can be at most 255. We pick a DefVarPackage instead. We replace the Op byte, and the encoding of the number of elements. Compare: DefPackage := PackageOp PkgLength NumElements PackageElementList DefVarPackage := VarPackageOp PkgLength VarNumElements PackageElementList PackageOp := 0x12 VarPackageOp := 0x13 NumElements := ByteData VarNumElements := TermArg => Integer The build_append_int() function implements precisely the following TermArg encodings (a subset of what the ACPI spec describes): TermArg := DataObject DataObject := ComputationalData ComputationalData := ConstObj | ByteConst | WordConst | DWordConst directly encoded in the function, with build_append_byte(): ConstObj := ZeroOp | OneOp ZeroOp := 0x00 OneOp := 0x01 call to build_append_value(..., 1): ByteConst := BytePrefix ByteData BytePrefix := 0x0A ByteData := 0x00 - 0xFF call to build_append_value(..., 2): WordConst := WordPrefix WordData WordPrefix := 0x0B WordData := ByteData[0:7] ByteData[8:15] call to build_append_value(..., 4): DWordConst := DWordPrefix DWordData DWordPrefix := 0x0C DWordData := WordData[0:15] WordData[16:31] Signed-off-by: Laszlo Ersek --- hw/i386/acpi-build.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c index da2741c..2bbefb5 100644 --- a/hw/i386/acpi-build.c +++ b/hw/i386/acpi-build.c @@ -1050,9 +1050,9 @@ build_ssdt(GArray *table_data, GArray *linker, { GArray *package = build_alloc_array(); - uint8_t op = 0x12; /* PackageOp */ + uint8_t op = 0x13; /* VarPackageOp */ - build_append_byte(package, acpi_cpus); /* NumElements */ + 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);