[Qemu-devel] KVMs default CPU type (was: allow sysenter on 32bit guests running on vmx host)

[Andre Przywara <andre.przywara@amd.com>]

[CCing kvm@vger]
Jamie Lokier wrote:
> Andrea Arcangeli wrote:
>> Hi Jamie,
 >...
> 
> It looks like it could be a KVM mis-feature.
> 
> Is the changing vendor id actually useful for anything, without
> updating the family/model/stepping at the same time?  E.g. does it
> make some guest things work, even though other parts of the cpuid
> don't reflect the host?
(sysenter/sysexit in 32bit compat mode, see below)
> 
>> Another approach is to switch model to 3 along with vendor_id in KVM
>> but because qemu is already using 6/3/3 when emulating a 32bit x86
>> hardware, I don't think this is simpler and more consistent.
> 
> No, I'm happy with 6/3/3.  Like that part of the patch :-)
> 
> Although... there aren't any 64-bit Pentium Pros, so maybe 6/3/3 is a
> bit... small? :-)
There aren't any K7 Athlons with 64bit, either ;-)
I think this whole family 6 thing comes actually from QEMU and it's 
emulation capabilities and makes no sense in KVM.

I think we should go away from using qemu64 as a default for KVM. In my 
opinion we should target -cpu host as KVM's default, while in parallel 
create a -cpu migrate type (still fiddling with the CPUID details of 
that), which takes over the qemu64 role of being some kind of least 
common denominator. This should be a family 15 CPU (AMD K8 or Intel P4) 
with a constant vendor ID (in my experiments Intel showed less problems 
with guests). Since 64bit Windows has a whitelist of known vendor IDs 
(AMD, Intel on XP, additionally Via on Win7) we cannot use a bogus 
vendor, although this should impose the least problems.

> Now I'm just wondering why the vendor id needs to change dynamically,
> if the other cpuid fields aren't changed.  If that's useful, then at
> least a comment around the qemu64 CPU type to say that happens would
> be good.  If that's not really a useful feature, then better not to do
> it.
The dynamic vendor change was introduced to avoid compatibility problems 
with 32-on-64 compat mode, wherein AMD does not support sysenter 
(although it does in legacy mode) and Intel does not support syscall 
(although it does in 64bit mode). See the comment around line 1500 in 
target-i386/helper.c (or search for vendor_override in current git).
Linux's decision whether to use syscall or sysenter depends on the 
vendor string, so it uses syscall on AMD even when sysenter is advertised.
With the sysenter/syscall emulation patches I sent lately and the -cpu 
host type I think this dynamic vendor ID kludge can go away, since it 
creates problem with cross-vendor migration (where the vendor ID changes 
during the guest's runtime)

> Maybe it's not useful any more, as "-cpu host" can be used instead (a
> recent patch).  That had better not break Skype :-)
> 
> For Windows guests, which are sensitive to CPU changes, I prefer not
> to change CPU type dynamically without the user knowing.  Even with
> "-cpu host", I hope (eventually) the chosen CPU type will be stored
> when saving/migrating and loaded exactly the same on other hosts, when
> it's technically possible.
You do not want to use -cpu host if you plan to migrate, another safer 
CPU type should be used then (the aforementioned -cpu migrate).
Although preserving the boot CPU's vendor/family/model/stepping is 
something that one can think about...


Regards,
Andre.

-- 
Andre Przywara
AMD-OSRC (Dresden)
Tel: x29712