Re: [virtio-dev] [PATCH v4] content: Introduce VIRTIO_NET_F_STANDBY feature

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Oct 04, 2018 at 05:03:14PM -0700, Siwei Liu wrote:
> On Tue, Oct 2, 2018 at 5:43 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Tue, Oct 02, 2018 at 01:42:09AM -0700, Siwei Liu wrote:
> > > The VF's MAC can be updated by PF/host on the fly at any time. One can
> > > start with a random MAC but use group ID to pair device instead. And
> > > only update MAC address to the real one when moving MAC filter around
> > > after PV says OK to switch datapath.
> > >
> > > Do you see any problem with this design?
> >
> > Isn't this what I proposed:
> >         Maybe we can
> >         start VF with a temporary MAC, then change it to a final one when guest
> >         tries to use it. It will work but we run into fact that MACs are
> >         currently programmed by mgmnt - in many setups qemu does not have the
> >         rights to do it.
> >
> > ?
> >
> > If yes I don't see a problem with the interface design, even though
> > implementation wise it's more work as it will have to include management
> > changes.
> 
> I thought we discussed this design a while back:
> https://www.spinics.net/lists/netdev/msg512232.html
> 
> ... plug in a VF with a random MAC filter programmed in prior, and
> initially use that random MAC within guest. This would require:
> a) not relying on permanent MAC address to do pairing during the
> initial discovery, e.g. use the failover group ID as in this
> discussion
> b) host to toggle the MAC address filter: which includes taking down
> the tap device to return the MAC back to PF, followed by assigning
> that MAC to VF using "ip link ... set vf ..."
> c) notify guest to reload/reset VF driver for the change of hardware MAC address
> d) until VF reloads the driver it won't be able to use the datapath,
> so very short period of network outage is (still) expected
>
> though I still don't think this design can elimnate downtime.


No, my idea is somewhat different. As you say there is a problem
of delay at point (c). Further, the need to poke at PF filters
with set vf does not match the current security model where
any security related configuration such as MAC filtering is done upfront.


So I have two suggestions:

1. Teach pf driver not to program the filter until vf driver actually goes up.

   How do we know it went up? For example, it is highly likely
   that driver will send some kind of command on init.
   E.g. linux seems to always try to set the mac address during init.
   We can have any kind of command received by the PF enable
   the filter, until reset.

   In absence of an appropriate command, QEMU can detect bus master
   enable and do that.

2. Create a variant of trusted VF where it starts out without a valid
   MAC, guest can set a softmac MAC but only can set it to the specific
   value that matches virtio.
   Alternatively - if it's preferred for some reason - allow
   guest to program just two MACs, the original one and the virtio one.
   Any other value is denied.



> However,
> it looks like as of today the MAC matching still haven't addressed the
> datapath switching and error handling in a clean way. As said, for
> SR-IOV live migration on iSCSI root disk there will be a lot of
> dancing parts going along the way, reliable network connectity and
> dedicated handshakes are critical to this kind of setup.
> 
> -Siwei

I think MAC matching removes downtime when device is removed but not
when it's re-added, yes. It has the advantage of an already present
linux driver support, but if you are prepared to work on
adding e.g. bridge based matching, that will go away.


> >
> > --
> > MST
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> >