search for: failover_existing_slave_register

...ks to me it's still a bug of > guest: > > E.g primary could be probed before failover_register() in guest. Then > we will miss the enslaving of primary forever. That is not an issue. Even if the primary is probed before failover driver, it will enslave the primary via the call to failover_existing_slave_register() as part of failover_register() routine. > > Thanks > >> >>> Thanks >>> >>>> We can move some of this code to management as well, >>>> architecturally it >>>> does not make too much sense but it might be easier >>>&gt...

...ks to me it's still a bug of > guest: > > E.g primary could be probed before failover_register() in guest. Then > we will miss the enslaving of primary forever. That is not an issue. Even if the primary is probed before failover driver, it will enslave the primary via the call to failover_existing_slave_register() as part of failover_register() routine. > > Thanks > >> >>> Thanks >>> >>>> We can move some of this code to management as well, >>>> architecturally it >>>> does not make too much sense but it might be easier >>>&gt...

...WN: + case NETDEV_CHANGE: + return failover_slave_link_change(event_dev); + case NETDEV_CHANGENAME: + return failover_slave_name_change(event_dev); + default: + return NOTIFY_DONE; + } +} + +static struct notifier_block failover_notifier = { + .notifier_call = failover_event, +}; + +static void +failover_existing_slave_register(struct net_device *failover_dev) +{ + struct net *net = dev_net(failover_dev); + struct net_device *dev; + + rtnl_lock(); + for_each_netdev(net, dev) { + if (netif_is_failover(dev)) + continue; + if (ether_addr_equal(failover_dev->perm_addr, dev->perm_addr)) + failover_slave_register(de...

...; > E.g primary could be probed before failover_register() in guest. > > > Then we will miss the enslaving of primary forever. > > > > That is not an issue. Even if the primary is probed before failover > > driver, it will > > enslave the primary via the call to failover_existing_slave_register() > > as part of > > failover_register() routine. > > Aha I get it. So the enumeration order is not an issue. > > Consider primary may still be seen by guest kernel even if we delay its > visibility, I wonder whether we can control the lifecycle of primary through >...

...t;> guest: >> >> E.g primary could be probed before failover_register() in guest. Then >> we will miss the enslaving of primary forever. > > That is not an issue. Even if the primary is probed before failover > driver, it will > enslave the primary via the call to failover_existing_slave_register() > as part of > failover_register() routine. Aha I get it. So the enumeration order is not an issue. Consider primary may still be seen by guest kernel even if we delay its visibility, I wonder whether we can control the lifecycle of primary through driver but not qemu. This can simplif...

...could be probed before failover_register() in guest. >> > > Then we will miss the enslaving of primary forever. >> > >> > That is not an issue. Even if the primary is probed before failover >> > driver, it will >> > enslave the primary via the call to failover_existing_slave_register() >> > as part of >> > failover_register() routine. >> >> Aha I get it. So the enumeration order is not an issue. >> >> Consider primary may still be seen by guest kernel even if we delay its >> visibility, I wonder whether we can control the lifecycl...

On Wed, Jun 06, 2018 at 10:29:03AM +0800, Jason Wang wrote: > > > On 2018?06?05? 20:33, Michael S. Tsirkin wrote: > > I don't think this is sufficient. > > > > If both primary and standby devices are present, a legacy guest without > > support for the feature might see two devices with same mac and get > > confused. > > > > I think that we

On Wed, Jun 06, 2018 at 10:29:03AM +0800, Jason Wang wrote: > > > On 2018?06?05? 20:33, Michael S. Tsirkin wrote: > > I don't think this is sufficient. > > > > If both primary and standby devices are present, a legacy guest without > > support for the feature might see two devices with same mac and get > > confused. > > > > I think that we

The main motivation for this patch is to enable cloud service providers to provide an accelerated datapath to virtio-net enabled VMs in a transparent manner with no/minimal guest userspace changes. This also enables hypervisor controlled live migration to be supported with VMs that have direct attached SR-IOV VF devices. Patch 1 introduces a failover module that provides a generic interface for

The main motivation for this patch is to enable cloud service providers to provide an accelerated datapath to virtio-net enabled VMs in a transparent manner with no/minimal guest userspace changes. This also enables hypervisor controlled live migration to be supported with VMs that have direct attached SR-IOV VF devices. Patch 1 introduces a failover module that provides a generic interface for