[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200708132947.5b7ee954@x1.home>
Date: Wed, 8 Jul 2020 13:29:47 -0600
From: Alex Williamson <alex.williamson@...hat.com>
To: "Liu, Yi L" <yi.l.liu@...el.com>
Cc: Auger Eric <eric.auger@...hat.com>,
"baolu.lu@...ux.intel.com" <baolu.lu@...ux.intel.com>,
"joro@...tes.org" <joro@...tes.org>,
"Tian, Kevin" <kevin.tian@...el.com>,
"jacob.jun.pan@...ux.intel.com" <jacob.jun.pan@...ux.intel.com>,
"Raj, Ashok" <ashok.raj@...el.com>,
"Tian, Jun J" <jun.j.tian@...el.com>,
"Sun, Yi Y" <yi.y.sun@...el.com>,
"jean-philippe@...aro.org" <jean-philippe@...aro.org>,
"peterx@...hat.com" <peterx@...hat.com>,
"Wu, Hao" <hao.wu@...el.com>,
"stefanha@...il.com" <stefanha@...il.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: [PATCH v4 04/15] vfio/type1: Report iommu nesting info to
userspace
On Wed, 8 Jul 2020 08:08:40 +0000
"Liu, Yi L" <yi.l.liu@...el.com> wrote:
> Hi Alex,
>
> Eric asked if we will to have data strcut other than struct iommu_nesting_info
> type in the struct vfio_iommu_type1_info_cap_nesting @info[] field. I'm not
> quit sure on it. I guess the answer may be not as VFIO's nesting support should
> based on IOMMU UAPI. how about your opinion?
>
> +#define VFIO_IOMMU_TYPE1_INFO_CAP_NESTING 3
> +
> +/*
> + * Reporting nesting info to user space.
> + *
> + * @info: the nesting info provided by IOMMU driver. Today
> + * it is expected to be a struct iommu_nesting_info
> + * data.
> + */
> +struct vfio_iommu_type1_info_cap_nesting {
> + struct vfio_info_cap_header header;
> + __u32 flags;
> + __u32 padding;
> + __u8 info[];
> +};
It's not a very useful uAPI if the user can't be sure what they're
getting out of it. Info capabilities are "cheap", they don't need to
be as extensible as an ioctl. It's not clear that we really even need
the flags (and therefore the padding), just define it to return the
IOMMU uAPI structure with no extensibility. If we need to expose
something else, create a new capability. Thanks,
Alex
>
> https://lore.kernel.org/linux-iommu/DM5PR11MB1435290B6CD561EC61027892C3690@DM5PR11MB1435.namprd11.prod.outlook.com/
>
> Regards,
> Yi Liu
>
> > From: Liu, Yi L
> > Sent: Tuesday, July 7, 2020 5:32 PM
> >
> [...]
> > > >
> > > >>> +
> > > >>> +/*
> > > >>> + * Reporting nesting info to user space.
> > > >>> + *
> > > >>> + * @info: the nesting info provided by IOMMU driver. Today
> > > >>> + * it is expected to be a struct iommu_nesting_info
> > > >>> + * data.
> > > >> Is it expected to change?
> > > >
> > > > honestly, I'm not quite sure on it. I did considered to embed struct
> > > > iommu_nesting_info here instead of using info[]. but I hesitated as
> > > > using info[] may leave more flexibility on this struct. how about
> > > > your opinion? perhaps it's fine to embed the struct
> > > > iommu_nesting_info here as long as VFIO is setup nesting based on
> > > > IOMMU UAPI.
> > > >
> > > >>> + */
> > > >>> +struct vfio_iommu_type1_info_cap_nesting {
> > > >>> + struct vfio_info_cap_header header;
> > > >>> + __u32 flags;
> > > >> You may document flags.
> > > >
> > > > sure. it's reserved for future.
> > > >
> > > > Regards,
> > > > Yi Liu
> > > >
> > > >>> + __u32 padding;
> > > >>> + __u8 info[];
> > > >>> +};
> > > >>> +
> > > >>> #define VFIO_IOMMU_GET_INFO _IO(VFIO_TYPE, VFIO_BASE + 12)
> > > >>>
> > > >>> /**
> > > >>>
> > > >> Thanks
> > > >>
> > > >> Eric
> > > >
>
Powered by blists - more mailing lists