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

[Michael S. Tsirkin]

On Fri, Oct 24, 2014 at 02:37:08PM +0200, Cornelia Huck wrote:
> On Fri, 24 Oct 2014 10:38:39 +0200
> Cornelia Huck <address@hidden> wrote:
> 
> > On Fri, 24 Oct 2014 00:42:20 +0300
> > "Michael S. Tsirkin" <address@hidden> 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.


Thanks!
Please note I have updated the branch several times - I'm not going to
send patches until next week.  I updated vhost net by now.
Just for the kernel, host side, we need to update tun, macvtap,
af_packet, vhost scsi and vhost test.
Guest side, we need to keep going over devices and convert them one by
one.
And of course qemu, including support for old and new tun/macvtap.

-- 
MST