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

[Stefan Hajnoczi]

On Wed, Oct 31, 2012 at 10:57:24AM +0200, Michael S. Tsirkin wrote:
> On Wed, Oct 31, 2012 at 09:07:27AM +0100, Stefan Hajnoczi wrote:
> > 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 <address@hidden>
> > > 
> > > 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.
> 
> Ideally, we'd probe all backend capabilities at init time.
> However, looks like we allowed netdev and device creation in any order.
> Can we change this and require netdev always be there before device?

I don't think the order is a problem.  The relaxed order is only
relevant during startup from main() - but in that case we have no
constraints yet anyway.

The problem only occurs when netdev_add is used to create an
incompatible netdev after devices have initialized.  We should be able
to check and error out in the code that my RFC patch modifies.  If
constraints are violated then netdev_add can fail with an error (the new
netdev is not created and the QMP client needs to try again with a
compatible netdev configuration).

Maybe I'm misunderstanding your point?

Stefan