Re: [libvirt] [PATCH 3/4] virnetdevvportprofile: Changes to support portprofiles for hostdevs

On 03/02/2012 09:12 AM, Gerhard Stenzel wrote: > On Thu, 2012-03-01 at 13:02 -0500, Laine Stump wrote: >> In the case of hostdev though, there is not necessarily any netdev >> driver at all in the host (and thus no "linkdev" to attach a macvtap >> to), certainly not after it's attached to the guest - control of the >> PCI >> device is given over to the guest. >> >> So is the problem here that 802.1QbX stuff can only work if there's an >> associated macvtap device? Although it might be possible to >> temporarily >> create a macvtap device and attach it to the PCI device's netdev >> driver >> prior to passing it through, that would only work if a netdev driver >> was >> bound to the PCI device (which isn't always the case, especially for >> SRIOV VFs), yet that netdev driver would then immediately need to be >> unbound prior to assigning the device to the guest, and most likely >> that >> would kill the macvtap device; even if the setup done using that >> macvtap >> device wasn't undone in the process, would it be possible to undo it >> later when the guest terminates (or the device is detached from the >> guest)? > I wondered how the complete XML fragment for Qbh would look like and > came up with the following: > > <interface type='hostdev'> > <source dev='eth0' mode='private'/> 1) Currently it requires a PCI address (although I plan to add the ability to accept a netdev name and automatically convert it to a PCI address): <source> <address type='pci' domain='0' bus='0' slot='6' function='0'/> </source> 2) I guess I have been misunderestimating the level of symbiosis between macvtap and 802.1QbX. I had thought that the private vs. vepa thing was related to whether or not macvtap could (or couldn't) share the physical device and (when sharing was allowed) whether or not it allowed multiple macvtap devices connected to the same physical to see traffic from each other. This assumption led me to believe that in the case of a PCI passthrough device, where there is obviously no sharing (or macvtap device), these different modes were irrelevant, and all that was needed was the information in<virtualport>. What I *think* I'm understanding from this discussion is that 1) in order for a virtual port association to happen, a macvtap interface must exist, and the association is done wrt that macvtap device *not* the physical device, or even the VF, and 2) knowing the information in