Re: [libvirt] [PATCH 3/4] virnetdevvportprofile: Changes to support portprofiles for hostdevs
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