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

[Laszlo Ersek]

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.

--*--

I think we had the same discussion when Wei was working on SMBIOS 3.0
for ARM. In
<http://thread.gmane.org/gmane.comp.emulators.qemu/353282/focus=354806>,
you asked

"Is support for this all in the mainline kernel yet?"

I didn't really understand that question -- it didn't matter. QEMU as a
*platform* was learning how to provide a service that was governed by an
industry standard. The status of *guest* kernel support (and of guest
utility support) was irrelevant, in my opinion.

Thanks
Laszlo