lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <A2975661238FB949B60364EF0F2C25743A1994A2@SHSMSX104.ccr.corp.intel.com>
Date:   Fri, 31 Jan 2020 13:04:11 +0000
From:   "Liu, Yi L" <yi.l.liu@...el.com>
To:     Alex Williamson <alex.williamson@...hat.com>
CC:     "eric.auger@...hat.com" <eric.auger@...hat.com>,
        "Tian, Kevin" <kevin.tian@...el.com>,
        "jacob.jun.pan@...ux.intel.com" <jacob.jun.pan@...ux.intel.com>,
        "joro@...tes.org" <joro@...tes.org>,
        "Raj, Ashok" <ashok.raj@...el.com>,
        "Tian, Jun J" <jun.j.tian@...el.com>,
        "Sun, Yi Y" <yi.y.sun@...el.com>,
        "jean-philippe.brucker@....com" <jean-philippe.brucker@....com>,
        "peterx@...hat.com" <peterx@...hat.com>,
        "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [RFC v3 4/8] vfio/type1: Add VFIO_NESTING_GET_IOMMU_UAPI_VERSION

Hi Alex,

> From: Alex Williamson [mailto:alex.williamson@...hat.com]
> Sent: Thursday, January 30, 2020 7:57 AM
> To: Liu, Yi L <yi.l.liu@...el.com>
> 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" <yi.l.liu@...el.com> wrote:
> 
> > From: Liu Yi L <yi.l.liu@...el.com>
> >
> > 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 <kevin.tian@...el.com>
> > CC: Jacob Pan <jacob.jun.pan@...ux.intel.com>
> > Cc: Alex Williamson <alex.williamson@...hat.com>
> > Cc: Eric Auger <eric.auger@...hat.com>
> > Cc: Jean-Philippe Brucker <jean-philippe.brucker@....com>
> > Signed-off-by: Liu Yi L <yi.l.liu@...el.com>
> > ---
> >  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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