[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Towards an ivshmem 2.0?
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] Towards an ivshmem 2.0? |
Date: |
Tue, 17 Jan 2017 10:00:05 +0000 |
User-agent: |
Mutt/1.7.1 (2016-10-04) |
On Mon, Jan 16, 2017 at 03:34:58PM +0100, Jan Kiszka wrote:
> On 2017-01-16 15:18, Stefan Hajnoczi wrote:
> > On Mon, Jan 16, 2017 at 09:36:51AM +0100, Jan Kiszka wrote:
> >> some of you may know that we are using a shared memory device similar to
> >> ivshmem in the partitioning hypervisor Jailhouse [1].
> >>
> >> We started as being compatible to the original ivshmem that QEMU
> >> implements, but we quickly deviated in some details, and in the recent
> >> months even more. Some of the deviations are related to making the
> >> implementation simpler. The new ivshmem takes <500 LoC - Jailhouse is
> >> aiming at safety critical systems and, therefore, a small code base.
> >> Other changes address deficits in the original design, like missing
> >> life-cycle management.
> >
> > My first thought is "what about virtio?". Can you share some background
> > on why ivshmem fits the use case better than virtio?
> >
> > The reason I ask is because the ivshmem devices you define would have
> > parallels to existing virtio devices and this could lead to duplication.
>
> virtio was created as an interface between a host and a guest. It has no
> notion of direct (or even symmetric) connection between guests. With
> ivshmem, we want to establish only a minimal host-guest interface. We
> want to keep the host out of the business negotiating protocol details
> between two connected guests.
>
> So, the trade-off was between reusing existing virtio drivers - in the
> best case, some changes would have been required definitely - and
> requiring complex translation of virtio into a vm-to-vm model on the one
> side and establishing a new driver ecosystem on much simpler host
> services (500 LoC...). We went for the latter.
Thanks. I was going in the same direction about vhost-pci as
Marc-André. Let's switch to his sub-thread.
Stefan
signature.asc
Description: PGP signature
- Re: [Qemu-devel] Towards an ivshmem 2.0?, (continued)
- Re: [Qemu-devel] Towards an ivshmem 2.0?, Wang, Wei W, 2017/01/20
- Re: [Qemu-devel] Towards an ivshmem 2.0?, Jan Kiszka, 2017/01/20
- Re: [Qemu-devel] Towards an ivshmem 2.0?, Wang, Wei W, 2017/01/22
- Re: [Qemu-devel] Towards an ivshmem 2.0?, Måns Rullgård, 2017/01/23
- Re: [Qemu-devel] Towards an ivshmem 2.0?, Stefan Hajnoczi, 2017/01/17
- Re: [Qemu-devel] Towards an ivshmem 2.0?, Jan Kiszka, 2017/01/17
- Re: [Qemu-devel] Towards an ivshmem 2.0?, msuchanek, 2017/01/29
- Re: [Qemu-devel] Towards an ivshmem 2.0?, Stefan Hajnoczi, 2017/01/30
Re: [Qemu-devel] Towards an ivshmem 2.0?, Stefan Hajnoczi, 2017/01/16
Re: [Qemu-devel] Towards an ivshmem 2.0?, Markus Armbruster, 2017/01/23
- Re: [Qemu-devel] Towards an ivshmem 2.0?, Jan Kiszka, 2017/01/25
- Re: [Qemu-devel] Towards an ivshmem 2.0?, Markus Armbruster, 2017/01/27
- Re: [Qemu-devel] Towards an ivshmem 2.0?, Jan Kiszka, 2017/01/29
- Re: [Qemu-devel] Towards an ivshmem 2.0?, Marc-André Lureau, 2017/01/29
- Re: [Qemu-devel] Towards an ivshmem 2.0?, Jan Kiszka, 2017/01/29
- Re: [Qemu-devel] Towards an ivshmem 2.0?, Markus Armbruster, 2017/01/30
- Re: [Qemu-devel] Towards an ivshmem 2.0?, Jan Kiszka, 2017/01/30
- Re: [Qemu-devel] Towards an ivshmem 2.0?, Wang, Wei W, 2017/01/30
Re: [Qemu-devel] Towards an ivshmem 2.0?, Markus Armbruster, 2017/01/30