From patchwork Fri Jul 5 11:01:51 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yi Liu X-Patchwork-Id: 11033725 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 67745912 for ; Sat, 6 Jul 2019 11:32:46 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4E7A728767 for ; Sat, 6 Jul 2019 11:32:46 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 2BED42877B; Sat, 6 Jul 2019 11:32:46 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.9 required=2.0 tests=BAYES_00,DATE_IN_PAST_24_48, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=unavailable version=3.3.1 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id C329628767 for ; Sat, 6 Jul 2019 11:32:45 +0000 (UTC) Received: from localhost ([::1]:58846 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hjivs-0007m1-Rl for patchwork-qemu-devel@patchwork.kernel.org; Sat, 06 Jul 2019 07:32:44 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52701) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hjije-0003TD-U0 for qemu-devel@nongnu.org; Sat, 06 Jul 2019 07:20:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hjijd-0006WB-SL for qemu-devel@nongnu.org; Sat, 06 Jul 2019 07:20:06 -0400 Received: from mga14.intel.com ([192.55.52.115]:2961) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hjijd-0005e0-Hc for qemu-devel@nongnu.org; Sat, 06 Jul 2019 07:20:05 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jul 2019 04:19:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.63,458,1557212400"; d="scan'208";a="363355079" Received: from yiliu-dev.bj.intel.com ([10.238.156.139]) by fmsmga005.fm.intel.com with ESMTP; 06 Jul 2019 04:19:39 -0700 From: Liu Yi L To: qemu-devel@nongnu.org, mst@redhat.com, pbonzini@redhat.com, alex.williamson@redhat.com, peterx@redhat.com Date: Fri, 5 Jul 2019 19:01:51 +0800 Message-Id: <1562324511-2910-19-git-send-email-yi.l.liu@intel.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1562324511-2910-1-git-send-email-yi.l.liu@intel.com> References: <1562324511-2910-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.115 Subject: [Qemu-devel] [RFC v1 18/18] intel_iommu: do not passdown pasid bind for PASID #0 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: tianyu.lan@intel.com, kevin.tian@intel.com, yi.l.liu@intel.com, Yi Sun , kvm@vger.kernel.org, jun.j.tian@intel.com, eric.auger@redhat.com, yi.y.sun@intel.com, Jacob Pan , david@gibson.dropbear.id.au Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP 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 further 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 on the PASIDs which are going to be bound to device. For PASID #0, no need to passdown pasid binding since PASID #0 is used as RID_PASID for requests without pasid. Reason is current Intel vIOMMU supports guest IOVA by shadowing guest 2nd level page table. However, in future, if guest OS uses 1st level page table to store IOVA mappings, thus guest IOVA support will also be done via nested translation in host side. Then vIOMMU could passdown the pasid binding for PASID #0 to host with a special PASID value. A special PASID value is to indicate host to bind the guest page table to a proper PASID. e.g PASID value from RID_PASID field for PF/VF or default PASID for ADI (Assignable Device Interface in Scalable IOV solution). Cc: Kevin Tian Cc: Jacob Pan Cc: Peter Xu Cc: Yi Sun Signed-off-by: Liu Yi L --- hw/i386/intel_iommu.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c index e4286e5..ee55209 100644 --- a/hw/i386/intel_iommu.c +++ b/hw/i386/intel_iommu.c @@ -1853,6 +1853,14 @@ static void vtd_bind_guest_pasid(IntelIOMMUState *s, int bus_n, { PCIBus *bus; struct gpasid_bind_data *g_bind_data; + + if (pasid < VTD_MIN_HPASID) { + /* + * If pasid < VTD_HPASID_MIN, this pasid is not allocated + * from host. No need to passdown the changes on it to host. + */ + return; + } bus = vtd_find_pci_bus_from_bus_num(s, bus_n); g_bind_data = g_malloc0(sizeof(*g_bind_data));