[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] net: Peer with existing NIC in netdev_add
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] [RFC] net: Peer with existing NIC in netdev_add |
Date: |
Wed, 31 Oct 2012 18:34:07 +0200 |
On Wed, Oct 31, 2012 at 03:51:08PM +0100, Stefan Hajnoczi wrote:
> 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
OK so if we basically require same type backend then I think it's mostly
fine. I was trying to think of a way to allow changing backend type,
this becomes messy very quickly. In partuclar macvtap probably
shouldn't be swapped with tap even though they are the same type
formally.
--
MST