* Sridhar Samudrala (sri@xxxxxxxxxx) wrote: > On 11/30/2011 3:00 PM, Chris Wright wrote: > > physical port > > | > >+------------+------------+ > >| +-----+ | > >| | VEB | | > >| +-----+ | > >| / | \ | > >| / | \ | > >| / | \ | > >+-----+------+------+-----+ > > | | | > > PF VF 1 VF 2 > > / | | > > +---+---+ VM4 +---+---+ > > | sw | |macvtap| > > | switch| +---+---+ > > +-+-+-+-+ | > > / | \ VM5 > > / | \ > >VM1 VM2 VM3 > > > >This has VMs 1-3 hanging of the PF via a linux bridge (traditional hv > >switching), VM4 directly owning VF1 (pci device assignement), and VM5 > >indirectly owning VF2 (macvtap passthrough, that started this whole > >thing). > > > >So, I'm understanding you saying that VM4 or VM4 sending a packet to VM1 > >goes in to VEB, out PF, and into linux bridging code, rigth? At which > >point the PF is in promiscuous mode (btw, same does not work if bridge is > >attached to VF, at least for some VFs, due to lack of promiscuous mode). > > > >>Packets sent from a guest with a VF to the address of another guest with > >>a VF need to be forwarded similarly, but the driver should be able to > >>infer that from (3). > >Right, and that works currently for the case where both guests are like > >VM4, they directly own the VF via PCI device assignement. But for VM4 > >to talk to VM5, VF3 is not in promiscuous mode and has a different MAC > >address than VM5's vNIC. If the embedded bridge does not learn, and > >nobody programmed it to fwd frames for VM5 via VF3... > I think you are referring to VF2. There is no VF3 in your picture. *sigh* (also meant 'VM4 or VM5' up above, not 'VM4 or VM4')... > In macvtap passthru mode, VF2 will be set to the same mac address as VM5's > MAC. So VM4 should be be able to talk to VM5. yes (i think macvtap in bridging or vepa mode w/ single VM has that issue, not passthru) > >I believe this is what Roopa's patch will allow. The question now is > >whether there's a better way to handle this? > My understanding is that Roopa's patch will allow setting additional mac > addresses to > VM5 without the need to put VF5 in promiscous mode. Thanks for your corrections Sridar. cheers, -chris -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
