[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5FC3163CFD30C246ABAA99954A238FA8388B1270@FRAEML521-MBS.china.huawei.com>
Date: Wed, 9 Jan 2019 17:08:46 +0000
From: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@...wei.com>
To: Alex Williamson <alex.williamson@...hat.com>,
Pierre Morel <pmorel@...ux.ibm.com>,
"ashok.raj@...el.com" <ashok.raj@...el.com>,
"Tian, Kevin" <kevin.tian@...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>
Subject: RE: [PATCH v1 1/2] vfio:iommu: Use capabilities do report IOMMU
informations
> -----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.
Thanks,
Shameer
[1]. https://lkml.org/lkml/2018/6/5/897
> Alex
>
> [1] https://lkml.org/lkml/2018/4/18/293
Powered by blists - more mailing lists