All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: Henning Schild <henning.schild@siemens.com>,
	qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org,
	kvm@vger.kernel.org
Cc: Henning Schild <henning.schild@siemens.com>
Subject: Re: Using virtio for inter-VM communication
Date: Thu, 12 Jun 2014 11:57:07 +0930	[thread overview]
Message-ID: <87r42uq2v8.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20140610184818.2e490419@nbschild1>

Henning Schild <henning.schild@siemens.com> writes:
> Hi,
>
> i am working on the jailhouse[1] project and am currently looking at
> inter-VM communication. We want to connect guests directly with virtual
> consoles based on shared memory. The code complexity in the hypervisor
> should be minimal, it should just make the shared memory discoverable
> and provide a signaling mechanism.

Hi Henning,

        The virtio assumption was that the host can see all of guest
memory.  This simplifies things significantly, and makes it efficient.

If you don't have this, *someone* needs to do a copy.  Usually the guest
OS does a bounce buffer into your shared region.  Goodbye performance.
Or you can play remapping tricks.  Goodbye performance again.

My preferred model is to have a trusted helper (ie. host) which
understands how to copy between virtio rings.  The backend guest (to
steal Xen vocab) R/O maps the descriptor, avail ring and used rings in
the guest.  It then asks the trusted helper to do various operation
(copy into writable descriptor, copy out of readable descriptor, mark
used).  The virtio ring itself acts as a grant table.

Note: that helper mechanism is completely protocol agnostic.  It was
also explicitly designed into the virtio mechanism (with its 4k
boundaries for data structures and its 'len' field to indicate how much
was written into the descriptor). 

It was also never implemented, and remains a thought experiment.
However, implementing it in lguest should be fairly easy.

Cheers,
Rusty.

WARNING: multiple messages have this Message-ID (diff)
From: Rusty Russell <rusty@rustcorp.com.au>
To: Henning Schild <henning.schild@siemens.com>,
	qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org,
	kvm@vger.kernel.org
Subject: Re: [Qemu-devel] Using virtio for inter-VM communication
Date: Thu, 12 Jun 2014 11:57:07 +0930	[thread overview]
Message-ID: <87r42uq2v8.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20140610184818.2e490419@nbschild1>

Henning Schild <henning.schild@siemens.com> writes:
> Hi,
>
> i am working on the jailhouse[1] project and am currently looking at
> inter-VM communication. We want to connect guests directly with virtual
> consoles based on shared memory. The code complexity in the hypervisor
> should be minimal, it should just make the shared memory discoverable
> and provide a signaling mechanism.

Hi Henning,

        The virtio assumption was that the host can see all of guest
memory.  This simplifies things significantly, and makes it efficient.

If you don't have this, *someone* needs to do a copy.  Usually the guest
OS does a bounce buffer into your shared region.  Goodbye performance.
Or you can play remapping tricks.  Goodbye performance again.

My preferred model is to have a trusted helper (ie. host) which
understands how to copy between virtio rings.  The backend guest (to
steal Xen vocab) R/O maps the descriptor, avail ring and used rings in
the guest.  It then asks the trusted helper to do various operation
(copy into writable descriptor, copy out of readable descriptor, mark
used).  The virtio ring itself acts as a grant table.

Note: that helper mechanism is completely protocol agnostic.  It was
also explicitly designed into the virtio mechanism (with its 4k
boundaries for data structures and its 'len' field to indicate how much
was written into the descriptor). 

It was also never implemented, and remains a thought experiment.
However, implementing it in lguest should be fairly easy.

Cheers,
Rusty.

WARNING: multiple messages have this Message-ID (diff)
From: Rusty Russell <rusty@rustcorp.com.au>
To: qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org,
	kvm@vger.kernel.org
Cc: Henning Schild <henning.schild@siemens.com>
Subject: Re: Using virtio for inter-VM communication
Date: Thu, 12 Jun 2014 11:57:07 +0930	[thread overview]
Message-ID: <87r42uq2v8.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20140610184818.2e490419@nbschild1>

Henning Schild <henning.schild@siemens.com> writes:
> Hi,
>
> i am working on the jailhouse[1] project and am currently looking at
> inter-VM communication. We want to connect guests directly with virtual
> consoles based on shared memory. The code complexity in the hypervisor
> should be minimal, it should just make the shared memory discoverable
> and provide a signaling mechanism.

Hi Henning,

        The virtio assumption was that the host can see all of guest
memory.  This simplifies things significantly, and makes it efficient.

If you don't have this, *someone* needs to do a copy.  Usually the guest
OS does a bounce buffer into your shared region.  Goodbye performance.
Or you can play remapping tricks.  Goodbye performance again.

My preferred model is to have a trusted helper (ie. host) which
understands how to copy between virtio rings.  The backend guest (to
steal Xen vocab) R/O maps the descriptor, avail ring and used rings in
the guest.  It then asks the trusted helper to do various operation
(copy into writable descriptor, copy out of readable descriptor, mark
used).  The virtio ring itself acts as a grant table.

Note: that helper mechanism is completely protocol agnostic.  It was
also explicitly designed into the virtio mechanism (with its 4k
boundaries for data structures and its 'len' field to indicate how much
was written into the descriptor). 

It was also never implemented, and remains a thought experiment.
However, implementing it in lguest should be fairly easy.

Cheers,
Rusty.

  parent reply	other threads:[~2014-06-12  2:27 UTC|newest]

