On 2014-06-17 07:24, Paolo Bonzini wrote:
Il 15/06/2014 08:20, Jan Kiszka ha scritto:
I think implementing Xen hypercalls in jailhouse for grant table and
event channels would actually make a lot of sense. The Xen
implementation is 2.5kLOC and I think it should be possible to compact
it
Il 15/06/2014 08:20, Jan Kiszka ha scritto:
I think implementing Xen hypercalls in jailhouse for grant table and
event channels would actually make a lot of sense. The Xen
implementation is 2.5kLOC and I think it should be possible to compact
it noticeably, especially if you limit yourself
On 2014-06-13 10:45, Paolo Bonzini wrote:
Il 13/06/2014 08:23, Jan Kiszka ha scritto:
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.
Il 13/06/2014 08:23, Jan Kiszka ha scritto:
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
On 2014-06-13 02:47, Rusty Russell wrote:
Jan Kiszka jan.kis...@siemens.com writes:
On 2014-06-12 04:27, Rusty Russell wrote:
Henning Schild henning.sch...@siemens.com writes:
It was also never implemented, and remains a thought experiment.
However, implementing it in lguest should be fairly
Vincent JARDIN vincent.jar...@6wind.com writes:
On 10/06/2014 18:48, Henning Schild wrote: Hi,
In a first prototype i implemented a ivshmem[2] device for the
hypervisor. That way we can share memory between virtual machines.
Ivshmem is nice and simple but does not seem to be used anymore.
On Thu, 12 Jun 2014 08:48:04 +0200
Markus Armbruster arm...@redhat.com wrote:
Vincent JARDIN vincent.jar...@6wind.com writes:
On 10/06/2014 18:48, Henning Schild wrote: Hi,
In a first prototype i implemented a ivshmem[2] device for the
hypervisor. That way we can share memory between
On 12/06/2014 09:44, Henning Schild wrote:
It may be used, but that doesn't mean it's maintained, or robust
against abuse. My advice is to steer clear of it.
Could you elaborate on why you advice against it?
+1 elaborate please.
beside the DPDK source code, some other common use cases:
-
Henning Schild henning.sch...@siemens.com writes:
On Thu, 12 Jun 2014 08:48:04 +0200
Markus Armbruster arm...@redhat.com wrote:
Vincent JARDIN vincent.jar...@6wind.com writes:
On 10/06/2014 18:48, Henning Schild wrote: Hi,
In a first prototype i implemented a ivshmem[2] device for the
Jan Kiszka jan.kis...@siemens.com writes:
On 2014-06-12 04:27, Rusty Russell wrote:
Henning Schild henning.sch...@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,
On 10/06/2014 18:48, Henning Schild wrote: Hi,
In a first prototype i implemented a ivshmem[2] device for the
hypervisor. That way we can share memory between virtual machines.
Ivshmem is nice and simple but does not seem to be used anymore.
And it
does not define higher level devices, like
Henning Schild henning.sch...@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
On 2014-06-12 04:27, Rusty Russell wrote:
Henning Schild henning.sch...@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
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
14 matches
Mail list logo
