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

[Andreas Färber]

Am 08.02.2013 18:35, schrieb Peter Maydell:
> On 8 February 2013 17:31, Andreas Färber <address@hidden> wrote:
>> Am 07.02.2013 19:56, schrieb Peter Maydell:
>>> 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()?
> 
>> 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.
> 
> That would suggest that some of the KVM init should also go
> via the CPU object; consider a system with one KVM-accelerated
> core and one TCG core of a different architecture.

Yes, I had considered such a mixed scenario but pushed it aside for now
because most kvm_enabled() and tcg_enabled() checks would need to get
refactored then, which would be quite invasive for a not yet supported
and hard to verify constellation.

If someone with a use case wanted to send patches I would certainly help
with review. ;-)

For the current x86 subclasses discussion this thought would mean that
we should try to keep KVM/no-KVM decisions to object instances.

Andreas

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