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

[Alex Bennée]

Laszlo Ersek <address@hidden> writes:

> 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.

Well sort of, for guests using virtio devices both the kernel and QEMU
should be following the spec defined API (so guests being run under any
random virtio hypervisor work the same).

> 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.

In this case the Userspace API the kernel provides to userspace which
QEMU is one user (in fact in the KVM kernel code anything that controls
the hypervisor is just referred to as userspace).

My bias is showing of course because I'm not considering guests here,
QEMU is the user of the kernel API. I'm thinking of things like the
KVM_RUN structure and the various ioctls and knobs for interaction
between KVM and QEMU.

>
> 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.

That's an interesting point. I suspect in this case QEMU is using the
Linux defined headers as a handy implementation of the virtio specs.

>
> --*--
>
> 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.

No there are plenty of examples, for example in my case guest debug
support requires a new kernel API which is only declared stable once
it passes review and gets merged into mainline.

-- 
Alex Bennée