From nobody Sun May 5 19:02:41 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 1487910702627921.5216303089729; Thu, 23 Feb 2017 20:31:42 -0800 (PST) Received: from localhost ([::1]:34588 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ch7Xg-0007Ce-Sr for importer@patchew.org; Thu, 23 Feb 2017 23:31:40 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50827) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ch7Vk-0006KW-Pw for qemu-devel@nongnu.org; Thu, 23 Feb 2017 23:29:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ch7Vh-0008TB-N1 for qemu-devel@nongnu.org; Thu, 23 Feb 2017 23:29:40 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41612) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ch7Vh-0008Sz-Ge for qemu-devel@nongnu.org; Thu, 23 Feb 2017 23:29:37 -0500 Received: from smtp.corp.redhat.com (int-mx16.intmail.prod.int.phx2.redhat.com [10.5.11.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6B82C7E9FC; Fri, 24 Feb 2017 04:29:37 +0000 (UTC) Received: from pxdev.xzpeter.org.com (ovpn-8-41.pek2.redhat.com [10.72.8.41]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3645B1DCC0; Fri, 24 Feb 2017 04:29:33 +0000 (UTC) From: Peter Xu To: qemu-devel@nongnu.org Date: Fri, 24 Feb 2017 12:29:21 +0800 Message-Id: <1487910561-17825-1-git-send-email-peterx@redhat.com> X-Scanned-By: MIMEDefang 2.74 on 10.5.11.28 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Fri, 24 Feb 2017 04:29: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] [PATCH v2] 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 \\ " , peterx@redhat.com, Alex Williamson , Marcel Apfelbaum , 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) so that we know iommu_fn will be setup correctly before realizations of those PCI devices (it is sensible 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. That might be dangerous. Here we add one more function to detect this kind of misordering issue, then report to guest. Currently, the only known device that is affected by this VT-d defect is the vfio-pci typed devices. So for now we just check against it to make sure we are safe. Signed-off-by: Peter Xu --- 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..b723ece 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. After all, no + * one should be blamed for this, and vfio-pci did nothing wrong. + */ +static bool vtd_detected_misorder_init(Error **errp) +{ + Object *dev =3D object_resolve_path_type("", "vfio-pci", NULL); + + if (dev) { + error_setg(errp, "Please specify \"intel-iommu\" before all the re= st " + "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