From: "Michael S. Tsirkin" <mst@redhat.com>
To: Ilya Maximets <i.maximets@samsung.com>
Cc: Jason Wang <jasowang@redhat.com>,
qemu-devel@nongnu.org, Dyasly Sergey <s.dyasly@samsung.com>
Subject: Re: [Qemu-devel] [PATCH 0/4] Fix QEMU crash on vhost-user socket disconnect.
Date: Tue, 5 Apr 2016 13:46:16 +0300 [thread overview]
Message-ID: <20160405134103-mutt-send-email-mst@redhat.com> (raw)
In-Reply-To: <56FCBD59.9020203@samsung.com>
On Thu, Mar 31, 2016 at 09:02:01AM +0300, Ilya Maximets wrote:
> On 30.03.2016 20:01, Michael S. Tsirkin wrote:
> > On Wed, Mar 30, 2016 at 06:14:05PM +0300, Ilya Maximets wrote:
> >> Currently QEMU always crashes in following scenario (assume that
> >> vhost-user application is Open vSwitch with 'dpdkvhostuser' port):
> >
> > In fact, wouldn't the right thing to do be stopping the VM?
>
> I don't think that is reasonable to stop VM on failure of just one of
> network interfaces.
We don't start QEMU until vhost user connects, either.
Making guest run properly with a backend is a much bigger
project, let's tackle this separately.
Also, I think handling graceful disconnect is the correct first step.
Handling misbehaving clients is much harder as we have asserts on remote
obeying protocol rules all over the place.
> There may be still working vhost-kernel interfaces.
> Even connection can still be established if vhost-user interface was in
> bonding with kernel interface.
Could not parse this.
> Anyway user should be able to save all his data before QEMU restart.
So reconnect a new backend, and VM will keep going.
> >
> >> 1. # Check that link in guest is in a normal state.
> >> [guest]# ip link show eth0
> >> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc <...>
> >> link/ether 00:16:35:af:aa:4b brd ff:ff:ff:ff:ff:ff
> >>
> >> 2. # Kill vhost-user application (using SIGSEGV just to be sure).
> >> [host]# kill -11 `pgrep ovs-vswitchd`
> >>
> >> 3. # Check that guest still thinks that all is good.
> >> [guest]# ip link show eth0
> >> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc <...>
> >> link/ether 00:16:35:af:aa:4b brd ff:ff:ff:ff:ff:ff
> >>
> >> 4. # Try to unbind virtio-pci driver and observe QEMU crash.
> >> [guest]# echo -n '0000:00:01.0' > /sys/bus/pci/drivers/virtio-pci/unbind
> >> qemu: Failed to read msg header. Read 0 instead of 12. Original request 11.
> >> qemu: Failed to read msg header. Read 0 instead of 12. Original request 11.
> >> qemu: Failed to read msg header. Read 0 instead of 12. Original request 11.
> >>
> >> Child terminated with signal = 0xb (SIGSEGV)
> >> GDBserver exiting
> >>
> >> After the applying of this patch-set:
> >>
> >> 4. # Try to unbind virtio-pci driver. Unbind works fine with only few errors.
> >> [guest]# echo -n '0000:00:01.0' > /sys/bus/pci/drivers/virtio-pci/unbind
> >> qemu: Failed to read msg header. Read 0 instead of 12. Original request 11.
> >> qemu: Failed to read msg header. Read 0 instead of 12. Original request 11.
> >>
> >> 5. # Bind virtio-pci driver back.
> >> [guest]# echo -n '0000:00:01.0' > /sys/bus/pci/drivers/virtio-pci/bind
> >>
> >> 6. # Check link in guest. No crashes here, link in DOWN state.
We already have interfaces to control link state.
I don't think we should necessarily tie link state to backend
state. Could be an option but probably not the default.
> >> [guest]# ip link show eth0
> >> 7: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc <...>
> >> link/ether 00:16:35:af:aa:4b brd ff:ff:ff:ff:ff:ff
> >>
> >> 7. QEMU may be gracefully restarted to restore communication after restarting
> >> of vhost-user application.
> >>
> >> Ilya Maximets (4):
> >> vhost-user: fix crash on socket disconnect.
> >> vhost: prevent double stop of vhost_net device.
> >> vhost: check for vhost_net device validity.
> >> net: notify about link status only if it changed.
> >>
> >> hw/net/vhost_net.c | 48 ++++++++++++++++++++++++++++++++++++++----
> >> hw/net/virtio-net.c | 33 ++++++++++++++++++++++-------
> >> include/hw/virtio/virtio-net.h | 1 +
> >> include/net/vhost-user.h | 1 +
> >> include/net/vhost_net.h | 1 +
> >> net/filter.c | 1 +
> >> net/net.c | 7 +++---
> >> net/vhost-user.c | 43 +++++++++++++++++++++++++++++--------
> >> 8 files changed, 111 insertions(+), 24 deletions(-)
> >>
> >> --
> >> 2.5.0
> >
> >
next prev parent reply other threads:[~2016-04-05 10:46 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-30 15:14 [Qemu-devel] [PATCH 0/4] Fix QEMU crash on vhost-user socket disconnect Ilya Maximets
2016-03-30 15:14 ` [Qemu-devel] [PATCH 1/4] vhost-user: fix crash on " Ilya Maximets
2016-03-30 15:14 ` [Qemu-devel] [PATCH 2/4] vhost: prevent double stop of vhost_net device Ilya Maximets
2016-03-30 15:14 ` [Qemu-devel] [PATCH 3/4] vhost: check for vhost_net device validity Ilya Maximets
2016-03-30 15:14 ` [Qemu-devel] [PATCH 4/4] net: notify about link status only if it changed Ilya Maximets
2016-03-30 17:01 ` [Qemu-devel] [PATCH 0/4] Fix QEMU crash on vhost-user socket disconnect Michael S. Tsirkin
2016-03-31 6:02 ` Ilya Maximets
2016-03-31 9:21 ` Michael S. Tsirkin
2016-03-31 10:48 ` Ilya Maximets
2016-04-05 10:46 ` Michael S. Tsirkin [this message]
-- strict thread matches above, loose matches on Subject: below --
2016-04-06 23:52 Ilya Maximets
2016-04-07 7:01 ` Michael S. Tsirkin
2016-04-07 11:09 Ilya Maximets
2016-04-07 12:25 ` 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=20160405134103-mutt-send-email-mst@redhat.com \
--to=mst@redhat.com \
--cc=i.maximets@samsung.com \
--cc=jasowang@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=s.dyasly@samsung.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.