On 20 November 2011 20:51, Andreas Färber <andreas.faer...@web.de> wrote: > Am 19.11.2011 22:53, schrieb Peter Maydell: >> We also don't support having multiple CPUs with different architectures > Although I have recently been investigating exactly that combo.
Yes, it would be nice to be able to do it cleanly... > * Part of the problem is that common CPUState fields are not at the > start of the struct. I have therefore been playing with a > CPU_COMMON_PREFIX at the start of the struct and using a macro for > clearing on reset, which preserves part of the common prefix fields. I've never much liked the way we clear the common fields in CPUState anyway -- having every target-foo know that the first not-to-be-cleared field in CPU_COMMON is called "breakpoints" is pretty ugly... > * Given a CPUState*, we need a way to differentiate different CPU types. > I used an enum CPUType cpu_type as first field in CPU_COMMON_PREFIX. > * cpu_mmu_index() is static inline, we should #define it to a non-static > function in helper.c. > * How to get declarations for such target-specific functions when > #include "target-xyz/cpu.h" would overwrite cpu_init, TARGET_PAGE_SIZE > and other defines? > > I hope this'll get easier with QOM. It seems to me that ideally a CPU should be just another device except with an extended interface that implements "this is a device which can run code and has to be scheduled". Ideally the common code shouldn't need to know what CPU type a schedulable object actually is. (I wonder if you could have a "some CPUs are KVM and some are TCG" config...?) (How we get there from here is a different question, of course; QOM ought to let you define an appropriate interface for the "provide the hooks for being a schedulable object" if we've got the QOM design right, though.) -- PMM
