On Fri, 2012-03-02 at 10:52 -0500, Laine Stump wrote:
> 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>
This means the XML fragment look more like this for Qbh:
<interface type='hostdev'>
<source>
<address type='pci' domain='0' bus='0' slot='6' function='0'/>
</source>
<mac address='52:54:00:8b:c9:51'>
<virtualport type='802.1Qbh'>
<parameters profileid='finance'/>
</virtualport>
</interface>
and for Qbg:
<interface type='hostdev'>
<source>
<address type='pci' domain='0' bus='0' slot='6' function='0'/>
</source>
<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>
>
> 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 I understand above correctly, your first assumption seems correct and
my XML examples have been misleading you.
>
> 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?)
>
>
I do not know for Qbh, but for Qbg:
The switch knows nothing about macvtap devices or virtual functions,
what matters is the combination of
(managerid, typeid, typeidversion, instanceid, vlanid)
to make an association.
Best regards,
Gerhard Stenzel, Hybrid Technologies, LTC
-----------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung:
Dirk Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list