qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 0/6] virtio: refactor host notifiers


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH 0/6] virtio: refactor host notifiers
Date: Tue, 29 Mar 2016 16:38:06 +0300

On Tue, Mar 29, 2016 at 03:23:57PM +0200, Christian Borntraeger wrote:
> On 03/24/2016 05:15 PM, Cornelia Huck wrote:
> > Here's the next version of my refactoring of the virtio host notifiers.
> > This one actually survives a bit of testing for me (reboot loop).
> > 
> > As this patchset fixes a latent bug exposed by the recent dataplane
> > changes (we have a deassigned ioeventfd for a short period of time
> > during dataplane start, which leads to the virtqueue handler being
> > called in both the vcpu thread and the iothread simultaneously), I'd
> > like to see this in 2.6.
> > 
> > Changes from RFC:
> > - Fixed some silly errors (checking for !disabled instead of disabled,
> >   virtio_ccw_stop_ioeventfd() calling virtio_bus_start_ioeventfd()).
> > - Completely reworked set_host_notifier(): We only want to set/unset
> >   the actual handler function and don't want to do anything to the
> >   ioeventfd backing, so reduce the function to actually doing only
> >   that.
> > - With the change above, we can lose the 'assign' parameter in
> >   virtio_bus_stop_ioeventfd() again.
> > - Added more comments that hopefully make it clearer what is going on.
> > 
> > I'd appreciate it if people could give it some testing; I'll be back
> > to look at the fallout after Easter.
> > 
> > Cornelia Huck (6):
> >   virtio-bus: common ioeventfd infrastructure
> >   virtio-bus: have callers tolerate new host notifier api
> >   virtio-ccw: convert to ioeventfd callbacks
> >   virtio-pci: convert to ioeventfd callbacks
> >   virtio-mmio: convert to ioeventfd callbacks
> >   virtio-bus: remove old set_host_notifier callback
> > 
> >  hw/block/dataplane/virtio-blk.c |   6 +-
> >  hw/s390x/virtio-ccw.c           | 133 
> > ++++++++++++++--------------------------
> >  hw/scsi/virtio-scsi-dataplane.c |   9 ++-
> >  hw/virtio/vhost.c               |  13 ++--
> >  hw/virtio/virtio-bus.c          | 132 
> > +++++++++++++++++++++++++++++++++++++++
> >  hw/virtio/virtio-mmio.c         | 128 
> > +++++++++++++-------------------------
> >  hw/virtio/virtio-pci.c          | 124 +++++++++++++------------------------
> >  include/hw/virtio/virtio-bus.h  |  31 +++++++++-
> >  8 files changed, 303 insertions(+), 273 deletions(-)
> > 
> 
> FWIW, I went back to the old F20 installation. Without your patch set qemu 
> crashes 
> pretty soon, with your patch set it runs stable.
> How intrusive would it be to provide the fix 3 times (for each transport) and
> do the refactoring after 2.6? If the result would be big as well I think
> this patch set is still the right thing to do for 2.6  unless MST has a 
> small and beautiful 2.6fix.

Definitely not beautiful but small.
It's hard for me to see what is meant here, but if it's
even bigger than this patch then I'd be worried.

> 
> 
> Christian



reply via email to

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