On Wed, Dec 15, 2021 at 10:10:35AM +0000, Peter Maydell wrote: > On Wed, 15 Dec 2021 at 08:18, Amir Gonnen <amir.gon...@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. > > > 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. > > I agree with Stefan that you should go ahead and send the code as > an RFC patchset, but I feel like there is a lot of work required > to really get the codebase into a state where it is a clean > shared library...
I expect there could end up being a big difference between "clean for use with QEMU CLI config X" vs "clean for use with all possible QEMU CLI configs" Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
