Re: [Qemu-devel] Status of the SH4 / ARM7 emulators

[Peter Maydell]

On 20 November 2011 20:51, Andreas Färber <address@hidden> 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