On 03/02/2012 11:58 AM, Stefan Berger wrote:
On 03/02/2012 11:37 AM, Gerhard Stenzel wrote:
>
> Letting the guest do the association is an option, which should work
> already (even if noone probably tested it yet), but the question is
> really how much control should the host have vs the guest. There are
> definitely scenarios thinkable where the host should do the association.
I think an applicable scenario is where the infrastructure provider
doesn't really know the guest user and needs to have 'mandatory access
control' over the configuration of the infrastructure and yet wants to
use the pass-through mode for better throughput.
And/or when the guest OS doesn't have the necessary smarts to do the
association (or maybe even vlan tagging) itself.
So, at the end of this, is there *any* 802.1QbX mode that can work using
PCI passthrough without at least one of the following things:
1) a macvtap interface on the host. (what about my idea of attaching a
macvtap interface to the PF? does that have any hint of practicality?)
2) extending the protocol for talking with lldpad to support using a raw
PCI device rather than a macvtap device.
3) the guest doing vlan tagging
4) the guest doing the full 802.1QbX associate/de-associate protocol
exchange itself?
Nobody has said it explicitly yet (I think), but I have the impression
that this problem unfortunately can't be solved by libvirt alone. If
that's the case, we should state that as soon as possible so that we can
table the <virtualport> part of these patches for the short term, and
separate the mac address part to get it pushed upstream (along with the
new low-level PCI utility functions), as that is very useful on its own.