Re: [Qemu-devel] virtio-gpu doesn't build if you do a linux-headers update from kvm/next

[Cornelia Huck]

On Thu, 5 Nov 2015 18:15:04 +0100
Laszlo Ersek <address@hidden> wrote:

> On 11/05/15 16:11, Peter Maydell wrote:
> > On 5 November 2015 at 14:58, Gerd Hoffmann <address@hidden> wrote:
> >> On Do, 2015-11-05 at 14:45 +0000, Peter Maydell wrote:
> >>> On 5 November 2015 at 14:42, Gerd Hoffmann <address@hidden> wrote:
> >>>> Chicken & egg issue in that case because airlied (linux kernel drm
> >>>> maintainer) asked to have the qemu changes merged before taking the
> >>>> virtio-gpu pull request.  So I had no other chance than creating the
> >>>> patches with not-yet upstream virtio header changes ...
> >>>
> >>> Hmm. If I'd realised that at the time I'd have pushed back on it.
> >>> We should never take code that relies on upstream kernel
> >>> ABI that hasn't been accepted by the maintainer yet.
> >>
> >> The reason airlied asked for qemu being upstream first is to avoid
> >> having code in the kernel tree not accepted by qemu yet ...
> >>
> >> So, one of the two has to go first ;)
> > 
> > Right, but this isn't a symmetrical arrangement. If on the
> > kernel side the ABI is changed before it's finally accepted
> > into mainline, that means that any QEMU that got released with
> > changes made on the basis of not-yet-upstream kernel patches
> > will be broken. But if the kernel accepts code which needs a
> > not-yet-in-qemu feature to be useful, that doesn't break the
> > kernel, because the kernel isn't actually dependent on the
> > QEMU changes. That's why I think the kernel side of the ABI
> > always needs to go first (the kernel provides the ABI, QEMU
> > uses it, never the other way around).
> 
> I could be confused about what ABI means, but in case of *guest* kernel
> drivers (for virtual devices provided by QEMU), the dependency seems to
> be the opposite.
> 
> Alex mentioned "kernel uapi includes" up-thread. To be honest, I don't
> know what "uapi" means here. Are those headers there to be relied upon
> by userspace processes that need services from the kernel? That would
> match your above argument.
> 
> However, I found the following files there:
> 
> include/uapi/linux/virtio_console.h
> include/uapi/linux/virtio_input.h
> include/uapi/linux/virtio_net.h
> include/uapi/linux/virtio_types.h
> include/uapi/linux/virtio_9p.h
> include/uapi/linux/virtio_balloon.h
> include/uapi/linux/virtio_scsi.h
> include/uapi/linux/virtio_rng.h
> include/uapi/linux/virtio_ids.h
> include/uapi/linux/virtio_ring.h
> include/uapi/linux/virtio_pci.h
> include/uapi/linux/virtio_gpu.h
> include/uapi/linux/virtio_config.h
> include/uapi/linux/virtio_blk.h
> 
> Which kinda confuses me. I cannot imagine that a userspace process
> should depend on these, for the purpose of consuming kernel services.
> Instead, QEMU should *definitely* dictate in this case, because it
> provides the service (the hardware), and Linux has drivers that consume
> that service.
> 
> Consider: there are virtio drivers in SeaBIOS, OVMF, and Windows too.
> Should QEMU include their header files as well? I think not.
> 
> In other words, I agree with your argument, and the "QEMU depends on the
> kernel" statement, as far as QEMU plays the role of a userspace process
> that consumes the *host* kernel's services (VFIO, KVM, ...).
> 
> However, when QEMU provides the *hardware* (which is hopefully described
> by an industry standard, or at least by some kind of independent
> documentation), then the *guest* kernel plays the consumer role (as do
> other non-Linux-kernel guests), and in that case the QEMU changes should
> go in first (hopefully after testing them with the under-development
> guest code, of course).
> 
> Hence, I'm leaning to think that the above virtio header files should
> not be under uapi *at all*. They should be under "include/virtio", and
> should be private to the guest drivers.

The virtio case is more of a convenience issue.

The *canonical* definitions for virtio implementations are neither in
the kernel nor in qemu, but only in the standard. We can't conveniently
pull headers (for Linux and qemu) from a third place, so we make sure
that the Linux headers implement the standard and have qemu pull them
(this is probably also a corollary of mostly the same people working on
the Linux and qemu implementations).

IOW, I think in the virtio case *both* Linux and qemu are consumers.
The setup is as-is as it seems to be most convenient for the developers
involved.

(There has been discussion on this before, which I'm too lazy to dig up
right now.)