Re: [Qemu-devel] [PATCH 0/4] add failover feature for assigned network devices

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

On Mon, Jun 03, 2019 at 02:18:19PM -0400, Laine Stump wrote:
> On 6/3/19 2:12 PM, Michael S. Tsirkin wrote:
> > On Mon, Jun 03, 2019 at 02:06:47PM -0400, Laine Stump wrote:
> > > On 5/28/19 10:54 PM, Michael S. Tsirkin wrote:
> > > > On Tue, May 28, 2019 at 05:14:22PM -0700, si-wei liu wrote:
> > > > > 
> > > > > 
> > > > > On 5/21/2019 11:49 AM, Jens Freimann wrote:
> > > > > > On Tue, May 21, 2019 at 07:37:19AM -0400, Michael S. Tsirkin wrote:
> > > > > > > On Tue, May 21, 2019 at 09:21:57AM +0200, Jens Freimann wrote:
> > > > > > > > On Mon, May 20, 2019 at 04:56:57PM -0600, Alex Williamson wrote:
> > > 
> > > > > > > Actually is there a list of devices for which this has been tested
> > > > > > > besides mlx5? I think someone said some old intel cards
> > > > > > > don't support this well, we might need to blacklist these ...
> > > > > > 
> > > > > > So far I've tested mlx5 and XL710 which both worked, but I'm
> > > > > > working on testing with more devices. But of course help with testing
> > > > > > is greatly appreciated.
> > > > > 
> > > > > It won't work on Intel ixgbe and Broadcom bnxt_en, which requires toggling
> > > > > the state of tap backing the virtio-net in order to release/reprogram MAC
> > > > > filter. Actually, it's very few NICs that could work with this - even some
> > > > > works by chance the behavior is undefined. Instead of blacklisting it makes
> > > > > more sense to whitelist the NIC that supports it - with some new sysfs
> > > > > attribute claiming the support presumably.
> > > > > 
> > > > > -Siwei
> > > > 
> > > > I agree for many cards we won't know how they behave until we try.  One
> > > > can consider this a bug in Linux that cards don't behave in a consistent
> > > > way.  The best thing to do IMHO would be to write a tool that people can
> > > > run to test the behaviour.
> > > 
> > > Is the "bad behavior" something due to the hardware of the cards, or their
> > > drivers? If it's the latter, then at least initially having a whitelist
> > > would be counterproductive, since it would make it difficult for relative
> > > outsiders to test and report success/failure of various cards.
> > 
> > We can add an "ignore whitelist" flag. Would that address the issue?
> 
> It would be better than requiring a kernel/qemu recompile :-)
> 
> 
> Where would the whilelist live? In qemu or in the kernel? It would be
> problematic to have the whitelist in qemu if kernel driver changes could fix
> a particular card.

So originally I thought:
- add some interface in the kernel to signal new behaviour
- start with a whitelist in qemu
- if not on the whitelist, check the new interface
- if not there, check a "force" flag on the device

But one problem with all of the above is that it's actually
too late. With a broken driver when management sets MAC on the
to-be-primary VF traffic stops being sent to standby.

> Beyond that, what about *always* just issuing some sort of warning rather
> than completely forbidding a card that wasn't whitelisted? (Haven't decided
> if I like that better or not (and it probably doesn't matter, since I'm not
> a "real" user, but I thought I would mention it).

People tend to ignore warnings :)

-- 
MST