qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] virtio-mmio: implement modern (v2) personality (v


From: Andrea Bolognani
Subject: Re: [Qemu-devel] [RFC] virtio-mmio: implement modern (v2) personality (virtio-1)
Date: Tue, 30 Jul 2019 14:17:48 +0200
User-agent: Evolution 3.32.4 (3.32.4-1.fc30)

On Tue, 2019-07-30 at 13:35 +0200, Cornelia Huck wrote:
> On Tue, 30 Jul 2019 12:25:30 +0200
> Andrea Bolognani <address@hidden> wrote:
> > Can you please make sure virtio-mmio uses the existing interface
> > instead of introducing a new one?
> 
> FWIW, I really hate virtio-pci's disable-modern/disable-legacy... for a
> starter, what is 'modern'? Will we have 'ultra-modern' in the future?

AIUI the modern/legacy terminology is part of the VirtIO spec, so
while I agree that it's not necessarily the least prone to ambiguity
at least it's well defined.

> It is also quite backwards with the 'disable' terminology.

That's also true. I never claimed the way virtio-pci does it is
perfect!

> We also have a different mechanism for virtio-ccw ('max_revision',
> which covers a bit more than virtio-1; it doesn't have a 'min_revision',
> as negotiating the revision down is fine), so I don't see why
> virtio-mmio should replicate the virtio-pci mechanism.
> 
> Also, IIUC, virtio-mmio does not have transitional devices, but either
> version 1 (legacy) or version 2 (virtio-1). It probably makes more
> sense to expose the device version instead; either as an exact version
> (especially if it isn't supposed to go up without incompatible
> changes), or with some min/max concept (where version 1 would stand a
> bit alone, so that would probably be a bit awkward.)

I think that if reinventing the wheel is generally agreed not to be
a good idea, then it stands to reason that reinventing it twice can
only be described as absolute madness :)

We should have a single way to control the VirtIO protocol version
that works for all VirtIO devices, regardless of transport. We might
even want to have virtio-*-{device,ccw}-non-transitional to mirror
the existing virtio-*-pci-non-transitional.

FWIW, libvirt already implements support for (non)-transitional
virtio-pci devices using either the dedicated devices or the base
virtio-pci plus the disable-{modern,legacy} attributes.

-- 
Andrea Bolognani / Red Hat / Virtualization




reply via email to

[Prev in Thread] Current Thread [Next in Thread]