[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [opnfv-tech-discuss] rfc: vhost user enhancements for v
From: |
Zhang, Yang Z |
Subject: |
Re: [Qemu-devel] [opnfv-tech-discuss] rfc: vhost user enhancements for vm2vm communication |
Date: |
Wed, 9 Sep 2015 06:40:48 +0000 |
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
Re: [Qemu-devel] rfc: vhost user enhancements for vm2vm communication, Michael S. Tsirkin, 2015/09/01
Re: [Qemu-devel] rfc: vhost user enhancements for vm2vm communication, Claudio Fontana, 2015/09/07
- Re: [Qemu-devel] [opnfv-tech-discuss] rfc: vhost user enhancements for vm2vm communication,
Zhang, Yang Z <=
- Re: [Qemu-devel] [opnfv-tech-discuss] rfc: vhost user enhancements for vm2vm communication, Claudio Fontana, 2015/09/09
- [Qemu-devel] RFC: virtio-peer shared memory based peer communication device, Claudio Fontana, 2015/09/18
- Re: [Qemu-devel] RFC: virtio-peer shared memory based peer communication device, Paolo Bonzini, 2015/09/18
- Re: [Qemu-devel] RFC: virtio-peer shared memory based peer communication device, Jan Kiszka, 2015/09/21
- Re: [Qemu-devel] RFC: virtio-peer shared memory based peer communication device, Paolo Bonzini, 2015/09/21
Re: [Qemu-devel] RFC: virtio-peer shared memory based peer communication device, Michael S. Tsirkin, 2015/09/21
Re: [Qemu-devel] RFC: virtio-peer shared memory based peer communication device, Jan Kiszka, 2015/09/21
Re: [Qemu-devel] RFC: virtio-peer shared memory based peer communication device, Michael S. Tsirkin, 2015/09/24
Re: [Qemu-devel] rfc: vhost user enhancements for vm2vm communication, Michael S. Tsirkin, 2015/09/09