[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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