Thread overview: 92+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-10 16:48 Using virtio for inter-VM communication Henning Schild
2014-06-10 16:48 ` [Qemu-devel] " Henning Schild
2014-06-10 22:15 ` Vincent JARDIN
2014-06-10 22:15 ` Vincent JARDIN
2014-06-10 22:15   ` [Qemu-devel] " Vincent JARDIN
2014-06-12  6:48   ` Markus Armbruster
2014-06-12  6:48   ` Markus Armbruster
2014-06-12  6:48     ` [Qemu-devel] " Markus Armbruster
2014-06-12  7:44     ` Henning Schild
2014-06-12  7:44       ` [Qemu-devel] " Henning Schild
2014-06-12  9:31       ` Vincent JARDIN
2014-06-12  9:31       ` Vincent JARDIN
2014-06-12  9:31         ` [Qemu-devel] " Vincent JARDIN
2014-06-12 12:55       ` Markus Armbruster
2014-06-12 14:40       ` Why I advise against using ivshmem (was: [Qemu-devel] Using virtio for inter-VM communication) Markus Armbruster
2014-06-12 14:40       ` Markus Armbruster
2014-06-12 14:40         ` [Qemu-devel] Why I advise against using ivshmem (was: " Markus Armbruster
2014-06-12 16:02         ` Why I advise against using ivshmem Vincent JARDIN
2014-06-12 16:02           ` [Qemu-devel] " Vincent JARDIN
2014-06-12 16:54           ` Paolo Bonzini
2014-06-12 16:54             ` [Qemu-devel] " Paolo Bonzini
2014-06-13  8:46           ` Markus Armbruster
2014-06-13  9:26             ` Vincent JARDIN
2014-06-13  9:31               ` Jobin Raju George
2014-06-13  9:31                 ` Jobin Raju George
2014-06-13  9:31               ` Jobin Raju George
2014-06-13  9:48               ` Olivier MATZ
2014-06-13  9:48               ` Olivier MATZ
2014-06-13  9:48                 ` Olivier MATZ
2014-06-13 10:09               ` Paolo Bonzini
2014-06-13 13:41                 ` Vincent JARDIN
2014-06-13 13:41                 ` Vincent JARDIN
2014-06-13 13:41                   ` Vincent JARDIN
2014-06-13 14:10                   ` Paolo Bonzini
2014-06-13 14:10                     ` Paolo Bonzini
2014-06-14 18:01                     ` Vincent JARDIN
2014-06-14 18:01                       ` Vincent JARDIN
2014-06-17  2:54                     ` Stefan Hajnoczi
2014-06-17  9:03                       ` David Marchand
2014-06-17  9:03                         ` David Marchand
2014-06-17  9:44                         ` Paolo Bonzini
2014-06-18 10:48                           ` Stefan Hajnoczi
2014-06-18 10:48                             ` Stefan Hajnoczi
2014-06-18 14:57                             ` David Marchand
2014-06-18 14:57                             ` David Marchand
2014-06-18 14:57                               ` David Marchand
2014-06-18 15:10                               ` Paolo Bonzini
2014-06-21  9:34                               ` Stefan Hajnoczi
2014-06-26 20:02                                 ` Cam Macdonell
2014-06-26 20:02                                   ` Cam Macdonell
2014-06-18 15:01                             ` Andreas Färber
2014-06-18 15:01                               ` Andreas Färber
2014-06-19  8:25                               ` David Marchand
2014-06-19  8:25                                 ` David Marchand
2014-06-19  8:25                               ` David Marchand
2014-06-18 15:01                             ` Andreas Färber
2014-06-30 11:10                             ` Markus Armbruster
2014-06-30 11:10                             ` Markus Armbruster
2014-06-30 11:10                               ` Markus Armbruster
2014-06-18 10:51                         ` Stefan Hajnoczi
2014-06-18 10:51                           ` Stefan Hajnoczi
2014-06-18 14:58                           ` David Marchand
2014-06-18 14:58                           ` David Marchand
2014-06-18 14:58                             ` David Marchand
2014-06-18 14:22                         ` Claudio Fontana
2014-06-17  9:03                       ` David Marchand
2014-06-13  9:29             ` Jobin Raju George
2014-06-13  9:29               ` [Qemu-devel] " Jobin Raju George
2014-06-13  9:29             ` Jobin Raju George
2014-06-12 16:02         ` Vincent JARDIN
2014-06-12  2:27 ` Rusty Russell [this message]
2014-06-12  2:27   ` Using virtio for inter-VM communication Rusty Russell
2014-06-12  2:27   ` [Qemu-devel] " Rusty Russell
2014-06-12  5:32   ` Jan Kiszka
2014-06-12  5:32     ` [Qemu-devel] " Jan Kiszka
2014-06-13  0:47     ` Rusty Russell
2014-06-13  0:47       ` [Qemu-devel] " Rusty Russell
2014-06-13  6:23       ` Jan Kiszka
2014-06-13  6:23         ` [Qemu-devel] " Jan Kiszka
2014-06-13  8:45         ` Paolo Bonzini
2014-06-13  8:45           ` [Qemu-devel] " Paolo Bonzini
2014-06-15  6:20           ` Jan Kiszka
2014-06-15  6:20           ` Jan Kiszka
2014-06-15  6:20             ` [Qemu-devel] " Jan Kiszka
2014-06-17  5:24             ` Paolo Bonzini
2014-06-17  5:24               ` [Qemu-devel] " Paolo Bonzini
2014-06-17  5:57               ` Jan Kiszka
2014-06-17  5:57               ` Jan Kiszka
2014-06-17  5:57                 ` [Qemu-devel] " Jan Kiszka
2014-06-17  5:24             ` Paolo Bonzini
2014-06-12  5:32   ` Jan Kiszka
2014-06-10 16:48 Henning Schild

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r42uq2v8.fsf@rustcorp.com.au \
    --to=rusty@rustcorp.com.au \
    --cc=henning.schild@siemens.com \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.