From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33887) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZavz-000409-VI for qemu-devel@nongnu.org; Wed, 09 Sep 2015 04:40:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZavu-0000uO-W6 for qemu-devel@nongnu.org; Wed, 09 Sep 2015 04:40:51 -0400 Received: from lhrrgout.huawei.com ([194.213.3.17]:45064) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZavu-0000t3-Nj for qemu-devel@nongnu.org; Wed, 09 Sep 2015 04:40:46 -0400 Message-ID: <55EFF03A.4000109@huawei.com> Date: Wed, 9 Sep 2015 10:39:22 +0200 From: Claudio Fontana MIME-Version: 1.0 References: <20150831160655-mutt-send-email-mst@redhat.com> <55ED854A.1080804@huawei.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [opnfv-tech-discuss] rfc: vhost user enhancements for vm2vm communication List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Zhang, Yang Z" , "Michael S. Tsirkin" , "qemu-devel@nongnu.org" , "virtualization@lists.linux-foundation.org" , "virtio-dev@lists.oasis-open.org" , "opnfv-tech-discuss@lists.opnfv.org" Cc: Jan Kiszka 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