Michael S. Tsirkin wrote on 2015-09-13: > On Fri, Sep 11, 2015 at 05:39:07PM +0200, Claudio Fontana wrote: >> On 09.09.2015 09:06, Michael S. Tsirkin wrote: >> >> There are many consequences to this, offset within BAR alone is not >> enough, there are multiple things at the virtio level that need sorting >> out. Also we need to consider virtio-mmio etc. >> >>> This would allow VM2VM communication if there are only 2 VMs, but >>> if data needs to be sent to multiple VMs, you must copy it. >> >> Not necessarily, however getting it to work (sharing the backend window >> and arbitrating the multicast) is really hard. >> >>> >>> Additionally, it's a single-purpose feature: you can use it from a >>> userspace PMD but linux will never use it. >>> >>> >>> My proposal is a superset: don't require that BAR memory is used, >>> use IOMMU translation tables. >>> This way, data can be sent to multiple VMs by sharing the same >>> memory with them all. >> >> Can you describe in detail how your proposal deals with the >> arbitration > necessary for multicast handling? > > Basically it falls out naturally. Consider linux guest as an example, > and assume dynamic mappings for simplicity. > > Multicast is done by a bridge on the guest side. That code clones the > skb (reference-counting page fragments) and passes it to multiple ports. > Each of these will program the IOMMU to allow read access to the > fragments to the relevant device.
How to work with vswitch in host side like OVS? Since the flow table is inside host, but guest cannot see it. Best regards, Yang _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
