On 09.09.2015 08:40, Zhang, Yang Z wrote: > Claudio Fontana wrote on 2015-09-07: >> Coming late to the party, >> >> On 31.08.2015 16:11, Michael S. Tsirkin wrote: >>> Hello! >>> During the KVM forum, we discussed supporting virtio on top >>> of ivshmem. I have considered it, and came up with an alternative >>> that has several advantages over that - please see below. >>> Comments welcome. >> >> as Jan mentioned we actually discussed a virtio-shmem device which would >> incorporate the advantages of ivshmem (so no need for a separate ivshmem >> device), which would use the well known virtio interface, taking advantage of >> the new virtio-1 virtqueue layout to split r/w and read-only rings as seen from >> the two sides, and make use also of BAR0 which has been freed up for use by >> the device. > > Interesting! Can you elaborate it? Yes, I will post a more detailed proposal in the coming days. >> >> This way it would be possible to share the rings and the actual memory >> for the buffers in the PCI bars. The guest VMs could decide to use the >> shared memory regions directly as prepared by the hypervisor (in the > > "the shared memory regions" here means share another VM's memory or like ivshmem? It's explicitly about sharing memory between two desired VMs, as set up by the virtualization environment. >> jailhouse case) or QEMU/KVM, or perform their own validation on the >> input depending on the use case. >> >> Of course the communication between VMs needs in this case to be >> pre-configured and is quite static (which is actually beneficial in our use case). > > pre-configured means user knows which VMs will talk to each other and configure it when booting guest(i.e. in Qemu command line)? Yes. Ciao, Claudio > >> >> But still in your proposed solution, each VM needs to be pre-configured to >> communicate with a specific other VM using a separate device right? >> >> But I wonder if we are addressing the same problem.. in your case you are >> looking at having a shared memory pool for all VMs potentially visible to all VMs >> (the vhost-user case), while in the virtio-shmem proposal we discussed we >> were assuming specific different regions for every channel. >> >> Ciao, >> >> Claudio _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization