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? > > 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? > 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)? > > 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 > > > Best regards, Yang _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization