qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 0/4] virtio-ccw: virtio-1 enablement


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH 0/4] virtio-ccw: virtio-1 enablement
Date: Thu, 25 Jun 2015 14:49:00 +0200

On Thu, Jun 25, 2015 at 12:24:40PM +0200, Cornelia Huck wrote:
> On Tue, 23 Jun 2015 19:19:39 +0200
> Cornelia Huck <address@hidden> wrote:
> 
> > On Tue, 23 Jun 2015 18:36:34 +0200
> > Thomas Huth <address@hidden> wrote:
> > 
> > > On Tue, 23 Jun 2015 13:17:32 +0200
> > > Cornelia Huck <address@hidden> wrote:
> > > 
> > > > Michael,
> > > > 
> > > > here's the virtio-ccw patches that Gerd had dropped due to conflicts
> > > > during his virtio-1 rebase. Patch 2 has been updated with my changes
> > > > to ensure big endian accesses (which was a separate patch before).
> > > > 
> > > > There might be more patches that were in my tree but are not yet 
> > > > upstream,
> > > > but I'm still digging myself out from under the post-vacation email 
> > > > pile.
> > > > 
> > > > I think these can still go into 2.4.
> > > 
> > > Is it safe enough to enable them by default already? If I've got
> > > the virtio-pci code right (see the patch description at
> > > https://lists.gnu.org/archive/html/qemu-devel/2015-06/msg01362.html),
> > > it is still disabled there by default - and "modern will be turned on by
> > > default once all remaining spec compilance issues are addressed".
> > 
> > I was about to say "yes" when I noticed that we probably want to care
> > about migrating dev->revision as well... I'll drop patch 4 for now and
> > just send patches 1-3 from this series.
> 
> On a second thought, I can simply include dev->revision, as we have the
> incompatible ->config_vector change for this release already. I'll
> include a new patch for this and patch 4 as well, as we only need to
> care about Linux guests on ccw for now and those are fine.

I don't think enable by default is a good idea for 2.4 since
I think we have spec compliance issues which just don't
trigger with linux guests. For example, devices poke at
rings before DRIVER_OK is set.

If we release QEMU like this, guests will have to work
around these issues, which is not nice.
Let's release 2.4 in disabled by default mode, and flip
it around for 2.5.

-- 
MST



reply via email to

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