[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Building QEMU as a shared library
From: |
Stefan Hajnoczi |
Subject: |
Re: Building QEMU as a shared library |
Date: |
Wed, 15 Dec 2021 09:45:56 +0000 |
On Wed, Dec 15, 2021 at 08:18:53AM +0000, Amir Gonnen wrote:
> Before sending a patch, I would like to check if it's of interest to the
> community.
>
> My goal is to simulate a mixed architecture system.
> Today QEMU strongly assumes that the simulated system is a *single
> architecture*.
> Changing this assumption and supporting mixed architecture in QEMU proved to
> be
> non-trivial and may require significant development effort. Common code such
> as
> TCG and others explicitly include architecture specific header files, for
> example.
Hi Amir,
Simulating heterogenous machines comes up from periodically. So far no
one has upstreamed a solution but there is definitely interest.
I suggest going ahead and posting the code even if it's not cleaned up.
> A possible solution, discussed on https://stackoverflow.com/q/63229262/619493
> is to
> separate the simulation to multiple processes (as done by Xilinx) and to use
> some form
> of Interprocess Communication channel between them.
> Such solution has several disadvantages:
>
> - Harder to synchronize simulation between processes
> - Performance impact of Interprocess Communication
> - Harder to debug, profile and maintain
>
> Instead, I would like to suggest a new approach we use at Neuroblade to
> achieve this:
> Build QEMU as a shared library that can be loaded and used directly in a
> larger simulation.
> Today we build qemu-system-nios2 shared library and load it from
> qemu-system-x86_64 in order
> to simulate an x86_64 system that also consists of multiple nios2 cores.
> In our simulation, two independent "main" functions are running on different
> threads, and
> simulation synchronization is reduced to synchronizing threads.
>
> To achieve this, I needed to do the following changes in QEMU:
>
> 1. Avoid Glib global context. Use a different context (g_main_context_new)
> for each QEMU instance.
> 2. Change meson.build to build QEMU as a shared library (with PIC enabled for
> static libraries)
> 3. Define a C API for the library and export it (with a -Wl,--version-script)
>
> These changes seem enough for simulating mixed architecture system on a
> single process.
>
> If this approach sounds useful, I'll be happy to send patches.
> I'd appreciate if you could provide your feedback!
I'm curious how much synchronization and IPC there is between the QEMU
shared libraries? I would have guessed that the pain of making
communication work efficiently between processes would be less than the
pain of solving global state bugs related to shared libraries within a
single process.
Were there issues with POSIX signal handlers?
Stefan
signature.asc
Description: PGP signature