On 03/02/2012 10:52 AM, Laine Stump wrote:
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
Well, another aspect of 802.1Qbg versus Qbh is that 802.1Qbg needs an
external daemon, lldpad, to setup the switch. 802.1Qbh presumably does
'all it needs' by talking to the firmware on the ethernet card... The
protocol between libvirt and lldpad currently requires the transfer of
an interface. So this protocol would have to be extended to 'somehow'
support a raw PIC bus/device/function.
Stefan
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list