[libvirt] [PATCH 3/4] virnetdevvportprofile: Changes to support portprofiles for hostdevs

[Roopa Prabhu]

On 3/2/12 11:27 AM, "Laine Stump" <laine at laine.org> wrote:

> 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.
> 
Laine, The patches I submitted for virtualport 802.1Qbh work just fine.
I submitted these patches mainly to get the virtualport working  for
802.1Qbh. Because we pass the port profile via the PF to fw and then to the
switch.  The driver in the guest just comes up on the VF and uses the
already associated VF.

We do the port profile association from the host because of security
reasons. Instead of giving control to the guest OS.

And as you can see in the patches, for 802.1Qbh port profile association on
the hostdev is not much different from port profile association in the
macvtap case.

Thanks,
Roopa