qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Markus Armbruster
Subject: Re: [Qemu-devel] IVSHMEM support on qemu-system-arm
Date: Mon, 15 Feb 2016 10:41:57 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

sridhar kulkarni <address@hidden> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]