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.
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|