Am 08.02.2013 18:35, schrieb Peter Maydell: > On 8 February 2013 17:31, Andreas Färber <afaer...@suse.de> 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
