From patchwork Fri Jun 19 02:40:14 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Laszlo Ersek X-Patchwork-Id: 486556 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 767D1140293 for ; Fri, 19 Jun 2015 12:44:52 +1000 (AEST) Received: from localhost ([::1]:55645 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5mIU-0004U9-ET for incoming@patchwork.ozlabs.org; Thu, 18 Jun 2015 22:44:50 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54868) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5mEQ-0004j7-6j for qemu-devel@nongnu.org; Thu, 18 Jun 2015 22:40:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z5mEP-0004Ng-4p for qemu-devel@nongnu.org; Thu, 18 Jun 2015 22:40:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49566) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5mEO-0004NY-T2 for qemu-devel@nongnu.org; Thu, 18 Jun 2015 22:40:37 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 874B32CAB8D for ; Fri, 19 Jun 2015 02:40:36 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-68.ams2.redhat.com [10.36.116.68]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5J2eJg8023899; Thu, 18 Jun 2015 22:40:35 -0400 From: Laszlo Ersek To: qemu-devel@nongnu.org, lersek@redhat.com Date: Fri, 19 Jun 2015 04:40:14 +0200 Message-Id: <1434681617-15539-8-git-send-email-lersek@redhat.com> In-Reply-To: <1434681617-15539-1-git-send-email-lersek@redhat.com> References: <1434681617-15539-1-git-send-email-lersek@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 209.132.183.28 Cc: Marcel Apfelbaum , "Michael S. Tsirkin" Subject: [Qemu-devel] [PATCH v7 07/10] hw/pci-bridge: disable SHPC in PXB 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 OVMF downloads the ACPI linker/loader script from QEMU when the edk2 PCI Bus driver globally signals the firmware that PCI enumeration and resource allocation have completed. At this point QEMU regenerates the ACPI payload in an fw_cfg read callback, and this is when the PXB's _CRS gets populated. Unfortunately, when this happens, the PCI_COMMAND_MEMORY bit is clear in the root bus's command register, *unlike* under SeaBIOS. The consequences unfold as follows: - When build_crs() fetches dev->io_regions[i].addr, it is all-bits-one, because pci_update_mappings() --> pci_bar_address() calculated it as PCI_BAR_UNMAPPED, due to the PCI_COMMAND_MEMORY bit being clear. - Consequently, the SHPC MMIO BAR (bar 0) of the bridge is not added to the _CRS, *despite* having been programmed in PCI config space. - Similarly, the SHPC MMIO BAR of the PXB is not removed from the main root bus's DWordMemory descriptor. - Guest OSes (Linux and Windows alike) notice the pre-programmed SHPC BAR within the PXB's config space, and notice that it conflicts with the main root bus's memory resource descriptors. Linux reports pci 0000:04:00.0: BAR 0: can't assign mem (size 0x100) pci 0000:04:00.0: BAR 0: trying firmware assignment [mem 0x88200000-0x882000ff 64bit] pci 0000:04:00.0: BAR 0: [mem 0x88200000-0x882000ff 64bit] conflicts with PCI Bus 0000:00 [mem 0x88200000-0xfebfffff] While Windows Server 2012 R2 reports https://technet.microsoft.com/en-us/library/cc732199%28v=ws.10%29.aspx This device cannot find enough free resources that it can use. If you want to use this device, you will need to disable one of the other devices on this system. (Code 12) This issue was apparently encountered earlier, see the "hack" in: https://lists.nongnu.org/archive/html/qemu-devel/2015-01/msg02983.html and the current hole-punching logic in build_crs() and build_ssdt() is probably supposed to remedy exactly that problem -- however, for OVMF they don't work, because at the end of the PCI enumeration and resource allocation, which cues the ACPI linker/loader client, the command register is clear. The "shpc" property of "pci-bridge", introduced in the previous patches, allows us to disable the standard hotplug controller cleanly, eliminating the SHPC bar and the conflict. Cc: Michael S. Tsirkin Cc: Marcel Apfelbaum Signed-off-by: Laszlo Ersek --- Notes: v7: - reference "shpc" property by macro PCI_BRIDGE_DEV_PROP_SHPC v6: - new in v6 (replaces "hw/pci-bridge: create interrupt-less, hotplug-less bridge for PXB" from v5) [Michael] hw/pci-bridge/pci_expander_bridge.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/pci-bridge/pci_expander_bridge.c b/hw/pci-bridge/pci_expander_bridge.c index 3d840ef..70708ef 100644 --- a/hw/pci-bridge/pci_expander_bridge.c +++ b/hw/pci-bridge/pci_expander_bridge.c @@ -177,6 +177,7 @@ static int pxb_dev_initfn(PCIDevice *dev) bds = qdev_create(BUS(bus), "pci-bridge"); bds->id = dev_name; qdev_prop_set_uint8(bds, PCI_BRIDGE_DEV_PROP_CHASSIS_NR, pxb->bus_nr); + qdev_prop_set_bit(bds, PCI_BRIDGE_DEV_PROP_SHPC, false); PCI_HOST_BRIDGE(ds)->bus = bus;