linux-kernel - RE: [PATCH v1 1/2] vfio:iommu: Use capabilities do report IOMMU informations

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]

Date:   Thu, 10 Jan 2019 00:55:07 +0000
From:   "Tian, Kevin" <kevin.tian@...el.com>
To:     Shameerali Kolothum Thodi <shameerali.kolothum.thodi@...wei.com>,
        "Alex Williamson" <alex.williamson@...hat.com>,
        Pierre Morel <pmorel@...ux.ibm.com>,
        "Raj, Ashok" <ashok.raj@...el.com>
CC:     "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "walling@...ux.ibm.com" <walling@...ux.ibm.com>,
        "cohuck@...hat.com" <cohuck@...hat.com>,
        "david@...hat.com" <david@...hat.com>,
        "pasic@...ux.ibm.com" <pasic@...ux.ibm.com>,
        "thuth@...hat.com" <thuth@...hat.com>,
        "Pan, Jacob jun" <jacob.jun.pan@...el.com>
Subject: RE: [PATCH v1 1/2] vfio:iommu: Use capabilities do report IOMMU
 informations

> From: Shameerali Kolothum Thodi
> [mailto:shameerali.kolothum.thodi@...wei.com]
> 
> > -----Original Message-----
> > From: Alex Williamson [mailto:alex.williamson@...hat.com]
> > Sent: 09 January 2019 15:37
> > To: Pierre Morel <pmorel@...ux.ibm.com>
> > Cc: kvm@...r.kernel.org; linux-kernel@...r.kernel.org;
> > walling@...ux.ibm.com; cohuck@...hat.com; david@...hat.com;
> > pasic@...ux.ibm.com; thuth@...hat.com; Shameerali Kolothum Thodi
> > <shameerali.kolothum.thodi@...wei.com>
> > Subject: Re: [PATCH v1 1/2] vfio:iommu: Use capabilities do report
> IOMMU
> > informations
> >
> > On Wed,  9 Jan 2019 13:41:53 +0100
> > Pierre Morel <pmorel@...ux.ibm.com> wrote:
> >
> > > We add a new flag, VFIO_IOMMU_INFO_CAPABILITIES, inside the
> > > vfio_iommu_type1_info to specify the support for capabilities.
> > >
> > > We add a new capability, with id VFIO_IOMMU_INFO_CAP_DMA
> > > in the capability list of the VFIO_IOMMU_GET_INFO ioctl.
> > >
> > > Signed-off-by: Pierre Morel <pmorel@...ux.ibm.com>
> > > ---
> > >  include/uapi/linux/vfio.h | 9 +++++++++
> > >  1 file changed, 9 insertions(+)
> > >
> > > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> > > index 8131028..54c4fcb 100644
> > > --- a/include/uapi/linux/vfio.h
> > > +++ b/include/uapi/linux/vfio.h
> > > @@ -669,6 +669,15 @@ struct vfio_iommu_type1_info {
> > >  	__u32	flags;
> > >  #define VFIO_IOMMU_INFO_PGSIZES (1 << 0)	/* supported page
> sizes
> > info */
> > >  	__u64	iova_pgsizes;		/* Bitmap of supported page sizes
> */
> > > +#define VFIO_IOMMU_INFO_CAPABILITIES (1 << 1)  /* support
> capabilities
> > info */
> > > +	__u64   cap_offset;     /* Offset within info struct of first cap */
> > > +};
> > > +
> > > +#define VFIO_IOMMU_INFO_CAP_DMA 1
> > > +struct vfio_iommu_cap_dma {
> > > +	struct vfio_info_cap_header header;
> > > +	__u64   dma_start;
> > > +	__u64   dma_end;
> > >  };
> > >
> > >  #define VFIO_IOMMU_GET_INFO _IO(VFIO_TYPE, VFIO_BASE + 12)
> >
> > Unfortunately for most systems, a simple start and end is not really
> > sufficient to describe the available IOVA space, there are often
> > reserved regions intermixed, so this is not really a complete
> > solution.  Shameer tried to solve this last year[1] but we ran into a
> > road block that Intel IGD devices impose a reserved range of IOVA
> > spaces reported to the user that conflict with existing assignment of
> > this device and we haven't figured out yet how to be more selective of
> > the enforcement of those reserved ranges.  Thanks,
> 
> Right. I had further discussions to unblock this at KVM forum/off-list with
> Intel folks and was promised some help.
> 
> IIRC the discussion was at, Kevin/Ashok will take another look on your
> proposed approach to exclude the RMRR[1] and see whether that is good
> enough or not.
> 
> Kevin/Ashok,
> 
> Please update if you had a chance to look into it.

+Jacob.

My recent check seems to indicate [1] possibly fine with IGD, but I'll let
Ashok/Jacob to double confirm and ack since they are the owner of 
intel-iommu driver. 

> 
> Thanks,
> Shameer
> 
> [1]. https://lkml.org/lkml/2018/6/5/897
> 
> > Alex
> >
> > [1] https://lkml.org/lkml/2018/4/18/293