On 2018年01月15日 21:56, Stefan Hajnoczi wrote:
On Mon, Jan 15, 2018 at 02:56:31PM +0800, Jason Wang wrote:
On 2018年01月12日 18:18, Stefan Hajnoczi wrote:
And what's more important, according to the kvm 2016 slides of vhost-pci,
the motivation of vhost-pci is not building SDN but a chain of VNFs. So
bypassing the central vswitch through a private VM2VM path does make sense.
(Though whether or not vhost-pci is the best choice is still questionable).
This is probably my fault. Maybe my networking terminology is wrong. I
consider "virtual network functions" to be part of "software-defined
networking" use cases. I'm not implying there must be a central virtual
switch.
To rephrase: vhost-pci enables exitless VM2VM communication.
The problem is, exitless is not what vhost-pci invents, it could be achieved
now when both sides are doing busypolling.
The only way I'm aware of is ivshmem. But ivshmem lacks a family of
standard device types that allows different implementations to
interoperate. We already have the virtio family of device types, so it
makes sense to work on a virtio-based solution.
Perhaps I've missed a different approach for exitless VM2VM
communication. Please explain how VM1 and VM2 can do exitless network
communication today?
I'm not sure we're talking the same thing. For VM2VM, do you mean only for
shared memory? I thought we can treat any backends that can transfer data
directly between two VMs for a VM2VM solution. In this case, if virtqueue
notifications were disabled by all sides (e.g busy polling), there will be
no exits at all.
And if you want a virtio version of shared memory, it's another kind of
motivation at least from my point of view.