[libvirt] [PATCH 4/4] qemu: default to kvm32/kvm64 when KVM is enabled

Paolo Bonzini pbonzini at redhat.com
Mon Jan 23 17:06:43 UTC 2012


On 01/23/2012 05:30 PM, Daniel P. Berrange wrote:
> On Mon, Jan 23, 2012 at 05:23:32PM +0100, Paolo Bonzini wrote:
>> On 01/23/2012 05:03 PM, Daniel P. Berrange wrote:
>>>>>>   >   The qemu32/qemu64 models are weird in that the exact combination of
>>>>>>   >   CPUID flags does not match any actual processor.  kvm32 and kvm64 are
>>>>>>   >   a better match when not using TCG.  Use them when -cpu is only needed
>>>>>>   >   to hardcode a 32-bit guest arch or for kvmclock.
>>>>>
>>>>>   I don't think we can do this as it means the guest CPU may change unexpectedly
>>>>>   for existing domains. A 32b domain started on current libvirt would see qemu32,
>>>>>   while the same domain started after this patch would see kvm32.
>>> Also, IIUC,  kvm32 is a fairly newly introduced CPU type for KVM - ie most
>>> deployments of KVM won't support it.
>>
>> Ok, I'll redo this patch with just kvm64.  As the wrong subject in
>> 0/3 show, it was an afterthought.
> 
> Is kvm64 actually any more widely supported than kvm32 ? I though they
> were all fairly new.
> 
> If I'm wrong, then we could trivially provide a kvm32, by using the
> kvm64 model, and subtracting the the "long mode" CPU flag.

commit d1cd4bf41906980434bee1c6656e8aeb9a132df3
Author: Andre Przywara <andre.przywara at amd.com>
Date:   Thu Aug 20 23:34:17 2009 +0200

    introduce kvm64 CPU
    
    In addition to the TCG based qemu64 type let's introduce a kvm64 CPU type,
    which is the least common denominator of all KVM-capable x86-CPUs
    (based on Intel Pentium 4 Prescott). It can be used as a base type
    for migration.
    
    Signed-off-by: Andre Przywara <andre.przywara at amd.com>
    Signed-off-by: Anthony Liguori <aliguori at us.ibm.com>

It is in RHEL6, but let's just scrap this patch until (at least) after 0.9.10.

Paolo




More information about the libvir-list mailing list