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

["Samudrala, Sridhar" <sridhar.samudrala@intel.com>]

On 10/10/2018 7:40 AM, Michael S. Tsirkin wrote:
> On Thu, Oct 04, 2018 at 10:17:04PM -0700, Samudrala, Sridhar wrote:
> > On 10/4/2018 5:03 PM, 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. However,
> > > it looks like as of today the MAC matching still haven't addressed the
> > > datapath switching and error handling in a clean way.
> > I am not sure what is the issue with datapath switching with the net_failover solution.
> >
> > Do you see any issues with the migration management layer to automate the steps
> > that are listed in the example script in the documentation.
> > https://www.kernel.org/doc/html/latest/networking/net_failover.html
> >
> > Now that we are considering making the VF visible only when the standby negotiation
> > is completed, i am not sure why we need a random MAC.
> The claim is that some pfs update MAC RX filter immediately once vf is
> created, not when its driver attaches. That will mean on hot-plug there
> is downtime until device is guest visible and driver initialized.
>
> Can you confirm that isn't the case for intel cards?

For an untrusted VF, MAC address is assigned by the management layer and is set via
ndo_set_vf_mac() call to the PF on the hypervisor. This does cause the MAC RX filter
to be programmed immediately.

If possible we could delay setting the MAC RX filter until the device is guest visible, but
before the driver is loaded. If the VF driver comes up with a random mac before the
MAC address is set via PF, it will require a VF reset to get the right MAC which also would
also result in downtime.