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.
next prev parent 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: linkBe 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.