Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp2383322ybb; Mon, 30 Mar 2020 05:14:43 -0700 (PDT) X-Google-Smtp-Source: ADFU+vuE0qL35EJ0mweesnG2sW232+Bx/Dmz/El1bNdy6kZuhBYrw9KcwrDygYSI2VWhImLtLgm+ X-Received: by 2002:a05:6830:10c2:: with SMTP id z2mr8507269oto.234.1585570482958; Mon, 30 Mar 2020 05:14:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585570482; cv=none; d=google.com; s=arc-20160816; b=Sq7oevOXckHhMgKPFuIhcFCSPJSBie4xYi8XHMLuVWFFlsqNtj2AsuNJ+5KScK9BkV +1fCR5TnytP8jngZTNr+fxSXrPh2PEASu8qFMumW5lLmCkhuaMvQ0mv6U/64EA86lvmG sV9MWyiRoSJGOgvEHY1UDKCWZsWlU7r9hs5kyxLVwrY9ACPQbm4zWgM7vJfbOkNtU55s y5vVJ+Hcs6RdWjNKLJNu/4UHThxew+tuj78NT2D7nekRAgwwKzd2m8y08cJIjvqlRC31 0xTeOm1CRZoi16u8q1lSCJ0RUCp/3mI2klx2CRHb/7xqRMu8MXo21joaICybBRbOJIND gt7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :dlp-reaction:dlp-version:dlp-product:content-language :accept-language:in-reply-to:references:message-id:date:thread-index :thread-topic:subject:cc:to:from:ironport-sdr:ironport-sdr; bh=NZvBzm8vIZn4Ug7za/6k9Xspiy6xnpTxmDg2yKVGo/o=; b=mwAtq1ifDdixJO5aJlzOVuVTwfSsNg2WbwTiHkRQQU4hbJSQYuTXM8QxlsprRegwLX Mgpsw2rsiJSYPypskdPcCfbLmCaBpBUd2/xv8AYzVbtZ0IvTDmkXv6ozSVXwofa/a9ei 70GpciQmJsTo11OMeicsrNvI1PP9fGoipo5D/V6lFLdkHclz9g88D0DwRRVIFf92oB8M nvohL76UTJgzWPzTN0VtfUhcCRRVhezf7mr0T7YY+R8rC0fzyqZy3ipqmgcScKEdk1fX UJlRiw0QDVkn+B9VD4un7ZGntnDZK14HnS4Xxby+swZxK57B/ZqDJ1dI6JN2lKTUCNz7 93hg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n125si5710301oib.97.2020.03.30.05.14.30; Mon, 30 Mar 2020 05:14:42 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729900AbgC3Lsy convert rfc822-to-8bit (ORCPT + 99 others); Mon, 30 Mar 2020 07:48:54 -0400 Received: from mga09.intel.com ([134.134.136.24]:30291 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728764AbgC3Lsy (ORCPT ); Mon, 30 Mar 2020 07:48:54 -0400 IronPort-SDR: lKWFHWNZYnlqaBmkSxOp+ICIPdzooc5adi49GeZB83dBcTb4g7dqgLCwdj5WMn3WuQ7JlH7Yq8 f6ISoez1kUMw== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Mar 2020 04:48:53 -0700 IronPort-SDR: 3n7ZaBt1QAtL8ckMyOn0+HIcWqDND4WEFimtAJUDCEPAMqYddkyHPVEF5IQ4bJL28vudceK//d 7+ieRaMumCaA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,324,1580803200"; d="scan'208";a="248674831" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga003.jf.intel.com with ESMTP; 30 Mar 2020 04:48:50 -0700 Received: from fmsmsx119.amr.corp.intel.com (10.18.124.207) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 30 Mar 2020 04:48:50 -0700 Received: from shsmsx106.ccr.corp.intel.com (10.239.4.159) by FMSMSX119.amr.corp.intel.com (10.18.124.207) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 30 Mar 2020 04:48:49 -0700 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.225]) by SHSMSX106.ccr.corp.intel.com ([169.254.10.89]) with mapi id 14.03.0439.000; Mon, 30 Mar 2020 19:48:46 +0800 From: "Tian, Kevin" To: "Liu, Yi L" , "alex.williamson@redhat.com" , "eric.auger@redhat.com" CC: "jacob.jun.pan@linux.intel.com" , "joro@8bytes.org" , "Raj, Ashok" , "Tian, Jun J" , "Sun, Yi Y" , "jean-philippe@linaro.org" , "peterx@redhat.com" , "iommu@lists.linux-foundation.org" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Wu, Hao" Subject: RE: [PATCH v1 5/8] vfio/type1: Report 1st-level/stage-1 format to userspace Thread-Topic: [PATCH v1 5/8] vfio/type1: Report 1st-level/stage-1 format to userspace Thread-Index: AQHWAEUcrRt83jyTNECgMYM7VBywiqhg9Y6g Date: Mon, 30 Mar 2020 11:48:45 +0000 Message-ID: References: <1584880325-10561-1-git-send-email-yi.l.liu@intel.com> <1584880325-10561-6-git-send-email-yi.l.liu@intel.com> In-Reply-To: <1584880325-10561-6-git-send-email-yi.l.liu@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > From: Liu, Yi L > Sent: Sunday, March 22, 2020 8:32 PM > > From: Liu Yi L > > VFIO exposes IOMMU nesting translation (a.k.a dual stage translation) > capability to userspace. Thus applications like QEMU could support > vIOMMU with hardware's nesting translation capability for pass-through > devices. Before setting up nesting translation for pass-through devices, > QEMU and other applications need to learn the supported 1st-lvl/stage-1 > translation structure format like page table format. > > Take vSVA (virtual Shared Virtual Addressing) as an example, to support > vSVA for pass-through devices, QEMU setup nesting translation for pass- > through devices. The guest page table are configured to host as 1st-lvl/ > stage-1 page table. Therefore, guest format should be compatible with > host side. > > This patch reports the supported 1st-lvl/stage-1 page table format on the > current platform to userspace. QEMU and other alike applications should > use this format info when trying to setup IOMMU nesting translation on > host IOMMU. > > Cc: Kevin Tian > CC: Jacob Pan > Cc: Alex Williamson > Cc: Eric Auger > Cc: Jean-Philippe Brucker > Signed-off-by: Liu Yi L > --- > drivers/vfio/vfio_iommu_type1.c | 56 > +++++++++++++++++++++++++++++++++++++++++ > include/uapi/linux/vfio.h | 1 + > 2 files changed, 57 insertions(+) > > diff --git a/drivers/vfio/vfio_iommu_type1.c > b/drivers/vfio/vfio_iommu_type1.c > index 9aa2a67..82a9e0b 100644 > --- a/drivers/vfio/vfio_iommu_type1.c > +++ b/drivers/vfio/vfio_iommu_type1.c > @@ -2234,11 +2234,66 @@ static int vfio_iommu_type1_pasid_free(struct > vfio_iommu *iommu, > return ret; > } > > +static int vfio_iommu_get_stage1_format(struct vfio_iommu *iommu, > + u32 *stage1_format) > +{ > + struct vfio_domain *domain; > + u32 format = 0, tmp_format = 0; > + int ret; > + > + mutex_lock(&iommu->lock); > + if (list_empty(&iommu->domain_list)) { > + mutex_unlock(&iommu->lock); > + return -EINVAL; > + } > + > + list_for_each_entry(domain, &iommu->domain_list, next) { > + if (iommu_domain_get_attr(domain->domain, > + DOMAIN_ATTR_PASID_FORMAT, &format)) { > + ret = -EINVAL; > + format = 0; > + goto out_unlock; > + } > + /* > + * format is always non-zero (the first format is > + * IOMMU_PASID_FORMAT_INTEL_VTD which is 1). For > + * the reason of potential different backed IOMMU > + * formats, here we expect to have identical formats > + * in the domain list, no mixed formats support. > + * return -EINVAL to fail the attempt of setup > + * VFIO_TYPE1_NESTING_IOMMU if non-identical formats > + * are detected. > + */ > + if (tmp_format && tmp_format != format) { > + ret = -EINVAL; > + format = 0; > + goto out_unlock; > + } > + > + tmp_format = format; > + } this path is invoked only in VFIO_IOMMU_GET_INFO path. If we don't want to assume the status quo that one container holds only one device w/ vIOMMU (the prerequisite for vSVA), looks we also need check the format compatibility when attaching a new group to this container? > + ret = 0; > + > +out_unlock: > + if (format) > + *stage1_format = format; > + mutex_unlock(&iommu->lock); > + return ret; > +} > + > static int vfio_iommu_info_add_nesting_cap(struct vfio_iommu *iommu, > struct vfio_info_cap *caps) > { > struct vfio_info_cap_header *header; > struct vfio_iommu_type1_info_cap_nesting *nesting_cap; > + u32 formats = 0; > + int ret; > + > + ret = vfio_iommu_get_stage1_format(iommu, &formats); > + if (ret) { > + pr_warn("Failed to get stage-1 format\n"); > + return ret; > + } > > header = vfio_info_cap_add(caps, sizeof(*nesting_cap), > VFIO_IOMMU_TYPE1_INFO_CAP_NESTING, > 1); > @@ -2254,6 +2309,7 @@ static int vfio_iommu_info_add_nesting_cap(struct > vfio_iommu *iommu, > /* nesting iommu type supports PASID requests (alloc/free) > */ > nesting_cap->nesting_capabilities |= > VFIO_IOMMU_PASID_REQS; > } > + nesting_cap->stage1_formats = formats; > > return 0; > } > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h > index ed9881d..ebeaf3e 100644 > --- a/include/uapi/linux/vfio.h > +++ b/include/uapi/linux/vfio.h > @@ -763,6 +763,7 @@ struct vfio_iommu_type1_info_cap_nesting { > struct vfio_info_cap_header header; > #define VFIO_IOMMU_PASID_REQS (1 << 0) > __u32 nesting_capabilities; > + __u32 stage1_formats; do you plan to support multiple formats? If not, use singular name. > }; > > #define VFIO_IOMMU_GET_INFO _IO(VFIO_TYPE, VFIO_BASE + 12) > -- > 2.7.4