On 3/2/12 12:45 PM, "Laine Stump" <laine@xxxxxxxxx> wrote: > On 03/02/2012 03:16 PM, Roopa Prabhu wrote: >> On 3/2/12 11:27 AM, "Laine Stump" <laine@xxxxxxxxx> 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. > > Yeah, I'm not sure how I lost sight of the fact that you said your > testing had gone okay - I guess too little sleep. So I read too much > into the discussion, and it's just Qbg that has these restrictions. > Good! Pay no attention to my alarmism :-) > > No problem :) >> 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. > > Right. That's pretty much how I've always been assuming it worked for > all of these modes. I guess I should spend more time at lower levels. > >> 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. >> > > Okay, then in the end these patches will support 802.1Qbh <virtualport> > setting, as well as setting the MAC address (but only for SRIOV-capable > devices). And any future support for 802.1Qbg would require both some > extra support outside libvirt, > as well as specifying the vlanid in the > config, and requiring the guest to setup VLAN tagging. Did I get it > right now? > Yes that seems right. I think we don't need to call out the setup in the guest. Its common for all modes. Host provisions the vlans (ie configures the switch port with that vlan etc). This is the step that libvirt does. And guest does his own setup for vlan devices if needed. Thanks, Roopa -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list