From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 469F4C33CB2 for ; Fri, 31 Jan 2020 13:04:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1D7C620CC7 for ; Fri, 31 Jan 2020 13:04:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728590AbgAaNEg convert rfc822-to-8bit (ORCPT ); Fri, 31 Jan 2020 08:04:36 -0500 Received: from mga17.intel.com ([192.55.52.151]:56888 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728514AbgAaNEg (ORCPT ); Fri, 31 Jan 2020 08:04:36 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jan 2020 05:04:35 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,385,1574150400"; d="scan'208";a="402650842" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga005.jf.intel.com with ESMTP; 31 Jan 2020 05:04:35 -0800 Received: from shsmsx153.ccr.corp.intel.com (10.239.6.53) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 31 Jan 2020 05:04:34 -0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.197]) by SHSMSX153.ccr.corp.intel.com ([169.254.12.97]) with mapi id 14.03.0439.000; Fri, 31 Jan 2020 21:04:12 +0800 From: "Liu, Yi L" To: Alex Williamson CC: "eric.auger@redhat.com" , "Tian, Kevin" , "jacob.jun.pan@linux.intel.com" , "joro@8bytes.org" , "Raj, Ashok" , "Tian, Jun J" , "Sun, Yi Y" , "jean-philippe.brucker@arm.com" , "peterx@redhat.com" , "iommu@lists.linux-foundation.org" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: RE: [RFC v3 4/8] vfio/type1: Add VFIO_NESTING_GET_IOMMU_UAPI_VERSION Thread-Topic: [RFC v3 4/8] vfio/type1: Add VFIO_NESTING_GET_IOMMU_UAPI_VERSION Thread-Index: AQHV1pyVzTVYYyC090Ow388f+bA35qgBzDSAgALuTFA= Date: Fri, 31 Jan 2020 13:04:11 +0000 Message-ID: References: <1580299912-86084-1-git-send-email-yi.l.liu@intel.com> <1580299912-86084-5-git-send-email-yi.l.liu@intel.com> <20200129165649.43008300@w520.home> In-Reply-To: <20200129165649.43008300@w520.home> 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-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYTgxNzM5ZWQtYTU3Mi00MjE4LThlNjQtYzE3YmQ3NmRiZGU1IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiaXE0Skp3bEs4ZGJhdmNWd0dYY3F2VWdpamZjN1FNcHpvZ2pMM2JYZzkxSzR3VVBkSjJpc1Z5TXNOcFBCZ1crSyJ9 x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org Hi Alex, > From: Alex Williamson [mailto:alex.williamson@redhat.com] > Sent: Thursday, January 30, 2020 7:57 AM > To: Liu, Yi L > Subject: Re: [RFC v3 4/8] vfio/type1: Add > VFIO_NESTING_GET_IOMMU_UAPI_VERSION > > On Wed, 29 Jan 2020 04:11:48 -0800 > "Liu, Yi L" wrote: > > > From: Liu Yi L > > > > In Linux Kernel, the IOMMU nesting translation (a.k.a. IOMMU dual stage > > translation capability) is abstracted in uapi/iommu.h, in which the uAPIs > > like bind_gpasid/iommu_cache_invalidate/fault_report/pgreq_resp are defined. > > > > VFIO_TYPE1_NESTING_IOMMU stands for the vfio iommu type which is backed by > > IOMMU nesting translation capability. VFIO exposes the nesting capability > > to userspace and also exposes uAPIs (will be added in later patches) to user > > space for setting up nesting translation from userspace. Thus applications > > like QEMU could support vIOMMU for pass-through devices with IOMMU nesting > > translation capability. > > > > As VFIO expose the nesting IOMMU programming to userspace, it also needs to > > provide an API for the uapi/iommu.h version check to ensure compatibility. > > This patch reports the iommu uapi version to userspace. Applications could > > use this API to do version check before further using the nesting uAPIs. > > > > 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.c | 3 +++ > > include/uapi/linux/vfio.h | 10 ++++++++++ > > 2 files changed, 13 insertions(+) > > > > diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c > > index 425d60a..9087ad4 100644 > > --- a/drivers/vfio/vfio.c > > +++ b/drivers/vfio/vfio.c > > @@ -1170,6 +1170,9 @@ static long vfio_fops_unl_ioctl(struct file *filep, > > case VFIO_GET_API_VERSION: > > ret = VFIO_API_VERSION; > > break; > > + case VFIO_NESTING_GET_IOMMU_UAPI_VERSION: > > + ret = iommu_get_uapi_version(); > > + break; > > Shouldn't the type1 backend report this? It doesn't make much sense > that the spapr backend reports a version for something it doesn't > support. Better yet, provide this info gratuitously in the > VFIO_IOMMU_GET_INFO ioctl return like you do with nesting in the next > patch, then it can help the user figure out if this support is present. yeah, it would be better to report it by type1 backed. However, it is kind of issue when QEMU using it. My series "hooks" vSVA supports on VFIO_TYPE1_NESTING_IOMMU type. [RFC v3 09/25] vfio: check VFIO_TYPE1_NESTING_IOMMU support https://www.spinics.net/lists/kvm/msg205197.html In QEMU, it will determine the iommu type firstly and then invoke VFIO_SET_IOMMU. I think before selecting VFIO_TYPE1_NESTING_IOMMU, QEMU needs to check the IOMMU uAPI version. If IOMMU uAPI is incompatible, QEMU should not use VFIO_TYPE1_NESTING_IOMMU type. If VFIO_NESTING_GET_IOMMU_UAPI_VERSION is available after set iommu, then it may be an issue. That's why this series reports the version in vfio layer instead of type1 backend. Regards, Yi Liu