search for: vm2vm

On Tue, Sep 01, 2015 at 11:11:52AM +0200, Jan Kiszka wrote: > On 2015-09-01 10:01, Michael S. Tsirkin wrote: > > On Tue, Sep 01, 2015 at 09:35:21AM +0200, Jan Kiszka wrote: > >> Leaving all the implementation and interface details aside, this > >> discussion is first of all about two fundamentally different approaches: > >> static shared memory windows vs.

On Tue, Sep 1, 2015 at 9:28 AM, Jan Kiszka <jan.kiszka at siemens.com> wrote: > On 2015-09-01 18:02, Michael S. Tsirkin wrote: ... >> You don't need to be able to map all guest memory if you know >> guest won't try to allow device access to all of it. >> It's a question of how good is the bus address allocator. > > But those BARs need to allocate a

On Tue, Sep 01, 2015 at 05:01:07PM -0700, Nakajima, Jun wrote: > On Tue, Sep 1, 2015 at 9:28 AM, Jan Kiszka <jan.kiszka at siemens.com> wrote: > > On 2015-09-01 18:02, Michael S. Tsirkin wrote: > ... > >> You don't need to be able to map all guest memory if you know > >> guest won't try to allow device access to all of it. > >> It's a

BTW, can you please take a look at the following URL to see my understanding is correct? Our engineers are saying that they are not really sure if they understood your proposal (especially around IOMMU), and I drew a figure, adding notes... https://wiki.opnfv.org/vm2vm_mst Thanks, -- Jun Intel Open Source Technology Center

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

On Mon, Aug 31, 2015 at 05:11:02PM +0300, Michael S. Tsirkin wrote: > The resulting channel might look something like the following: > > +-- VM1 --------------+ +---VM2-----------+ > | virtio-pci -- iommu +--+ vhost-pci -- VF | -- VFIO -- IOMMU -- NIC > +---------------------+ +-----------------+ > > comparing the two diagrams, a vhost-user thread on the host is > no

On Tue, Sep 01, 2015 at 05:01:07PM -0700, Nakajima, Jun wrote: > On Tue, Sep 1, 2015 at 9:28 AM, Jan Kiszka <jan.kiszka at siemens.com> wrote: > > On 2015-09-01 18:02, Michael S. Tsirkin wrote: > ... > >> You don't need to be able to map all guest memory if you know > >> guest won't try to allow device access to all of it. > >> It's a

On Mon, Aug 31, 2015 at 05:11:02PM +0300, Michael S. Tsirkin wrote: > The resulting channel might look something like the following: > > +-- VM1 --------------+ +---VM2-----------+ > | virtio-pci -- iommu +--+ vhost-pci -- VF | -- VFIO -- IOMMU -- NIC > +---------------------+ +-----------------+ > > comparing the two diagrams, a vhost-user thread on the host is > no

..., is to allow inter-vm communication with polling (to get very low latencies) but polling within VMs only, without need to run a host thread (which when polling uses up a host CPU). What was proposed was to simply change virtio to allow "offset within BAR" instead of PA. This would allow VM2VM communication if there are only 2 VMs, but if data needs to be sent to multiple VMs, you must copy it. Additionally, it's a single-purpose feature: you can use it from a userspace PMD but linux will never use it. My proposal is a superset: don't require that BAR memory is used, use IOMMU...

On Tue, Sep 01, 2015 at 04:09:44PM +0200, Jan Kiszka wrote: > On 2015-09-01 11:24, Michael S. Tsirkin wrote: > > On Tue, Sep 01, 2015 at 11:11:52AM +0200, Jan Kiszka wrote: > >> On 2015-09-01 10:01, Michael S. Tsirkin wrote: > >>> On Tue, Sep 01, 2015 at 09:35:21AM +0200, Jan Kiszka wrote: > >>>> Leaving all the implementation and interface details

...to allow > > "offset within BAR" instead of PA. > > There are many consequences to this, offset within BAR alone is not enough, there are multiple things at the virtio level that need sorting out. > Also we need to consider virtio-mmio etc. > > > This would allow VM2VM communication if there are only 2 VMs, > > but if data needs to be sent to multiple VMs, you > > must copy it. > > Not necessarily, however getting it to work (sharing the backend window and arbitrating the multicast) is really hard. > > > > > Additionally, it...

