From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Cornelia Huck <cornelia.huck@de.ibm.com>, qemu-devel@nongnu.org
Cc: tubo@linux.vnet.ibm.com, pbonzini@redhat.com, famz@redhat.com,
stefanha@redhat.com, mst@redhat.com
Subject: Re: [Qemu-devel] [PATCH 0/6] virtio: refactor host notifiers
Date: Tue, 29 Mar 2016 15:23:57 +0200 [thread overview]
Message-ID: <56FA81ED.2040903@de.ibm.com> (raw)
In-Reply-To: <1458836125-73613-1-git-send-email-cornelia.huck@de.ibm.com>
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.
Christian
next prev parent reply other threads:[~2016-03-29 13:24 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-24 16:15 [Qemu-devel] [PATCH 0/6] virtio: refactor host notifiers Cornelia Huck
2016-03-24 16:15 ` [Qemu-devel] [PATCH 1/6] virtio-bus: common ioeventfd infrastructure Cornelia Huck
2016-03-24 16:15 ` [Qemu-devel] [PATCH 2/6] virtio-bus: have callers tolerate new host notifier api Cornelia Huck
2016-03-24 16:15 ` [Qemu-devel] [PATCH 3/6] virtio-ccw: convert to ioeventfd callbacks Cornelia Huck
2016-03-24 16:15 ` [Qemu-devel] [PATCH 4/6] virtio-pci: " Cornelia Huck
2016-03-24 16:15 ` [Qemu-devel] [PATCH 5/6] virtio-mmio: " Cornelia Huck
2016-03-24 16:15 ` [Qemu-devel] [PATCH 6/6] virtio-bus: remove old set_host_notifier callback Cornelia Huck
2016-03-24 17:06 ` [Qemu-devel] [PATCH 0/6] virtio: refactor host notifiers Paolo Bonzini
2016-03-29 8:18 ` Cornelia Huck
2016-03-29 9:15 ` Paolo Bonzini
2016-03-25 9:52 ` Fam Zheng
2016-03-28 3:55 ` TU BO
2016-03-28 18:11 ` Paolo Bonzini
2016-03-29 9:14 ` tu bo
2016-03-29 11:45 ` Cornelia Huck
2016-03-29 13:50 ` Paolo Bonzini
2016-03-29 16:27 ` Christian Borntraeger
2016-03-31 2:37 ` tu bo
2016-03-31 5:47 ` tu bo
2016-03-29 11:54 ` Christian Borntraeger
2016-03-31 2:47 ` tu bo
2016-03-29 13:23 ` Christian Borntraeger [this message]
2016-03-29 13:38 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56FA81ED.2040903@de.ibm.com \
--to=borntraeger@de.ibm.com \
--cc=cornelia.huck@de.ibm.com \
--cc=famz@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=tubo@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).