From patchwork Tue May 10 00:37:32 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Laszlo Ersek X-Patchwork-Id: 67386 Delivered-To: patch@linaro.org Received: by 10.140.92.199 with SMTP id b65csp1858395qge; Mon, 9 May 2016 17:37:47 -0700 (PDT) X-Received: by 10.98.55.133 with SMTP id e127mr53235476pfa.81.1462840667928; Mon, 09 May 2016 17:37:47 -0700 (PDT) Return-Path: Received: from ml01.01.org (ml01.01.org. [198.145.21.10]) by mx.google.com with ESMTPS id p125si40521873pfp.73.2016.05.09.17.37.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 May 2016 17:37:47 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of edk2-devel-bounces@lists.01.org designates 198.145.21.10 as permitted sender) client-ip=198.145.21.10; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of edk2-devel-bounces@lists.01.org designates 198.145.21.10 as permitted sender) smtp.mailfrom=edk2-devel-bounces@lists.01.org Received: from [127.0.0.1] (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id C316F1A1F1B; Mon, 9 May 2016 17:37:45 -0700 (PDT) X-Original-To: edk2-devel@ml01.01.org Delivered-To: edk2-devel@ml01.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id EC34B1A1F02 for ; Mon, 9 May 2016 17:37:43 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7F6BB10B838; Tue, 10 May 2016 00:37:43 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-113-38.phx2.redhat.com [10.3.113.38]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u4A0bc8I001870; Mon, 9 May 2016 20:37:42 -0400 From: Laszlo Ersek To: edk2-devel-01 Date: Tue, 10 May 2016 02:37:32 +0200 Message-Id: <1462840655-1802-4-git-send-email-lersek@redhat.com> In-Reply-To: <1462840655-1802-1-git-send-email-lersek@redhat.com> References: <1462840655-1802-1-git-send-email-lersek@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 10 May 2016 00:37:43 +0000 (UTC) Subject: [edk2] [PATCH 3/6] OvmfPkg: introduce PcdIch9AcpiPmBaseAddress X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Jordan Justen MIME-Version: 1.0 Errors-To: edk2-devel-bounces@lists.01.org Sender: "edk2-devel" According to the ICH9 spec, PMBASE "provides 128 bytes of I/O space for ACPI, GPIO, and TCO logic. This is placed on a 128-byte boundary". On the Q35 machine type of QEMU, our current PMBASE setting of 0xB000 is the only thing that prevents us from lowering the base of the PCI IO port aperture from 0xC000. (The base must be aligned to 0x1000 due to PCI bridge requirements.) By moving our PMBASE to 0x0600 (moving the register block to 0x0600..0x067F inclusive), which is also what SeaBIOS uses on Q35, we will be able to lower the PCI IO port aperture base to 0x6000 (the next IO port under it being taken by the "vmport" device, at fixed 0x5658), while steering clear of other QEMU devices. On PIIX4, freeing up the 0x1000 IO ports at 0xB000 wouldn't help much, because the 0xA000 block right below it is occupied by unmovable devices (see for details). Doing this for Q35 only has two more benefits: - It won't interfere with Xen guests, - The Q35 machine type with the smallest version number is "pc-q35-2.4", which is guaranteed to have an ACPI generator. This matters because the ACPI tables (FACP, DSDT) have to reflect the PM base address that we program. Cc: Jordan Justen Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1333238 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek --- OvmfPkg/OvmfPkg.dec | 4 ++++ 1 file changed, 4 insertions(+) -- 1.8.3.1 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec index d30a40eb153c..a65bd01399be 100644 --- a/OvmfPkg/OvmfPkg.dec +++ b/OvmfPkg/OvmfPkg.dec @@ -77,10 +77,14 @@ [PcdsFixedAtBuild] ## This flag determines the Power Management Base Address of choice, written # to PIIX4 function 3 offset 0x40-0x43 bits [15:6]. gUefiOvmfPkgTokenSpaceGuid.PcdPiix4AcpiPmBaseAddress|0xB000|UINT16|5 + ## This PCD determines the Power Management Base Address of choice, written + # to ICH9 device 31 function 0, offset 0x40-0x43 bits [15:7]. + gUefiOvmfPkgTokenSpaceGuid.PcdIch9AcpiPmBaseAddress|0x0600|UINT16|0x28 + ## When VirtioScsiDxe is instantiated for a HBA, the numbers of targets and # LUNs are retrieved from the host during virtio-scsi setup. # MdeModulePkg/Bus/Scsi/ScsiBusDxe then scans all MaxTarget * MaxLun # possible devices. This can take extremely long, for example with # MaxTarget=255 and MaxLun=16383. The *inclusive* constants below limit