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

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

[Andre Przywara]

[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

Re: [Qemu-devel] KVMs default CPU type

[Avi Kivity]

On 06/25/2009 11:11 AM, Andre Przywara wrote:
> 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.

-cpu host may have issues other than migration; for example if you 
upgrade your host processor guests will notice and perhaps trigger a 
revalidation.  It also means every host offers something slightly 
different to guests, increasing the test matrix.

-- 
error compiling committee.c: too many arguments to function

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

[Andrea Arcangeli]

Hi everyone,

On Thu, Jun 25, 2009 at 10:11:58AM +0200, Andre Przywara wrote:
> 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.

I don't mind which vendor_id is used in the default common denominator
as long as we don't create a not-existing-hardware-vendor-id which
doesn't make much sense to me and it looks like gratuitous
complication for guest OS ;). The model string as qemu may be kind of
eye-candy in /proc/cpuinfo and it didn't break stuff yet, but that's
about 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).

This afternooon I was trying to test the 6/3/3 with amd vendor id with
32bit linux and 32bit windows on my laptop with qemu (my SVM test
system is down and it's troublesome to fix it now but I'll fix it
tomorrow), but I noticed that qemu seems to ignore that so I don't
think my testing of 6/3/3 with SEP feature enabled (sep is enabled
with qemu because of inheriting from PPRO even on -cpu athlon) was
reliable:

    case 0x134: /* sysenter */
        /* For Intel SYSENTER is valid on 64-bit */
        if (CODE64(s) && cpu_single_env->cpuid_vendor1 != CPUID_VENDOR_INTEL_1)
            goto illegal_op;
        if (!s->pe) {
            gen_exception(s, EXCP0D_GPF, pc_start - s->cs_base);
        } else {
            if (s->cc_op != CC_OP_DYNAMIC) {
                gen_op_set_cc_op(s->cc_op);
                s->cc_op = CC_OP_DYNAMIC;
            }
            gen_jmp_im(pc_start - s->cs_base);
            gen_helper_sysenter();
            gen_eob(s);
        }
        break;

qemu apparently allows sysenter without segfaults always on code32,
even if -cpu athlon is set and syscall feature disabled in cpuid, so
the fact sep is enabled on -cpu athlon probably won't trigger
breakages for qemu and it can be unnoticed (even if it fails to
emulate real athlon hardware) but I'm now worried it may break KVM as
I couldn't test it yet. This is the stuff I'd like to discuss...

> 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)

I have to test 6/3/3 vendor_id = AMD with KVM ASAP...

Also if we want to really emulate real hardware in qemu we'd need to
allow syscall/sysret not just on the x86-64 target and set
CPUID_EXT2_SYSCALL and clear SEP again on athlon, no?

> 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...

Maybe it makes sense to use -cpu host, but that could have other
implications, also if it makes sense for qemu to have a model name
reflecting qemu cpu, I think we should be consistent and have a common
denominator with a qemu model name even for kvm, but on kvm we must
get certain bitflags right, and on intel move away from that 6/2/3
that purely asks for troubles I think. At the same time I doubt we
want to deviate much from qemu code here, this seems messy enough
already without big changes to maintain in this area, and I guess this
explains why kvm is only flipping the vendor_id right now...

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

[Andrea Arcangeli]

On Fri, Jun 26, 2009 at 02:42:17AM +0200, Andrea Arcangeli wrote:
> that purely asks for troubles I think. At the same time I doubt we
> want to deviate much from qemu code here, this seems messy enough
> already without big changes to maintain in this area, and I guess this
> explains why kvm is only flipping the vendor_id right now...

Basically it seems athlon and other cpu definitions are tuned for cpus
having vmx/svm and running in legacy mode, that always support sep in
legacy mode and always supports syscall in long mode, so while qemu
seem to be cheating and not really emulating real hardware, those are
good tradeoffs definitions for KVM and it explains why it's enough to
flip the vendor_id to match the host vendor_id to get compatibility
mode right on 64bit guests, but only as long as 6/3/3 is set (hence
the reason of the patch).

So in short, we can't make any further change in KVM in addition to
waiting the common denominator to move to 6/3/3. First qemu has to
decide if it goes ahead not emulating real 32bit athlon but by
providing feature flags definition of a svm/vmx cpu in legacy mode.