From nobody Mon Oct 13 23:45:44 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=intel.com ARC-Seal: i=1; a=rsa-sha256; t=1582358749; cv=none; d=zohomail.com; s=zohoarc; b=S20WXSYXOsgOgN++lqHqpCSJOveEI1NKgnTvLFsCxLoO+I9wndQEVxUrX+LWHc3UWFQOz/Ko7l6CVbpS8oDa8TWdC6CgQRB+tTY5zx2xUmA2bzjJxyUPHCHigPz7FoRAGDPjAvOIBScjrJ8oPZGlunEhhp7QLC/ZnSNGEoZcv3g= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1582358749; h=Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:Message-ID:References:Sender:Subject:To; bh=iY8E7nJrOzlOcOsGEnnLKyy03nPnvF1bjNMQkHB1oo4=; b=QxgqNtGUQwFhGEGZ11FNUL/Lf9OisHP2/TxciiAAlEMYycuHPZ8J57TJfC9iVsumCqSaAC4Zbnb7kLP0FmhQd4ilpah8+h31DK1+ujpbxwWL94ub0zFZgAzw9tN/Py4YtcbNRyjgstxIKs0ayZY0ZQGagZGRK0bKT8tZrvXt9O0= ARC-Authentication-Results: i=1; mx.zohomail.com; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1582358749572629.3817865836916; Sat, 22 Feb 2020 00:05:49 -0800 (PST) Received: from localhost ([::1]:39934 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j5PnI-0007R2-K7 for importer@patchew.org; Sat, 22 Feb 2020 03:05:48 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:57514) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j5Pjm-0002BR-0S for qemu-devel@nongnu.org; Sat, 22 Feb 2020 03:02:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j5Pjj-00082i-AX for qemu-devel@nongnu.org; Sat, 22 Feb 2020 03:02:09 -0500 Received: from mga17.intel.com ([192.55.52.151]:49238) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1j5Pjj-0007tq-0I for qemu-devel@nongnu.org; Sat, 22 Feb 2020 03:02:07 -0500 Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Feb 2020 00:01:58 -0800 Received: from jacob-builder.jf.intel.com ([10.7.199.155]) by orsmga006.jf.intel.com with ESMTP; 22 Feb 2020 00:01:57 -0800 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,471,1574150400"; d="scan'208";a="240547702" From: Liu Yi L To: qemu-devel@nongnu.org, alex.williamson@redhat.com, peterx@redhat.com Subject: [RFC v3.1 17/22] intel_iommu: do not pass down pasid bind for PASID #0 Date: Sat, 22 Feb 2020 00:07:18 -0800 Message-Id: <1582358843-51931-18-git-send-email-yi.l.liu@intel.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1582358843-51931-1-git-send-email-yi.l.liu@intel.com> References: <1582358843-51931-1-git-send-email-yi.l.liu@intel.com> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 192.55.52.151 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kevin.tian@intel.com, yi.l.liu@intel.com, Yi Sun , Eduardo Habkost , kvm@vger.kernel.org, mst@redhat.com, jun.j.tian@intel.com, eric.auger@redhat.com, yi.y.sun@intel.com, Jacob Pan , pbonzini@redhat.com, Richard Henderson , david@gibson.dropbear.id.au Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" RID_PASID field was introduced in VT-d 3.0 spec, it is used for DMA requests w/o PASID in scalable mode VT-d. It is also known as IOVA. And in VT-d 3.1 spec, there is definition on it: "Implementations not supporting RID_PASID capability (ECAP_REG.RPS is 0b), use a PASID value of 0 to perform address translation for requests without PASID." This patch adds a check against the PASIDs which are going to be bound to device. For PASID #0, it is not necessary to pass down pasid bind request for it since PASID #0 is used as RID_PASID for DMA requests without pasid. Further reason is current Intel vIOMMU supports gIOVA by shadowing guest 2nd level page table. However, in future, if guest IOMMU driver uses 1st level page table to store IOVA mappings, then guest IOVA support will also be done via nested translation. When gIOVA is over FLPT, then vIOMMU should pass down the pasid bind request for PASID #0 to host, host needs to bind the guest IOVA page table to a proper PASID. e.g PASID value in RID_PASID field for PF/VF if ECAP_REG.RPS is clear or default PASID for ADI (Assignable Device Interface in Scalable IOV solution). IOVA over FLPT support on Intel VT-d: https://lkml.org/lkml/2019/9/23/297 Cc: Kevin Tian Cc: Jacob Pan Cc: Peter Xu Cc: Yi Sun Cc: Paolo Bonzini Cc: Richard Henderson Cc: Eduardo Habkost Signed-off-by: Liu Yi L --- hw/i386/intel_iommu.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c index b85aad3..cacc38b 100644 --- a/hw/i386/intel_iommu.c +++ b/hw/i386/intel_iommu.c @@ -1883,6 +1883,16 @@ static int vtd_bind_guest_pasid(IntelIOMMUState *s, = VTDBus *vtd_bus, PCIDevice *dev; int ret =3D -1; =20 + if (pasid < VTD_MIN_HPASID) { + /* + * If pasid < VTD_HPASID_MIN, this pasid is not allocated + * from host. No need to pass down the changes on it to host. + * TODO: when IOVA over FLPT is ready, this switch should be + * refined. + */ + return 0; + } + dev =3D vtd_bus->bus->devices[devfn]; host_icx =3D pci_device_host_iommu_context(dev); if (!host_icx) { --=20 2.7.4