Re: Building QEMU as a shared library

[Peter Maydell]

On Thu, 23 Dec 2021 at 09:49, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>
> Hi Peter,
>
> On 12/15/21 11:10, Peter Maydell wrote:
> > On Wed, 15 Dec 2021 at 08:18, Amir Gonnen <amir.gonnen@neuroblade.ai> wrote:
> >> 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.
> >
> > Yeah. This is definitely something we'd like to fix some day. It's
> > the approach I would prefer for getting multi-architecture machines.
>
> Am I understanding correctly your preference would be *not* using shared
> libraries, but having a monolithic process able to use any configuration
> of heterogeneous architectures?

That would be my preference, yes. On the other hand I know there's
a lot of work in trying to get there, so I don't want to rule out the
idea that maybe pragmatically we do something else instead.

> What are your thoughts on Daniel idea to where (IIUC) cores can are
> external processes wired via vhost-user.

It sounds a bit awkward to me -- you end up with a system where
QEMU's scheduler between vCPUs is no longer the only thing deciding
what gets to run. (eg, how do you emulate atomic accesses? currently
we do those by "stop all other CPUs, do the thing, restart" for the
cases where we can't rely on the host's atomic insns.)
The multiple-host-processes model can certainly be made to work,
though -- AIUI this is how Xilinx's out-of-tree stuff works.

-- PMM