Re: [Qemu-devel] [RFC qom-cpu v2 03/28] target-arm: Update ARMCPU to QOM realizefn

[Andreas Färber]

Am 07.02.2013 19:56, schrieb Peter Maydell:
> On 7 February 2013 18:44, Andreas Färber <address@hidden> wrote:
>> Am 07.02.2013 17:31, schrieb Eduardo Habkost:
>>> My first question I had when I saw this was: are you really sure it is
>>> safe to call cpu_reset() and qemu_init_vcpu() before
>>> arm_translate_init()?
>>>
>>> But I see that you change this on commit 092028dbf1. So now I have the
>>> opposite question: are you really sure it is safe to call
>>> arm_translate_init() before arm_cpu_realizefn()?
>>
>> The answer to either is yes. TCG initialization functions themselves
>> (after this series latest) don't depend on CPU state and only calculate
>> static field offsets (in one or two cases depending on CPU versions that
>> I have inlined as part of the series). ARM's doesn't. If you spot any
>> remaining exception to that rule, please shout.
> 
> An idle thought: I wonder if we could rearrange things so that
> the target-specific TCG init is called via tcg_init(), to
> parallel the way that target-specific KVM init is called
> via kvm_init()? That would avoid the slight oddity that
> cpu_arm_init() &c have tcg_enabled()-specific code but not
> kvm_enabled()-specific or other accelerator-specific init.
> 
> I'm not sure it would be worth the effort to make that change,
> though.

I think that would be counter-productive. KVM is a host technology, it
depends on whether you're running the right target arch and whether it's
available/usable on your host. Since you're running on a single host,
there's only one KVM init to call.

The reason we made it conditional to tcg_enabled() is QTest, which
doesn't need it. Nor will KVM on ARM.

For TCG I'm hoping to enable multiple targets coexisting at some point,
so consolidating things into *CPUClass and instance_init seems better.
There's no ugly #ifdef'ery involved for TCG.

I am still thinking about how to restructure TCG code - for one whether
I can make TCG helpers optionally use CPUState at some point and for
another how to consolidate the various global variables. We'd need only
one cpu_env, I think - might go into CPUClass or as global into
qom/cpu.c then.

Cheers,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg