On Thu, 13 Feb 2020 10:39:57 -0700
Alex Williamson <alex.william...@redhat.com> wrote:
> On Thu, 13 Feb 2020 13:41:21 +0100
> Cornelia Huck <coh...@redhat.com> wrote:
>
> > On Tue, 11 Feb 2020 16:05:51 -0700
> > Alex Williamson <alex.william...@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.
