All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: Jan Kiszka <jan.kiszka@siemens.com>,
	Henning Schild <henning.schild@siemens.com>,
	qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org,
	kvm@vger.kernel.org
Subject: Re: Using virtio for inter-VM communication
Date: Fri, 13 Jun 2014 10:17:37 +0930	[thread overview]
Message-ID: <87fvj9prdi.fsf@rustcorp.com.au> (raw)
In-Reply-To: <53993B7B.7010404@siemens.com>

Jan Kiszka <jan.kiszka@siemens.com> writes:
> On 2014-06-12 04:27, Rusty Russell wrote:
>> Henning Schild <henning.schild@siemens.com> writes:
>> It was also never implemented, and remains a thought experiment.
>> However, implementing it in lguest should be fairly easy.
>
> The reason why a trusted helper, i.e. additional logic in the
> hypervisor, is not our favorite solution is that we'd like to keep the
> hypervisor as small as possible. I wouldn't exclude such an approach
> categorically, but we have to weigh the costs (lines of code, additional
> hypervisor interface) carefully against the gain (existing
> specifications and guest driver infrastructure).

Reasonable, but I think you'll find it is about the minimal
implementation in practice.  Unfortunately, I don't have time during the
next 6 months to implement it myself :(

> Back to VIRTIO_F_RING_SHMEM_ADDR (which you once brought up in an MCA
> working group discussion): What speaks against introducing an
> alternative encoding of addresses inside virtio data structures? The
> idea of this flag was to replace guest-physical addresses with offsets
> into a shared memory region associated with or part of a virtio
> device.

We would also need a way of defining the shared memory region.  But
that's not the problem.  If such a feature is not accepted by the guest?
How to you fall back?

We don't add features which unmake the standard.

> That would preserve zero-copy capabilities (as long as you can work
> against the shared mem directly, e.g. doing DMA from a physical NIC or
> storage device into it) and keep the hypervisor out of the loop.

This seems ill thought out.  How will you program a NIC via the virtio
protocol without a hypervisor?  And how will you make it safe?  You'll
need an IOMMU.  But if you have an IOMMU you don't need shared memory.

> Is it
> too invasive to existing infrastructure or does it have some other pitfalls?

You'll have to convince every vendor to implement your addition to the
standard.  Which is easier than inventing a completely new system, but
it's not quite virtio.

Cheers,
Rusty.

WARNING: multiple messages have this Message-ID (diff)
From: Rusty Russell <rusty@rustcorp.com.au>
To: Jan Kiszka <jan.kiszka@siemens.com>,
	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: Fri, 13 Jun 2014 10:17:37 +0930	[thread overview]
Message-ID: <87fvj9prdi.fsf@rustcorp.com.au> (raw)
In-Reply-To: <53993B7B.7010404@siemens.com>

Jan Kiszka <jan.kiszka@siemens.com> writes:
> On 2014-06-12 04:27, Rusty Russell wrote:
>> Henning Schild <henning.schild@siemens.com> writes:
>> It was also never implemented, and remains a thought experiment.
>> However, implementing it in lguest should be fairly easy.
>
> The reason why a trusted helper, i.e. additional logic in the
> hypervisor, is not our favorite solution is that we'd like to keep the
> hypervisor as small as possible. I wouldn't exclude such an approach
> categorically, but we have to weigh the costs (lines of code, additional
> hypervisor interface) carefully against the gain (existing
> specifications and guest driver infrastructure).

Reasonable, but I think you'll find it is about the minimal
implementation in practice.  Unfortunately, I don't have time during the
next 6 months to implement it myself :(

> Back to VIRTIO_F_RING_SHMEM_ADDR (which you once brought up in an MCA
> working group discussion): What speaks against introducing an
> alternative encoding of addresses inside virtio data structures? The
> idea of this flag was to replace guest-physical addresses with offsets
> into a shared memory region associated with or part of a virtio
> device.

We would also need a way of defining the shared memory region.  But
that's not the problem.  If such a feature is not accepted by the guest?
How to you fall back?

We don't add features which unmake the standard.

> That would preserve zero-copy capabilities (as long as you can work
> against the shared mem directly, e.g. doing DMA from a physical NIC or
> storage device into it) and keep the hypervisor out of the loop.

This seems ill thought out.  How will you program a NIC via the virtio
protocol without a hypervisor?  And how will you make it safe?  You'll
need an IOMMU.  But if you have an IOMMU you don't need shared memory.

> Is it
> too invasive to existing infrastructure or does it have some other pitfalls?

You'll have to convince every vendor to implement your addition to the
standard.  Which is easier than inventing a completely new system, but
it's not quite virtio.

Cheers,
Rusty.

  reply	other threads:[~2014-06-13  0:47 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 ` Using virtio for inter-VM communication Rusty Russell
2014-06-12  2:27   ` 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 [this message]
2014-06-13  0:47       ` 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=87fvj9prdi.fsf@rustcorp.com.au \
    --to=rusty@rustcorp.com.au \
    --cc=henning.schild@siemens.com \
    --cc=jan.kiszka@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.