Re: [Qemu-devel] [PATCH v2 0/3] i386: Add "max" CPU model to TCG and KVM

[David Hildenbrand]

Am 24.02.2017 um 14:48 schrieb Peter Maydell:
> On 22 February 2017 at 18:39, Eduardo Habkost <address@hidden> wrote:
>> Changes v1 -> v2:
>> * Fix build without CONFIG_KVM at lmce_supported()
>> * Rebased on top of my x86-next branch:
>>   https://github.com/ehabkost/qemu x86-next
>>
>> Git branch for testing:
>>   https://github.com/ehabkost/qemu-hacks work/x86-cpu-max-tcg
>>
>> libvirt code to use the new feature already exist, and were
>> submitted to libvir-list, at:
>>   https://www.mail-archive.com/address@hidden/msg142168.html
>>
>> ---
>>
>> This is a replacement for the previous series that enabled the
>> "host" CPU model on TCG. Now a new "max" CPU is being added,
>> while keeping "host" KVM-specific.
>>
>> In addition to simply adding "max" as a copy of the existing
>> "host" CPU model, additional patches change it to not use any
>> host CPUID information when in TCG mode.
> 
> 
> I had a look at implementing this for ARM, and ran into problems
> because of how we've done '-cpu host'. For us the "host" CPU
> type is registered dynamically when kvm_init() is called,
> because (a) it only exists if -enable-kvm and (b) it probes
> the kernel to find out what's available. So I could easily
> add 'max' in the same place; but then where should I add the
> type definition of 'max' for the non-KVM case?
> 
> Any suggestions?

Maybe switch to some late initialization?

On s390x, we register the host model right away, but fill it with life
in the initfn. If KVM is disabled, the host model will be available, but
we will deny to use it (via kvm_required).

For max, it would be the same thing. The initfn will simply inititalize
the model differently, depending on the selected accelerator.

When the models are inititalized, kvm is already up and running, so it
the kernel can be properly probed.

Not sure if that helps :)

-- 
Thanks,

David