From nobody Thu May 2 07:19:23 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zoho.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1487878476578424.0272401787786; Thu, 23 Feb 2017 11:34:36 -0800 (PST) Received: from localhost ([::1]:60574 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cgz9u-0006jC-DL for importer@patchew.org; Thu, 23 Feb 2017 14:34:34 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34695) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cgz8Z-0005UI-26 for qemu-devel@nongnu.org; Thu, 23 Feb 2017 14:33:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cgz8U-0002E7-2x for qemu-devel@nongnu.org; Thu, 23 Feb 2017 14:33:11 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48808) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cgz8T-0002Ce-TY for qemu-devel@nongnu.org; Thu, 23 Feb 2017 14:33:06 -0500 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (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 15C533A76BB for ; Thu, 23 Feb 2017 19:33:06 +0000 (UTC) Received: from gimli.home (ovpn-117-7.phx2.redhat.com [10.3.117.7]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v1NJX5db006052; Thu, 23 Feb 2017 14:33:05 -0500 From: Alex Williamson To: qemu-devel@nongnu.org Date: Thu, 23 Feb 2017 12:33:04 -0700 Message-ID: <20170223193258.16909.52582.stgit@gimli.home> In-Reply-To: <20170223193048.16909.25661.stgit@gimli.home> References: <20170223193048.16909.25661.stgit@gimli.home> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Thu, 23 Feb 2017 19:33:06 +0000 (UTC) Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PULL 1/3] vfio/pci: Report errors from qdev_unplug() via device request X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 Currently we ignore this error, report it with error_reportf_err() Signed-off-by: Alex Williamson Reviewed-by: Eric Auger Reviewed-by: Philippe Mathieu-Daud=C3=A9 --- hw/vfio/pci.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c index 332f41d6627f..f2ba9b6cfafc 100644 --- a/hw/vfio/pci.c +++ b/hw/vfio/pci.c @@ -2506,12 +2506,16 @@ static void vfio_unregister_err_notifier(VFIOPCIDev= ice *vdev) static void vfio_req_notifier_handler(void *opaque) { VFIOPCIDevice *vdev =3D opaque; + Error *err =3D NULL; =20 if (!event_notifier_test_and_clear(&vdev->req_notifier)) { return; } =20 - qdev_unplug(&vdev->pdev.qdev, NULL); + qdev_unplug(&vdev->pdev.qdev, &err); + if (err) { + error_reportf_err(err, WARN_PREFIX, vdev->vbasedev.name); + } } =20 static void vfio_register_req_notifier(VFIOPCIDevice *vdev) From nobody Thu May 2 07:19:23 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zoho.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1487878725082616.640469648352; Thu, 23 Feb 2017 11:38:45 -0800 (PST) Received: from localhost ([::1]:60597 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cgzDu-0002Uv-P3 for importer@patchew.org; Thu, 23 Feb 2017 14:38:42 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35536) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cgzBy-0000S3-BS for qemu-devel@nongnu.org; Thu, 23 Feb 2017 14:36:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cgzBx-0003Un-2f for qemu-devel@nongnu.org; Thu, 23 Feb 2017 14:36:42 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36272) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cgzBw-0003Uc-QO for qemu-devel@nongnu.org; Thu, 23 Feb 2017 14:36:41 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (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 ED90583F38 for ; Thu, 23 Feb 2017 19:36:40 +0000 (UTC) Received: from gimli.home (ovpn-117-7.phx2.redhat.com [10.3.117.7]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v1NJaer0017546; Thu, 23 Feb 2017 14:36:40 -0500 From: Alex Williamson To: qemu-devel@nongnu.org Date: Thu, 23 Feb 2017 12:36:39 -0700 Message-ID: <20170223193621.17110.40016.stgit@gimli.home> In-Reply-To: <20170223193048.16909.25661.stgit@gimli.home> References: <20170223193048.16909.25661.stgit@gimli.home> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Thu, 23 Feb 2017 19:36:40 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PULL 2/3] vfio/pci: Improve extended capability comments, skip masked caps X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 Since commit 4bb571d857d9 ("pci/pcie: don't assume cap id 0 is reserved") removes the internal use of extended capability ID 0, the comment here becomes invalid. However, peeling back the onion, the code is still correct and we still can't seed the capability chain with ID 0, unless we want to muck with using the version number to force the header to be non-zero, which is much uglier to deal with. The comment also now covers some of the subtleties of using cap ID 0, such as transparently indicating absence of capabilities if none are added. This doesn't detract from the correctness of the referenced commit as vfio in the kernel also uses capability ID zero to mask capabilties. In fact, we should skip zero capabilities precisely because the kernel might also expose such a capability at the head position and re-introduce the problem. Signed-off-by: Alex Williamson Reviewed-by: Peter Xu Tested-by: Peter Xu Reported-by: Jintack Lim Tested-by: Jintack Lim --- hw/vfio/pci.c | 31 +++++++++++++++++++++---------- 1 file changed, 21 insertions(+), 10 deletions(-) diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c index f2ba9b6cfafc..03a3d0154976 100644 --- a/hw/vfio/pci.c +++ b/hw/vfio/pci.c @@ -1880,16 +1880,26 @@ static void vfio_add_ext_cap(VFIOPCIDevice *vdev) /* * Extended capabilities are chained with each pointing to the next, s= o we * can drop anything other than the head of the chain simply by modify= ing - * the previous next pointer. For the head of the chain, we can modif= y the - * capability ID to something that cannot match a valid capability. ID - * 0 is reserved for this since absence of capabilities is indicated by - * 0 for the ID, version, AND next pointer. However, pcie_add_capabil= ity() - * uses ID 0 as reserved for list management and will incorrectly matc= h and - * assert if we attempt to pre-load the head of the chain with this ID. - * Use ID 0xFFFF temporarily since it is also seems to be reserved in - * part for identifying absence of capabilities in a root complex regi= ster - * block. If the ID still exists after adding capabilities, switch ba= ck to - * zero. We'll mark this entire first dword as emulated for this purp= ose. + * the previous next pointer. Seed the head of the chain here such th= at + * we can simply skip any capabilities we want to drop below, regardle= ss + * of their position in the chain. If this stub capability still exis= ts + * after we add the capabilities we want to expose, update the capabil= ity + * ID to zero. Note that we cannot seed with the capability header be= ing + * zero as this conflicts with definition of an absent capability chain + * and prevents capabilities beyond the head of the list from being ad= ded. + * By replacing the dummy capability ID with zero after walking the de= vice + * chain, we also transparently mark extended capabilities as absent if + * no capabilities were added. Note that the PCIe spec defines an abs= ence + * of extended capabilities to be determined by a value of zero for the + * capability ID, version, AND next pointer. A non-zero next pointer + * should be sufficient to indicate additional capabilities are presen= t, + * which will occur if we call pcie_add_capability() below. The entire + * first dword is emulated to support this. + * + * NB. The kernel side does similar masking, so be prepared that our + * view of the device may also contain a capability ID zero in the head + * of the chain. Skip it for the same reason that we cannot seed the + * chain with a zero capability. */ pci_set_long(pdev->config + PCI_CONFIG_SPACE_SIZE, PCI_EXT_CAP(0xFFFF, 0, 0)); @@ -1915,6 +1925,7 @@ static void vfio_add_ext_cap(VFIOPCIDevice *vdev) PCI_EXT_CAP_NEXT_MASK); =20 switch (cap_id) { + case 0: /* kernel masked capability */ case PCI_EXT_CAP_ID_SRIOV: /* Read-only VF BARs confuse OVMF */ case PCI_EXT_CAP_ID_ARI: /* XXX Needs next function virtualization= */ trace_vfio_add_ext_cap_dropped(vdev->vbasedev.name, cap_id, ne= xt); From nobody Thu May 2 07:19:23 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zoho.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1487878740239802.24879148684; Thu, 23 Feb 2017 11:39:00 -0800 (PST) Received: from localhost ([::1]:60598 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cgzE7-0002ce-NK for importer@patchew.org; Thu, 23 Feb 2017 14:38:55 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35666) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cgzCv-0001ov-Nz for qemu-devel@nongnu.org; Thu, 23 Feb 2017 14:37:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cgzCr-0003dC-84 for qemu-devel@nongnu.org; Thu, 23 Feb 2017 14:37:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55260) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cgzCq-0003cr-Vr for qemu-devel@nongnu.org; Thu, 23 Feb 2017 14:37:37 -0500 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (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 216447FB7D for ; Thu, 23 Feb 2017 19:37:37 +0000 (UTC) Received: from gimli.home (ovpn-117-7.phx2.redhat.com [10.3.117.7]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v1NJbaq8009036; Thu, 23 Feb 2017 14:37:36 -0500 From: Alex Williamson To: qemu-devel@nongnu.org Date: Thu, 23 Feb 2017 12:37:35 -0700 Message-ID: <20170223193724.17158.84397.stgit@gimli.home> In-Reply-To: <20170223193048.16909.25661.stgit@gimli.home> References: <20170223193048.16909.25661.stgit@gimli.home> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Thu, 23 Feb 2017 19:37:37 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PULL 3/3] vfio/pci-quirks.c: Disable stolen memory for igd VFIO X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 From: XiongZhang Regardless of running in UPT or legacy mode, the guest igd drivers may attempt to use stolen memory, however only legacy mode has BIOS support for reserving stolen memmory in the guest VM. We zero out the stolen memory size in all cases, then guest igd driver won't use stolen memory. In legacy mode, user could use x-igd-gms option to specify the amount of stolen memory which will be pre-allocated and reserved by bios for igd use. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=3D99028 https://bugs.freedesktop.org/show_bug.cgi?id=3D99025 Signed-off-by: Xiong Zhang Tested-by: Terrence Xu Signed-off-by: Alex Williamson --- hw/vfio/pci-quirks.c | 65 +++++++++++++++++++++++++++++-----------------= ---- 1 file changed, 38 insertions(+), 27 deletions(-) diff --git a/hw/vfio/pci-quirks.c b/hw/vfio/pci-quirks.c index e9b493b939db..e995e32deedf 100644 --- a/hw/vfio/pci-quirks.c +++ b/hw/vfio/pci-quirks.c @@ -1367,14 +1367,45 @@ static void vfio_probe_igd_bar4_quirk(VFIOPCIDevice= *vdev, int nr) uint16_t cmd_orig, cmd; Error *err =3D NULL; =20 + /* This must be an Intel VGA device. */ + if (!vfio_pci_is(vdev, PCI_VENDOR_ID_INTEL, PCI_ANY_ID) || + !vfio_is_vga(vdev) || nr !=3D 4) { + return; + } + /* - * This must be an Intel VGA device at address 00:02.0 for us to even - * consider enabling legacy mode. The vBIOS has dependencies on the - * PCI bus address. + * IGD is not a standard, they like to change their specs often. We + * only attempt to support back to SandBridge and we hope that newer + * devices maintain compatibility with generation 8. */ - if (!vfio_pci_is(vdev, PCI_VENDOR_ID_INTEL, PCI_ANY_ID) || - !vfio_is_vga(vdev) || nr !=3D 4 || - &vdev->pdev !=3D pci_find_device(pci_device_root_bus(&vdev->pdev), + gen =3D igd_gen(vdev); + if (gen !=3D 6 && gen !=3D 8) { + error_report("IGD device %s is unsupported by IGD quirks, " + "try SandyBridge or newer", vdev->vbasedev.name); + return; + } + + /* + * Regardless of running in UPT or legacy mode, the guest graphics + * driver may attempt to use stolen memory, however only legacy mode + * has BIOS support for reserving stolen memory in the guest VM. + * Emulate the GMCH register in all cases and zero out the stolen + * memory size here. Legacy mode may request allocation and re-write + * this below. + */ + gmch =3D vfio_pci_read_config(&vdev->pdev, IGD_GMCH, 4); + gmch &=3D ~((gen < 8 ? 0x1f : 0xff) << (gen < 8 ? 3 : 8)); + + /* GMCH is read-only, emulated */ + pci_set_long(vdev->pdev.config + IGD_GMCH, gmch); + pci_set_long(vdev->pdev.wmask + IGD_GMCH, 0); + pci_set_long(vdev->emulated_config_bits + IGD_GMCH, ~0); + + /* + * This must be at address 00:02.0 for us to even onsider enabling + * legacy mode. The vBIOS has dependencies on the PCI bus address. + */ + if (&vdev->pdev !=3D pci_find_device(pci_device_root_bus(&vdev->pdev), 0, PCI_DEVFN(0x2, 0))) { return; } @@ -1394,18 +1425,6 @@ static void vfio_probe_igd_bar4_quirk(VFIOPCIDevice = *vdev, int nr) } =20 /* - * IGD is not a standard, they like to change their specs often. We - * only attempt to support back to SandBridge and we hope that newer - * devices maintain compatibility with generation 8. - */ - gen =3D igd_gen(vdev); - if (gen !=3D 6 && gen !=3D 8) { - error_report("IGD device %s is unsupported in legacy mode, " - "try SandyBridge or newer", vdev->vbasedev.name); - return; - } - - /* * Most of what we're doing here is to enable the ROM to run, so if * there's no ROM, there's no point in setting up this quirk. * NB. We only seem to get BIOS ROMs, so a UEFI VM would need CSM supp= ort. @@ -1460,8 +1479,6 @@ static void vfio_probe_igd_bar4_quirk(VFIOPCIDevice *= vdev, int nr) goto out; } =20 - gmch =3D vfio_pci_read_config(&vdev->pdev, IGD_GMCH, 4); - /* * If IGD VGA Disable is clear (expected) and VGA is not already enabl= ed, * try to enable it. Probably shouldn't be using legacy mode without = VGA, @@ -1532,12 +1549,11 @@ static void vfio_probe_igd_bar4_quirk(VFIOPCIDevice= *vdev, int nr) * when IVD (IGD VGA Disable) is clear, but the claim is that it's unu= sed, * so let's not waste VM memory for it. */ - gmch &=3D ~((gen < 8 ? 0x1f : 0xff) << (gen < 8 ? 3 : 8)); - if (vdev->igd_gms) { if (vdev->igd_gms <=3D 0x10) { gms_mb =3D vdev->igd_gms * 32; gmch |=3D vdev->igd_gms << (gen < 8 ? 3 : 8); + pci_set_long(vdev->pdev.config + IGD_GMCH, gmch); } else { error_report("Unsupported IGD GMS value 0x%x", vdev->igd_gms); vdev->igd_gms =3D 0; @@ -1557,11 +1573,6 @@ static void vfio_probe_igd_bar4_quirk(VFIOPCIDevice = *vdev, int nr) fw_cfg_add_file(fw_cfg_find(), "etc/igd-bdsm-size", bdsm_size, sizeof(*bdsm_size)); =20 - /* GMCH is read-only, emulated */ - pci_set_long(vdev->pdev.config + IGD_GMCH, gmch); - pci_set_long(vdev->pdev.wmask + IGD_GMCH, 0); - pci_set_long(vdev->emulated_config_bits + IGD_GMCH, ~0); - /* BDSM is read-write, emulated. The BIOS needs to be able to write i= t */ pci_set_long(vdev->pdev.config + IGD_BDSM, 0); pci_set_long(vdev->pdev.wmask + IGD_BDSM, ~0);