From nobody Fri May 3 03:00:17 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 1488425598408733.7164949645967; Wed, 1 Mar 2017 19:33:18 -0800 (PST) Received: from localhost ([::1]:50117 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cjHUT-0001Wv-0d for importer@patchew.org; Wed, 01 Mar 2017 22:33:17 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40882) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cjHTl-0001V1-EQ for qemu-devel@nongnu.org; Wed, 01 Mar 2017 22:32:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cjHTi-0006ag-B4 for qemu-devel@nongnu.org; Wed, 01 Mar 2017 22:32:33 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54394) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cjHTi-0006aD-4y for qemu-devel@nongnu.org; Wed, 01 Mar 2017 22:32:30 -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 1011161B8D; Thu, 2 Mar 2017 03:32:30 +0000 (UTC) Received: from pxdev.xzpeter.org.com (ovpn-8-45.pek2.redhat.com [10.72.8.45]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v223WQKJ011466; Wed, 1 Mar 2017 22:32:26 -0500 From: Peter Xu To: qemu-devel@nongnu.org Date: Thu, 2 Mar 2017 11:32:18 +0800 Message-Id: <1488425538-13785-1-git-send-email-peterx@redhat.com> 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.39]); Thu, 02 Mar 2017 03:32:30 +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] [PATCH v3] intel_iommu: check misordered init when realize 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: , Cc: yi.l.liu@intel.com, "\\ Michael S . Tsirkin \\ " , Jason Wang , peterx@redhat.com, Alex Williamson , Marcel Apfelbaum , Paolo Bonzini , Jintack Lim Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Intel vIOMMU devices are created with "-device" parameter, while here actually we need to make sure the dmar device be created before other PCI devices (like vfio-pci, virtio-pci ones) so that we know iommu_fn will be setup correctly before realizations of those PCI devices (it is legal that PCI device fetch these info during its realization). Now this ordering yet cannot be achieved elsewhere, and devices will be created in the order that user specified. We need to avoid that. This patch tries to detect this kind of misordering issue during init of VT-d device, then report to guest if misordering happened. In the future, we can provide something better to solve it, e.g., to support device init ordering, then we can live without this patch. Signed-off-by: Peter Xu --- v3: added virtio-pci device detection since we have that requirement as well now. PS. this patch should be needed along with Jason's: "virtio: unbreak virtio-pci with IOMMU after caching ring translations" to make sure virtio devices with vt-d are safe for 2.9. --- hw/i386/intel_iommu.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c index 22d8226..1077f90 100644 --- a/hw/i386/intel_iommu.c +++ b/hw/i386/intel_iommu.c @@ -2560,6 +2560,24 @@ static bool vtd_decide_config(IntelIOMMUState *s, Er= ror **errp) return true; } =20 +/* + * TODO: we should have a better way to achieve the ordering rather + * than this misorder check explicitly against vfio-pci and virtio-pci + * devices. Here, there's no easy way to detect init of virtio-pci + * devices, instead we detect the virtio bus. + */ +static bool vtd_detected_misorder_init(Error **errp) +{ + if (object_resolve_path_type("", "vfio-pci", NULL) || + object_resolve_path_type("", "virtio-pci-bus", NULL)) { + error_setg(errp, "Please specify \"intel-iommu\" before " + "all the rest of the devices."); + return true; + } + + return false; +} + static void vtd_realize(DeviceState *dev, Error **errp) { PCMachineState *pcms =3D PC_MACHINE(qdev_get_machine()); @@ -2567,6 +2585,10 @@ static void vtd_realize(DeviceState *dev, Error **er= rp) IntelIOMMUState *s =3D INTEL_IOMMU_DEVICE(dev); X86IOMMUState *x86_iommu =3D X86_IOMMU_DEVICE(dev); =20 + if (vtd_detected_misorder_init(errp)) { + return; + } + VTD_DPRINTF(GENERAL, ""); x86_iommu->type =3D TYPE_INTEL; =20 --=20 2.7.4