Re: [PATCH RFC 00/11] qemu: towards virtio-1 host support

[Cornelia Huck <cornelia.huck@de.ibm.com>]

On Fri, 24 Oct 2014 10:38:39 +0200
Cornelia Huck <cornelia.huck@de.ibm.com> wrote:

> On Fri, 24 Oct 2014 00:42:20 +0300
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> 
> > On Tue, Oct 07, 2014 at 04:39:56PM +0200, Cornelia Huck wrote:
> > > This patchset aims to get us some way to implement virtio-1 compliant
> > > and transitional devices in qemu. Branch available at
> > > 
> > > git://github.com/cohuck/qemu virtio-1
> > > 
> > > I've mainly focused on:
> > > - endianness handling
> > > - extended feature bits
> > > - virtio-ccw new/changed commands
> > 
> > So issues identified so far:
> 
> Thanks for taking a look.
> 
> > - devices not converted yet should not advertize 1.0
> 
> Neither should an uncoverted transport. So we either can
> - have transport set the bit and rely on devices ->get_features
>   callback to mask it out
>   (virtio-ccw has to change the calling order for get_features, btw.)
> - have device set the bit and the transport mask it out later. Feels a
>   bit weird, as virtio-1 is a transport feature bit.
> 
> I'm tending towards the first option; smth like this (on top of my
> branch):

(...)

OK, I played around with this patch on top and the vhost-next branch as
guest. It seems to work reasonably well so far: a virtio-blk device
used virtio-1, a virtio-balloon device legacy.

One thing I noticed, though, is that I may need to think about
virtio-ccw revision vs. virtio version again. As a device can refuse
virtio-1 after the driver negotiated revision 1, we're operating a
legacy device with (some) standard ccws. Probably not a big deal, as
(a) both driver and device already have indicated that they support
revision 1 which those ccws are tied to and (b) some legacy
devices/drivers already support standard ccws (adapter interrupt
support). I might want to clarify the standard a bit, let me think
about that over the weekend.