On 08/07/2012 01:53 PM, Nishank Trivedi (nistrive) wrote: > Hi, > > In 802.1Qbh case where exists a SR-IOV capable network device, if any of > the virtual functions of this device is used in hostdev mode for the > guest, port-profile disassociate will also cause physical function > interface to go down. This appears to be a bug, but wanted to find if this > was done intentionally for some reasons. > > To be more specific, if a network device supports SRIOV and its VF is > being used in pci passthrough mode, when the guest is shutdown or > destroyed following happens - > > qemuProcessStop > \_ qemuDomainReAttachHostdevDevices(hostdevs) > \_ qemuDomainHostdevNetConfigRestore(hostdev) > \_ virNetDevPortProfileDisassociate(linkdev) > \_ virNetDevSetOnline(linkdev, false) > > In above, qemuDomainHostdevNetConfigRestore() finds out the PF for > provided hostdev (which is VF) and passes it to > virNetDevPortProfileDisassociate() as linkdev. Later, linkdev gets passed > to virNetDevSetOnline() where the interface is brought down by clearing > IFF_UP flag. > > However, in macvtap emulation mode, > virNetDevMacVLanDeleteWithVPortProfile() passes VF as linkdev (and -1 as > vf) to virNetDevPortProfileDisassociate(), hence, not affecting PF at all. > > Bringing down a PF, when only VF is being brought down is not expected > behavior (unless, I'm missing something here). A way to get around it > would be to check if there exists vf (>=0) in > virNetDevPortProfileDisassociate(), and if so, it should only pass the > interface name of this VF rather than PF itself to virNetDevSetOnline(). > If it sounds reasonable, I'll send out a fix. Yes, I believe you are correct that virNetDevSetOnline is being called with the wrong device name (I could be wrong though - is there maybe some odd rule that the PF must be UP before the VFs will be up? In case case, we certainly shouldn't be setting the PF to IFF_DOWN). But in the case of PCI passthrough, does it even need to be called at all? Cc'ing Roopa in case she missed this in all the other traffic. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list