sridhar kulkarni <[email protected]> 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'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..
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.
