On Thu, 5 Nov 2015 18:15:04 +0100 Laszlo Ersek <ler...@redhat.com> wrote:
> On 11/05/15 16:11, Peter Maydell wrote: > > On 5 November 2015 at 14:58, Gerd Hoffmann <kra...@redhat.com> wrote: > >> On Do, 2015-11-05 at 14:45 +0000, Peter Maydell wrote: > >>> On 5 November 2015 at 14:42, Gerd Hoffmann <kra...@redhat.com> 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.)
