On Tue, Mar 13, 2018 at 05:28:07PM -0700, Samudrala, Sridhar wrote: > > I am not sure if it's a good idea to leave the > > virtio_bypass around if running into failure: the guest is not > > migratable as the VF doesn't have a backup path, > > Are you talking about a failure when registering backup netdev? This should > not > happen, but i guess we can improve error handling in such scenario.
A nice way to do this would be to clear the backup feature bit. > > > And perhaps the worse > > part is that, it now has two interfaces with identical MAC address but > > one of them is invalid (user cannot use the virtio interface as it has > > a dampened datapath). IMHO the virtio_bypass and its lower netdev > > should be destroyed at all when it fails to bind the VF, and > > technically, there should be some way to propogate the failure status > > to the hypervisor/backend, indicating that the VM is not migratable > > because of guest software errors (maybe by clearing out the backup > > feature from the guest virtio driver so host can see/learn it). > > In BACKUP mode, user can only use the upper virtio_bypass netdev and that will > always be there. Any failure to enslave VF netdev is not fatal, but i will see > if we can improve the error handling of failure to enslave backup netdev. > Also, i don't think the BACKUP feature bit is negotiable with the host. > > Thanks > Sridhar All bits are negotiable. It's up to the host whether to support a device with this bit clear, or to fail negotiation. -- MST
