Re: [Qemu-devel] Multi heterogenous CPU archs for SoC sim?
My use case here is testing and debugging, so I think we could live with the blocks being executed in an interleaved fashion until someone has the ultimate parallelization solution for upstream. So you prefer parallelizing QEMU itself in your case? -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667
Re: [Qemu-devel] Multi heterogenous CPU archs for SoC sim?
On 21 October 2011 23:05, Andreas Färber andreas.faer...@web.de wrote: Am 21.10.2011 08:58, schrieb Peter Maydell: (For several of the ARM boards we currently just ignore the fact that the real h/w has a Cortex-M3 doing power management type stuff.) Mind to share which boards? I'm only aware of the NXP LPC43xx asymmetric SoC (Cortex-M4 + Cortex-M0), which still is in development stage. I had in mind the Versatile Express -- the main core is an A9x4 but there is also an M3 on the board. (There are some other interestng ARM based heterogeneous architectures coming up too, like the nVidia Tegra3 with 4xA9+1xA9, and the ARM big.LITTLE systems with 4xA7+4xA15.) The datasheet doesn't really enlighten me how such a combo is supposed to work in shared memory: Do all ARM cores share a reset vector (or what you call it on arm) so that one has to branch based on CPUID to do different tasks on different cores? In general a multicore bootup will use the core ID to figure out what it is at reset. I don't know what a multicluster system would do, but probably the same thing. The other approach I've seen is that you can give the two CPUs different memory maps so they share most things but have different memory layouts where the vector table/startup code is. Or you could have the power controller hold the secondary core in reset until the primary core has booted, and have your boot code work differently for first and second execution, I guess. (The reset architecture on M profile and AR profiles is different, but I don't think the differences are important for these purposes.) -- PMM
Re: [Qemu-devel] Multi heterogenous CPU archs for SoC sim?
On 20 October 2011 23:51, Andreas Färber andreas.faer...@web.de wrote: I have now come across such a heterogeneous SoC myself: Renesas announced the R-Car H1 this week, a SoC with one SH4A core and four ARM Cortex-A9 cores. Does it expose the SH4 to apps/OSes, or is it mostly used for power management or similar ignorable duties? (For several of the ARM boards we currently just ignore the fact that the real h/w has a Cortex-M3 doing power management type stuff.) That would make them all 32-bit, and I am hoping to get confirmation that this is consistently Little Endian. I think the endianness is a red herring for heterogenous systems anyway -- what QEMU defines as the target endianness is really something more like the system bus endianness, as far as I can tell. An extra core with a different idea of endianness shouldn't be any harder to handle than cores which can switch endianness at runtime. You just either insert swizzling or not. The only realistic way to get started with such setups I see is to create a new target-xxx for the specific mix, define TARGET_LONG_BITS etc. appropriately in a new cpu.h, compile the needed target-xyz/*.c to unique xxx-softmmu/xyz-*.o and dispatch from a cpu_init() to the two cpu_*_init(). Yuck. Longer term if we want to support this kind of heterogeneity we should be removing all the compile-time assumptions and generally making the target-specifics suitably contained rather than leaking into the rest of the code. I'm guessing we may need to distinguish the TBs at runtime? Reserving log2(#architectures) bits in the TBFLAGS might do, but feels ugly. Probably a lot of other issues I'm not seeing yet. We may want the tb cache to be per-core anyway (and one thread per core), which would avoid the problem of trying to wedge everything into one set of tb_flags. (Has anybody had a look at http://sourceforge.net/p/coremu/home/Home/ ?) -- PMM
Re: [Qemu-devel] Multi heterogenous CPU archs for SoC sim?
We may want the tb cache to be per-core anyway (and one thread per core), which would avoid the problem of trying to wedge everything into one set of tb_flags. (Has anybody had a look at http://sourceforge.net/p/coremu/home/Home/ ?) COREMU treats QEMU as an entity and lauches multiple QEMUs at the same time. QEMUs communicates to each other by using a underlying thin layer provided by COREMU. I think this approach is much clean than trying to parallelize QEMU itself. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667
Re: [Qemu-devel] Multi heterogenous CPU archs for SoC sim?
Am 21.10.2011 09:26, schrieb 陳韋任: COREMU treats QEMU as an entity and lauches multiple QEMUs at the same time. QEMUs communicates to each other by using a underlying thin layer provided by COREMU. I think this approach is much clean than trying to parallelize QEMU itself. In this case I disagree. Given shared global memory and peripherals in the SoC case, any IPC or shared-memory setup is destined to create performance or management overhead. When there's independent nodes connected via CAN/LIN/FlexRay, then I agree that multiple processes communicating via UNIX sockets make a lot of sense. My use case here is testing and debugging, so I think we could live with the blocks being executed in an interleaved fashion until someone has the ultimate parallelization solution for upstream. Regards, Andreas
Re: [Qemu-devel] Multi heterogenous CPU archs for SoC sim?
Am 21.10.2011 08:58, schrieb Peter Maydell: On 20 October 2011 23:51, Andreas Färber andreas.faer...@web.de wrote: Renesas announced the R-Car H1 this week, a SoC with one SH4A core and four ARM Cortex-A9 cores. Does it expose the SH4 to apps/OSes, or is it mostly used for power management or similar ignorable duties? The predecessors were all SuperH based only, and the ARM cores don't seem to have VFPv3 so the SH4A would feature a 128-bit FPU. As for what automative customers may do with it once available, I have no clue. My focus is on investigating where QEMU has architectural shortcomings or undocumented assumptions blocking embedded development and addressing these. (For several of the ARM boards we currently just ignore the fact that the real h/w has a Cortex-M3 doing power management type stuff.) Mind to share which boards? I'm only aware of the NXP LPC43xx asymmetric SoC (Cortex-M4 + Cortex-M0), which still is in development stage. The datasheet doesn't really enlighten me how such a combo is supposed to work in shared memory: Do all ARM cores share a reset vector (or what you call it on arm) so that one has to branch based on CPUID to do different tasks on different cores? Andreas
Re: [Qemu-devel] Multi heterogenous CPU archs for SoC sim?
Am 26.05.2011 um 21:11 schrieb Blue Swirl: 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. Gary never followed up on this, it seems. I have now come across such a heterogeneous SoC myself: Renesas announced the R-Car H1 this week, a SoC with one SH4A core and four ARM Cortex-A9 cores. That would make them all 32-bit, and I am hoping to get confirmation that this is consistently Little Endian. The only realistic way to get started with such setups I see is to create a new target-xxx for the specific mix, define TARGET_LONG_BITS etc. appropriately in a new cpu.h, compile the needed target-xyz/*.c to unique xxx-softmmu/xyz-*.o and dispatch from a cpu_init() to the two cpu_*_init(). I'm guessing we may need to distinguish the TBs at runtime? Reserving log2(#architectures) bits in the TBFLAGS might do, but feels ugly. Probably a lot of other issues I'm not seeing yet. Comments? Andreas
Re: [Qemu-devel] Multi heterogenous CPU archs for SoC sim?
Blue Swirl writes: On Thu, May 26, 2011 at 11:07 PM, Lluís xscr...@gmx.net wrote: 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. Well, C++ templates would help clean the current define and macro-based code generation labyrinth without switching the whole QEMU codebase into an OO design, but I suppose this was also part of the duscussion. Thanks, Lluis -- And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer. -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth
Re: [Qemu-devel] Multi heterogenous CPU archs for SoC sim?
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.
Re: [Qemu-devel] Multi heterogenous CPU archs for SoC sim?
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? Lluis -- And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer. -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth
Re: [Qemu-devel] Multi heterogenous CPU archs for SoC sim?
Am 25.05.2011 um 20:44 schrieb Greg McGary: 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. In theory, many things are possible. In practice, it's a matter of manhours you're willing to invest. Without further details on your SoC it's hard to provide a useful answer. An SoC with mixed ARM Cortex-M4 and Cortex-M0, for instance, may be much easier to accomplish than mixing architectures with differing endianness and especially bitness. That will likely involve compiling for ceil(bitness) - since I don't see how linking hw/*.o compiled for diffent bit-widths would work - and making sure any lower-bitness architectures continue to work, while probably dropping in overall performance... Andreas
Re: [Qemu-devel] Multi heterogenous CPU archs for SoC sim?
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.
[Qemu-devel] Multi heterogenous CPU archs for SoC sim?
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. Has anyone has thought much about this, and/or have advice? FYI, I am reasonably experienced with QEMU--I ported it to a new proprietary generic-RISC architecture last year and have it running in linux-user mode and in system mode running a newly-ported linux kernel. G
Re: [Qemu-devel] Multi heterogenous CPU archs for SoC sim?
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. -- PMM
