QEMU/libvfio-user might use different VFIO headers

[tmakatos]

Discussion copied from Slack:

JJ pointed out that there can be seemingly unnoticed additions of members to structs, e.g. the addition of cap_offset to struct vfio_device_info (https://lore.kernel.org/qemu-devel/[email protected]/#Z30linux-headers:linux:vfio.h). IIUC this isn't accompanied by some VFIO version change. QEMU has it's own version of the VFIO headers, plus QEMU and libvfio-user can be compiled with different versions of VFIO headers anyway, so we need to figure out how to make sure they work in such cases.

[jlevon]

maybe we should ship with our own copy too

[tmakatos]

Actually, such incompatibilities are expected and they're solved by the argsz field. In this particular case there's a bug in libvfio-user:

int
handle_device_get_info(vfu_ctx_t *vfu_ctx, uint32_t size,
                       struct vfio_device_info *dev_info)
{
    assert(vfu_ctx != NULL);
    assert(dev_info != NULL);

    if (size != sizeof *dev_info) {
        return -EINVAL;
    }

We should be checking argsz and use struct vfio_device_info accordingly (e.g. don't access fields of the strcut whose offset is past argsz).

[tmakatos]

#232 fixes this specific problem, however I realize that we have a bigger problem because of the way we use the VFIO headers: if we assume that some struct member exists in some VFIO struct (e.g. struct vfio_device_info.cap_offset but the VFIO headers installed in the system don't have this recently-added member, libvfio-user will fail to compile.