On Tue, 26 Jun 2018 18:38:51 +0300
"Michael S. Tsirkin" [off-list ref] wrote:

On Tue, Jun 26, 2018 at 05:17:32PM +0200, Cornelia Huck wrote:

quoted

On Tue, 26 Jun 2018 04:50:25 +0300
"Michael S. Tsirkin" [off-list ref] wrote:
  

quoted

On Mon, Jun 25, 2018 at 10:54:09AM -0700, Samudrala, Sridhar wrote:  

quoted

quoted

quoted

quoted

quoted

Might not neccessarily be something wrong, but it's very limited to
prohibit the MAC of VF from changing when enslaved by failover.    

You mean guest changing MAC? I'm not sure why we prohibit that.    

I think Sridhar and Jiri might be better person to answer it. My
impression was that sync'ing the MAC address change between all 3
devices is challenging, as the failover driver uses MAC address to
match net_device internally.    

Yes. The MAC address is assigned by the hypervisor and it needs to manage the movement
of the MAC between the PF and VF.  Allowing the guest to change the MAC will require
synchronization between the hypervisor and the PF/VF drivers. Most of the VF drivers
don't allow changing guest MAC unless it is a trusted VF.    

OK but it's a policy thing. Maybe it's a trusted VF. Who knows?
For example I can see host just
failing VIRTIO_NET_CTRL_MAC_ADDR_SET if it wants to block it.
I'm not sure why VIRTIO_NET_F_STANDBY has to block it in the guest.
  

So, what I get from this is that QEMU needs to be able to control all
of standby, uuid, and mac to accommodate the different setups
(respectively have libvirt/management software set it up). Is the host
able to find out respectively define whether a VF is trusted?  

You do it with ip link I think but QEMU doesn't normally do this,
it relies on libvirt to poke at host kernel and supply the info.

Ok, that makes me conclude that we definitely need to involve the
libvirt folks before we proceed further with defining QEMU interfaces.