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. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list