> From: Shameerali Kolothum Thodi > [mailto:shameerali.kolothum.thodi@xxxxxxxxxx] > > > -----Original Message----- > > From: Alex Williamson [mailto:alex.williamson@xxxxxxxxxx] > > Sent: 09 January 2019 15:37 > > To: Pierre Morel <pmorel@xxxxxxxxxxxxx> > > Cc: kvm@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > > walling@xxxxxxxxxxxxx; cohuck@xxxxxxxxxx; david@xxxxxxxxxx; > > pasic@xxxxxxxxxxxxx; thuth@xxxxxxxxxx; Shameerali Kolothum Thodi > > <shameerali.kolothum.thodi@xxxxxxxxxx> > > 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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> > > > --- > > > 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
