Am 07.02.2013 19:56, schrieb Peter Maydell: > On 7 February 2013 18:44, Andreas Färber <[email protected]> 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
