On Thu, May 26, 2011 at 11:07 PM, Lluís <xscr...@gmx.net> wrote: > Blue Swirl writes: > >> On Wed, May 25, 2011 at 10:20 PM, Peter Maydell >> <peter.mayd...@linaro.org> wrote: >>> On 25 May 2011 19:44, Greg McGary <greg.mcg...@gmail.com> wrote: >>>> I would like to create a QEMU model of an SoC that has several >>>> CPU cores having different architectures. I'm guessing this >>>> can be done. >>> >>> It's not supported currently as far as I'm aware. There was >>> at least one paper at the QEMU Forum earlier this year describing >>> an approach to multi-CPU environments (embedding QEMU into a >>> SystemC world) that basically saved and restored all QEMU's >>> global variables every time it switched cores... >>> >>> It would be good if it was supported in QEMU proper, but I >>> suspect you may be in for some large-scale restructuring work. > >> One of the long standing goals for QEMU has been to be able to use a >> single executable to emulate multiple architectures. I think for >> example the lines like >> #define cpu_init cpu_sparc_init >> #define cpu_exec cpu_sparc_exec >> etc. stand for this purpose, so there has been some consideration for this. > > Nicely handling per-arch functions would be one of the benefits of using > C++ in QEMU (I know, it's sufficient but not necessary). What were the > conclusions regarding such a change?
I don't think the discussions gave enough motivation for the change. There's resistance to qdevification already and that is far from a real object model.
