Re: [Qemu-devel] [PATCH v6 3/4] vfio: vfio-pci device assignment driver

[Alex Williamson <alex.williamson@redhat.com>]

On Fri, 2012-10-05 at 18:05 +0000, Blue Swirl wrote:
> On Fri, Oct 5, 2012 at 5:33 PM, Alex Williamson
> <alex.williamson@redhat.com> wrote:
> > On Fri, 2012-10-05 at 17:22 +0000, Blue Swirl wrote:
> >> On Fri, Oct 5, 2012 at 5:11 PM, Alex Williamson
> >> <alex.williamson@redhat.com> wrote:
> >> > On Fri, 2012-10-05 at 16:54 +0000, Blue Swirl wrote:
> >> >> On Wed, Sep 26, 2012 at 5:19 PM, Alex Williamson
> >> >> <alex.williamson@redhat.com> wrote:
> >> >> > +
> >> >> > +typedef struct QEMU_PACKED VFIOIRQSetFD {
> >> >> > +    struct vfio_irq_set irq_set;
> >> >> > +    int32_t fd;
> >> >> > +} VFIOIRQSetFD;
> >> >>
> >> >> I'm now getting this error from Clang:
> >> >>
> >> >> /src/qemu/hw/vfio_pci.c:126:25: error: field 'irq_set' with variable
> >> >> sized type 'struct vfio_irq_set' not at the end of a struct or class
> >> >> is a GNU extension [-Werror,-Wgnu]
> >> >>     struct vfio_irq_set irq_set;
> >> >>
> >> >> Does the kernel really use the fd field, isn't it implicit from the
> >> >> ioctl fd or are they different?
> >> >
> >> > The kernel side is defined as:
> >> >
> >> > struct vfio_irq_set {
> >> >         __u32   argsz;
> >> >         __u32   flags;
> >> >         __u32   index;
> >> >         __u32   start;
> >> >         __u32   count;
> >> >         __u8    data[];
> >> > };
> >>
> >> Then the kernel only expects vfio_irq_set structure, not VFIOIRQSetFD,
> >> so you should use &irq_set_fd.irq_set instead of &irq_set_fd for the
> >> ioctl(). Then VFIOIRQSetFD can be rearranged to have fd field first,
> >> also QEMU_PACKED is not necessary.
> >
> > Sorry, I was unclear.  The kernel sees fd as data[0], that's the point
> > of the structure, so re-arranging it makes it useless.  Thanks,
> 
> I see. The example in GCC shows how to statically initialize flexible
> array members properly but it does not seem to work:
> http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html

That's not going to like that the data type is actually different for
this use case.

> Also, Clang does not like that syntax either.
> 
> Maybe it's best to use g_malloc with room for the extra int.

:(  Ok, I'll write a patch to make it dynamically allocated.  Thanks,

Alex