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
<virtualport> (along with knowing that the physical device is not being
shared) is not enough information to properly perform an associate
operation.
Is this correct?
If that's the case, then there are some basic assumptions made here that
are incorrect, and we will need to either change the lower level code to
somehow accomplish a port associate without a macvtap interface, or we
will need to pull some kind of trickery, possibly adding a macvtap
interface to the PF to be used as a proxy to do the ASSOCIATE for the VF
(will that even work? In particular, will it work if multiple VFs need
to operate in one of the "exclusive" modes where no sharing of physical
device is permitted?)
Or maybe I'm still not understanding...
> <mac address='52:54:00:8b:c9:51'>
> <virtualport type='802.1Qbh'>
> <parameters profileid='finance'/>
> </virtualport>
> </interface>
>
> Can someone confirm?
>
> For Qbg, we would need then something like this:
>
> <interface type='hostdev'>
> <source dev='eth0' mode='vepa'/>
> <mac address='52:54:00:8b:c9:51'>
> <virtualport type="802.1Qbg">
> <parameters managerid="11" typeid="1193047" typeidversion="2" instanceid="09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f" vlanid="2"/>
> </virtualport>
> </interface>
>
> to be of any use.
Again, my knowledge is insufficient to understand - why was a vlanid not
necessary before when we were dealing with a hostside macvtap tied to a
guest-side emulated netdev, and why is it necessary now that we want to
just passthrough the PCI device to the guest?
> Note the additional vlanid attribute. The semantic
> would be that the host establishes a Qbg association for
> (managerid, typeid, typeidversion, instanceid, vlanid)
> and that the VM would need to add the correct VLAN tag in order to be
> able to communicate.
So adding the VLAN tag has in the past been done by the macvtap
interface? Where did it learn the vlanid from?
Definitely if the packets need to leave the host with a VLAN tag, in PCI
passthrough mode that will need to be done by the guest OS, since the
host will be unable to get its hands on the packets. Once that's the
case, does it maybe make more sense to just leave *everything* up to the
guest OS - do a PCI passthrough of the device (maybe setting the MAC
address) and let the guest do the port associate etc. too? (Another way
of saying this - at this point, shouldn't we just admit that transparent
hostside support of VEPA (or any other protocol that requires data
packets to be modified) using PCI passthrough by definition is not
possible, and therefore isn't supported?)
Or am I just misunderstanding again?
>
> Does that make sense?
Not yet, but I'm slowly learning more and more :-)
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list