Re: [Qemu-devel] [RFC] net: Peer with existing NIC in netdev_add

[Stefan Hajnoczi <stefanha@gmail.com>]

On Tue, Oct 30, 2012 at 05:24:06PM +0200, Michael S. Tsirkin wrote:
> On Wed, Oct 24, 2012 at 02:49:21PM +0200, Stefan Hajnoczi wrote:
> > Allow netdev_del followed by netdev_add to re-peer a NIC and its netdev:
> > 
> >   (qemu) info network
> >   virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
> >    \ netdev0: type=user,net=10.0.2.0,restrict=off
> > 
> >   (qemu) netdev_del netdev0
> > 
> >   (qemu) netdev_add socket,id=netdev0,listen=:1234
> > 
> >   (qemu) info network
> >   virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
> >    \ netdev0: type=socket,
> > 
> > This makes it possible to switch netdev while the guest is running.  It
> > is not necessary to reset the NIC.
> > 
> > Note that the NIC's link goes down in netdev_del and back up again in
> > netdev_add.  Therefore the guest becomes aware that the network has
> > changed, although this depends on the emulated NIC model providing link
> > status change interrupts.
> > 
> > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> 
> I'd be surprised if this patch worked when one or both backends are tap.
> tap supports offloads but slirp doesn't, since guest
> probes offloads at startup, it assumes it can use offloads.
> We also program tap during device operation e.g. on set features.
> vhost operation could also be interesting, have not looked into it.

Yes, I left a TODO in the RFC patch and described the issue below.
We'll have to reject incompatible netdevs.

At this stage I'd like to see if this approach works for Laine.  If it
looks good I'll figure out how we can make vhost and offload checks.

> > ---
> > This patch addresses the netdev hotplug issue that has been discussed
> > previously on the mailing list:
> > 
> >   https://www.redhat.com/archives/libvir-list/2012-October/msg00629.html
> 
> I actually think both we and libvirt should address (2):
> 	(2) because qemu has no asynchronous event to notify libvirt
> 	when the guest's PCI detach has actually completed, I have to stick in
> 	an arbitrary call to sleep() which is generally *way* too long, but may
> 	be too short in some cases of extremely high load.
> 
> libvirt should verify device is gone after calling sleep,
> if not yet gone - sleep again.
> 
> qemu should report an event when device is ejected.

I agree.  The hotplug implementation and how it is driven by QMP clients
is really ugly today.

Stefan