Re: [PATCH 4/7] vfio: Introduce VFIO_DEVICE_FEATURE ioctl and first user

Cornelia Huck
2020-02-13T18:08:30Z

On Thu, 13 Feb 2020 10:39:57 -0700
Alex Williamson <alex.williamson@redhat.com> wrote:

> On Thu, 13 Feb 2020 13:41:21 +0100
> Cornelia Huck <cohuck@redhat.com> wrote:
>
> > On Tue, 11 Feb 2020 16:05:51 -0700
> > Alex Williamson <alex.williamson@redhat.com> wrote:

> > > +struct vfio_device_feature {
> > > + __u32 argsz;
> > > + __u32 flags;
> > > +#define VFIO_DEVICE_FEATURE_MASK (0xffff) /* 16-bit feature index */
> > > +#define VFIO_DEVICE_FEATURE_GET (1 << 16) /* Get feature into data[] */
> > > +#define VFIO_DEVICE_FEATURE_SET (1 << 17) /* Set feature from data[] */
> > > +#define VFIO_DEVICE_FEATURE_PROBE (1 << 18) /* Probe feature support */
> > > + __u8 data[];
> > > +};
> >
> > I'm not sure I'm a fan of cramming both feature selection and operation
> > selection into flags. What about:
> >
> > struct vfio_device_feature {
> > __u32 argsz;
> > __u32 flags;
> > /* GET/SET/PROBE #defines */
> > __u32 feature;
> > __u8 data[];
> > };
>
> Then data is unaligned so we either need to expand feature or add
> padding. So this makes the structure at least 8 bytes bigger and buys
> us...? What's so special about the bottom half of flags that we can't
> designate it as the flags that specify the feature? We still have
> another 13 bits of flags for future use.

It is more my general dislike of bit fiddling here, no strong
objection, certainly.

>
> > Getting/setting more than one feature at the same time does not sound
> > like a common use case; you would need to specify some kind of
> > algorithm for that anyway, and just doing it individually seems much
> > easier than that.
>
> Yup. I just figured 2^16 features is a nice way to make use of the
> structure vs 2^32 features and 4 bytes of padding or 2^64 features. I
> don't think I'm being optimistic in thinking we'll have far less than
> 16K features and we can always reserve feature 0xffff as an extended
> feature where the first 8-bytes of data defines that extended feature
> index.

Agreed, we're probably not going to end up with a flood of features
here.

Anyway, much of this seems to be a matter of personal taste, so let's
keep it as it is.