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 > > > >