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