On Tue, Sep 01, 2015 at 05:34:37PM +0200, Jan Kiszka wrote: > On 2015-09-01 16:34, Michael S. Tsirkin wrote: > > On Tue, Sep 01, 2015 at 04:09:44PM +0200, Jan Kiszka wrote: > >> On 2015-09-01 11:24, Michael S. Tsirkin wrote: > >>> On Tue, Sep 01, 2015 at 11:11:52AM +0200, Jan Kiszka wrote: > >>>> On 2015-09-01 10:01, Michael S. Tsirkin wrote: >

On 2015-09-01 10:01, Michael S. Tsirkin wrote: > On Tue, Sep 01, 2015 at 09:35:21AM +0200, Jan Kiszka wrote: >> Leaving all the implementation and interface details aside, this >> discussion is first of all about two fundamentally different approaches: >> static shared memory windows vs. dynamically remapped shared windows (a >> third one would be copying in the

On 2015-09-01 10:01, Michael S. Tsirkin wrote: > On Tue, Sep 01, 2015 at 09:35:21AM +0200, Jan Kiszka wrote: >> Leaving all the implementation and interface details aside, this >> discussion is first of all about two fundamentally different approaches: >> static shared memory windows vs. dynamically remapped shared windows (a >> third one would be copying in the

On Tue, Sep 01, 2015 at 09:35:21AM +0200, Jan Kiszka wrote: > On 2015-08-31 16:11, Michael S. Tsirkin wrote: > > Hello! > > During the KVM forum, we discussed supporting virtio on top > > of ivshmem. > > No, not on top of ivshmem. On top of shared memory. Our model is > different from the simplistic ivshmem. > > > I have considered it, and came up with an

On Thu, Sep 03, 2015 at 10:21:28AM +0200, Jan Kiszka wrote: > On 2015-09-03 10:08, Michael S. Tsirkin wrote: > > On Tue, Sep 01, 2015 at 06:28:28PM +0200, Jan Kiszka wrote: > >> On 2015-09-01 18:02, Michael S. Tsirkin wrote: > >>> On Tue, Sep 01, 2015 at 05:34:37PM +0200, Jan Kiszka wrote: > >>>> On 2015-09-01 16:34, Michael S. Tsirkin wrote: >

On Tue, Sep 01, 2015 at 06:28:28PM +0200, Jan Kiszka wrote: > On 2015-09-01 18:02, Michael S. Tsirkin wrote: > > On Tue, Sep 01, 2015 at 05:34:37PM +0200, Jan Kiszka wrote: > >> On 2015-09-01 16:34, Michael S. Tsirkin wrote: > >>> On Tue, Sep 01, 2015 at 04:09:44PM +0200, Jan Kiszka wrote: > >>>> On 2015-09-01 11:24, Michael S. Tsirkin wrote: >

...d was to simply change virtio to allow > "offset within BAR" instead of PA. There are many consequences to this, offset within BAR alone is not enough, there are multiple things at the virtio level that need sorting out. Also we need to consider virtio-mmio etc. > This would allow VM2VM communication if there are only 2 VMs, > but if data needs to be sent to multiple VMs, you > must copy it. Not necessarily, however getting it to work (sharing the backend window and arbitrating the multicast) is really hard. > > Additionally, it's a single-purpose feature: you c...

...d was to simply change virtio to allow > "offset within BAR" instead of PA. There are many consequences to this, offset within BAR alone is not enough, there are multiple things at the virtio level that need sorting out. Also we need to consider virtio-mmio etc. > This would allow VM2VM communication if there are only 2 VMs, > but if data needs to be sent to multiple VMs, you > must copy it. Not necessarily, however getting it to work (sharing the backend window and arbitrating the multicast) is really hard. > > Additionally, it's a single-purpose feature: you c...

...August 31, 2015 1:36 PM > To: Michael S. Tsirkin > Cc: virtio-dev at lists.oasis-open.org; Jan Kiszka; > Claudio.Fontana at huawei.com; qemu-devel at nongnu.org; Linux > Virtualization; opnfv-tech-discuss at lists.opnfv.org > Subject: Re: [Qemu-devel] rfc: vhost user enhancements for vm2vm > communication > > On Mon, Aug 31, 2015 at 7:11 AM, Michael S. Tsirkin <mst at redhat.com> > 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 > > h...