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