[Qemu-devel] IVSHMEM support on qemu-system-arm

[Qemu-devel] IVSHMEM support on qemu-system-arm

[sridhar kulkarni]

[-- Attachment #1: Type: text/plain, Size: 443 bytes --]

Hi,
I am working on a requirement where I need to have shared memory IPC between two guest VM's running different OS. Both VM's use vexpress-A9 boards. I came across the "ivshmem" implementation and have some questions. Whether the "ivshmem" implementation can be used on qemu-system-arm? I understand that "ivshmem" device is a PCI device and require PCI bus to connect to. Does vexpress board support this kind of arrangement?
RegardsSridhar

[-- Attachment #2: Type: text/html, Size: 972 bytes --]

Re: [Qemu-devel] IVSHMEM support on qemu-system-arm

[Peter Maydell]

On 12 February 2016 at 15:05, sridhar kulkarni <sridhar_kulk@yahoo.com> wrote:
> I am working on a requirement where I need to have shared memory IPC between
> two guest VM's running different OS. Both VM's use vexpress-A9 boards. I
> came across the "ivshmem" implementation and have some questions. Whether
> the "ivshmem" implementation can be used on qemu-system-arm? I understand
> that "ivshmem" device is a PCI device and require PCI bus to connect to.
> Does vexpress board support this kind of arrangement?

No, there is no PCI bus on vexpress. If you need PCI you'll have to
switch to 'virt' instead.

thanks
-- PMM

Re: [Qemu-devel] IVSHMEM support on qemu-system-arm

[Markus Armbruster]

sridhar kulkarni <sridhar_kulk@yahoo.com> writes:

> Hi,
> I am working on a requirement where I need to have shared memory IPC
> between two guest VM's running different OS. Both VM's use vexpress-A9
> boards. I came across the "ivshmem" implementation and have some
> questions. Whether the "ivshmem" implementation can be used on
> qemu-system-arm? I understand that "ivshmem" device is a PCI device
> and require PCI bus to connect to. Does vexpress board support this
> kind of arrangement?
> RegardsSridhar

What are you trying to accomplish?

I'm asking because "shared memory" is means towards an end.  Really,
really low-level means, in fact.  Requirements can compel choice of
certain means, but means cannot be requirements.  What are your *real*
requirements?

Re: [Qemu-devel] IVSHMEM support on qemu-system-arm

[sridhar kulkarni]

[-- Attachment #1: Type: text/plain, Size: 663 bytes --]

We have two applications running on real custom board with custom asic and has two arm cores. Each application runs on different core, and uses shared memory for inter application high bandwidth transferss. The trigger for this RPC mailbox communication where each core can send interrupt to other core to initiate a shared memory IPC. 
We are trying to simulate this whole thing on qemu virtual platform by running two vm's. Our goal is to run the whole application as is without any hacks. Application s really shouldn't know if its running on real hardware or virtual platform.
That's the reason I wanted to understand if ivshmem can be used here..

[-- Attachment #2: Type: text/html, Size: 3670 bytes --]

Re: [Qemu-devel] IVSHMEM support on qemu-system-arm

[Markus Armbruster]

sridhar kulkarni <sridhar_kulk@yahoo.com> writes:

> We have two applications running on real custom board with custom asic
> and has two arm cores. Each application runs on different core, and
> uses shared memory for inter application high bandwidth
> transferss. The trigger for this RPC mailbox communication where each
> core can send interrupt to other core to initiate a shared memory IPC.
>
> We are trying to simulate this whole thing on qemu virtual platform by
> running two vm&#39;s. Our goal is to run the whole application as is
> without any hacks. Application s really shouldn&#39;t know if its
> running on real hardware or virtual platform.
>
> That&#39;s the reason I wanted to understand if ivshmem can be used here..

To "simulate the whole thing" so that your software runs unmodified, you
have to model your board, including the cores, their local memory,
shared memory, and inter-processor interrupts.  Anything less requires
some kind of hardware abstraction layer in your software.  Note that
this would most likely run in a *single* QEMU process.

Less faithful emulation + more hardware abstraction can be cheaper to
build, but it's usually less useful for the purpose of developing
low-level software for the physical board.

With ivshmem, you can share memory among separate QEMU processes, with
an optional interrupt capability.  ivshmem and your ASIC will look quite
different to software, unless you designed your ASIC to look like
ivshmem (and why would anybody do that?).  Your hardware abstraction
layer would have to encapsulate all ASIC access, and implement it
separately for physical hardware and your simulator.

If that much abstraction is fine for you, then I'd seriously consider
abstracting away one more layer: provide an IPC interface, implement it
separately for physical hardware and your simulator.

But if you need a more faithful simulator, you better emulate your
actual hardware.