[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Multi heterogenous CPU archs for SoC sim?
From: |
Lluís Vilanova |
Subject: |
Re: [Qemu-devel] Multi heterogenous CPU archs for SoC sim? |
Date: |
Fri, 21 Oct 2011 17:41:07 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) |
Peter Maydell writes:
>> 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.
Yup, this sounds like pointer tables. That's one of the main reasons I advocated
C++. Another reason is improving code maintainability through templates (without
impacting performance).
>> 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.
Well, AFAIU if targets have different ISAs, the same physical tb will never be
used by differing targets (ignoring the case of different targets but same ISA).
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