On Thu, Mar 16, 2017 at 12:52:32PM -0400, Gabriel L. Somlo wrote: > On Thu, Mar 16, 2017 at 06:45:02PM +0200, Michael S. Tsirkin wrote: > > On Thu, Mar 16, 2017 at 12:16:13PM -0400, Gabriel L. Somlo wrote: > > > On Thu, Mar 16, 2017 at 04:35:18PM +0100, Radim Krčmář wrote: > > > > 2017-03-16 10:58-0400, Gabriel L. Somlo: > > > > > On Thu, Mar 16, 2017 at 04:04:12PM +0200, Michael S. Tsirkin wrote: > > > > > > On Thu, Mar 16, 2017 at 09:24:27AM -0400, Gabriel L. Somlo wrote: > > > > > > > After studying your patch a bit more carefully (sorry, it's crazy > > > > > > > around here right now :) ) I realized you're simply trying to > > > > > > > (selectively) decide when to exit L1 and emulate as NOP vs. when > > > > > > > to > > > > > > > just allow L1 to execute MONITOR & MWAIT natively. > > > > > > > > > > > > > > Is that right ? Because if so, the issues I saw on my MacPro1,1 > > > > > > > are > > > > > > > weird and inexplicable, given that allowing L>=1 to run > > > > > > > MONITOR/MWAIT > > > > > > > natively was one of the options Alex Graf and Rene Rebe used back > > > > > > > in > > > > > > > the very early days of OS X on QEMU, at the time I got involved > > > > > > > with > > > > > > > that project. Here's part of an out of tree patch against 3.4 > > > > > > > which did > > > > > > > just that, and worked as far as I remember on *any* MWAIT capable > > > > > > > intel chip I had access to back in 2010: > > > > > > > > > > > > > > ############################################################################## > > > > > > > # 99-mwait.patch.kvm-kmod (Rene Rebe <r...@exactcode.de>) > > > > > > > 2010-04-27 > > > > > > > ############################################################################## > > > > > > > diff -pNarU5 linux-3.4/arch/x86/kvm/cpuid.c > > > > > > > linux-3.4-mac/arch/x86/kvm/cpuid.c > > > > > > > --- linux-3.4/arch/x86/kvm/cpuid.c 2012-05-20 > > > > > > > 18:29:13.000000000 -0400 > > > > > > > +++ linux-3.4-mac/arch/x86/kvm/cpuid.c 2012-10-09 > > > > > > > 11:42:59.921215750 -0400 > > > > > > > @@ -222,11 +222,11 @@ static int do_cpuid_ent(struct kvm_cpuid > > > > > > > f_nx | 0 /* Reserved */ | F(MMXEXT) | F(MMX) | > > > > > > > F(FXSR) | F(FXSR_OPT) | f_gbpages | f_rdtscp | > > > > > > > 0 /* Reserved */ | f_lm | F(3DNOWEXT) | F(3DNOW); > > > > > > > /* cpuid 1.ecx */ > > > > > > > const u32 kvm_supported_word4_x86_features = > > > > > > > - F(XMM3) | F(PCLMULQDQ) | 0 /* DTES64, MONITOR */ | > > > > > > > + F(XMM3) | F(PCLMULQDQ) | F(MWAIT) /* DTES64, MONITOR */ > > > > > > > | > > > > > > > 0 /* DS-CPL, VMX, SMX, EST */ | > > > > > > > 0 /* TM2 */ | F(SSSE3) | 0 /* CNXT-ID */ | 0 /* > > > > > > > Reserved */ | > > > > > > > F(FMA) | F(CX16) | 0 /* xTPR Update, PDCM */ | > > > > > > > 0 /* Reserved, DCA */ | F(XMM4_1) | > > > > > > > F(XMM4_2) | F(X2APIC) | F(MOVBE) | F(POPCNT) | > > > > > > > diff -pNarU5 linux-3.4/arch/x86/kvm/svm.c > > > > > > > linux-3.4-mac/arch/x86/kvm/svm.c > > > > > > > --- linux-3.4/arch/x86/kvm/svm.c 2012-05-20 18:29:13.000000000 > > > > > > > -0400 > > > > > > > +++ linux-3.4-mac/arch/x86/kvm/svm.c 2012-10-09 > > > > > > > 11:44:41.598997481 -0400 > > > > > > > @@ -1102,12 +1102,10 @@ static void init_vmcb(struct vcpu_svm *s > > > > > > > set_intercept(svm, INTERCEPT_VMSAVE); > > > > > > > set_intercept(svm, INTERCEPT_STGI); > > > > > > > set_intercept(svm, INTERCEPT_CLGI); > > > > > > > set_intercept(svm, INTERCEPT_SKINIT); > > > > > > > set_intercept(svm, INTERCEPT_WBINVD); > > > > > > > - set_intercept(svm, INTERCEPT_MONITOR); > > > > > > > - set_intercept(svm, INTERCEPT_MWAIT); > > > > > > > set_intercept(svm, INTERCEPT_XSETBV); > > > > > > > > > > > > > > control->iopm_base_pa = iopm_base; > > > > > > > control->msrpm_base_pa = __pa(svm->msrpm); > > > > > > > control->int_ctl = V_INTR_MASKING_MASK; > > > > > > > diff -pNarU5 linux-3.4/arch/x86/kvm/vmx.c > > > > > > > linux-3.4-mac/arch/x86/kvm/vmx.c > > > > > > > --- linux-3.4/arch/x86/kvm/vmx.c 2012-05-20 18:29:13.000000000 > > > > > > > -0400 > > > > > > > +++ linux-3.4-mac/arch/x86/kvm/vmx.c 2012-10-09 > > > > > > > 11:42:59.925215977 -0400 > > > > > > > @@ -1938,11 +1938,11 @@ static __init void nested_vmx_setup_ctls > > > > > > > nested_vmx_procbased_ctls_low, > > > > > > > nested_vmx_procbased_ctls_high); > > > > > > > nested_vmx_procbased_ctls_low = 0; > > > > > > > nested_vmx_procbased_ctls_high &= > > > > > > > CPU_BASED_VIRTUAL_INTR_PENDING | > > > > > > > CPU_BASED_USE_TSC_OFFSETING | > > > > > > > CPU_BASED_HLT_EXITING | CPU_BASED_INVLPG_EXITING | > > > > > > > - CPU_BASED_MWAIT_EXITING | CPU_BASED_CR3_LOAD_EXITING | > > > > > > > + CPU_BASED_CR3_LOAD_EXITING | > > > > > > > CPU_BASED_CR3_STORE_EXITING | > > > > > > > #ifdef CONFIG_X86_64 > > > > > > > CPU_BASED_CR8_LOAD_EXITING | > > > > > > > CPU_BASED_CR8_STORE_EXITING | > > > > > > > #endif > > > > > > > CPU_BASED_MOV_DR_EXITING | CPU_BASED_UNCOND_IO_EXITING | > > > > > > > @@ -2404,12 +2404,10 @@ static __init int setup_vmcs_config(stru > > > > > > > CPU_BASED_CR3_LOAD_EXITING | > > > > > > > CPU_BASED_CR3_STORE_EXITING | > > > > > > > CPU_BASED_USE_IO_BITMAPS | > > > > > > > CPU_BASED_MOV_DR_EXITING | > > > > > > > CPU_BASED_USE_TSC_OFFSETING | > > > > > > > - CPU_BASED_MWAIT_EXITING | > > > > > > > - CPU_BASED_MONITOR_EXITING | > > > > > > > CPU_BASED_INVLPG_EXITING | > > > > > > > CPU_BASED_RDPMC_EXITING; > > > > > > > > > > > > > > opt = CPU_BASED_TPR_SHADOW | > > > > > > > CPU_BASED_USE_MSR_BITMAPS | > > > > > > > > > > > > > > If all you're trying to do is (selectively) revert to this > > > > > > > behavior, > > > > > > > that "shouldn't" mess it up for the MacPro either, so I'm > > > > > > > thoroughly > > > > > > > confused at this point :) > > > > > > > > > > > > Yes. Me too. Want to try that other patch and see what happens? > > > > > > > > > > You mean the old 3.4 patch against current KVM ? I'll try to do that, > > > > > might take me a while :) > > > > > > > > Michael's patch already did most of that, you just need to add > > > > > > > > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c > > > > index efde6cc50875..b12f07d4ce17 100644 > > > > --- a/arch/x86/kvm/cpuid.c > > > > +++ b/arch/x86/kvm/cpuid.c > > > > @@ -348,7 +348,7 @@ static inline int __do_cpuid_ent(struct > > > > kvm_cpuid_entry2 *entry, u32 function, > > > > const u32 kvm_cpuid_1_ecx_x86_features = > > > > /* NOTE: MONITOR (and MWAIT) are emulated as NOP, > > > > * but *not* advertised to guests via CPUID ! */ > > > > - F(XMM3) | F(PCLMULQDQ) | 0 /* DTES64, MONITOR */ | > > > > + F(XMM3) | F(PCLMULQDQ) | F(MWAIT) /* DTES64, MONITOR */ > > > > | > > > > 0 /* DS-CPL, VMX, SMX, EST */ | > > > > 0 /* TM2 */ | F(SSSE3) | 0 /* CNXT-ID */ | 0 /* > > > > Reserved */ | > > > > F(FMA) | F(CX16) | 0 /* xTPR Update, PDCM */ | > > > > > > > > Note: this will never be upstream, because mwait isn't what we want by > > > > default. :) > > > > > > But since OS X doesn't check CPUID and simply runs MONITOR & MWAIT > > > assuming they're present, the above one-liner would make no > > > difference. If everything else in the old patch I quoted is identical > > > to what Michael does, then I don't know -- maybe the MacPro1,1 has > > > really broken L>=1 MWAIT, and it only ever worked with vmexit and > > > emulation on the host side. > > > > > > I think I have an idea. It is probably one of the monitor bugs > > on this host. > > > > X86_BUG_CLFLUSH_MONITOR or X86_BUG_MONITOR. > > > > If you tell guest you have a CPU that does not need it > > but host does need it, then mwait will not work. > > > > if (c->x86 == 6 && boot_cpu_has(X86_FEATURE_CLFLUSH) && > > (c->x86_model == 29 || c->x86_model == 46 || c->x86_model == > > 47)) > > set_cpu_bug(c, X86_BUG_CLFLUSH_MONITOR); > > > > > > if (c->x86 == 6 && boot_cpu_has(X86_FEATURE_MWAIT) && > > ((c->x86_model == INTEL_FAM6_ATOM_GOLDMONT))) > > set_cpu_bug(c, X86_BUG_MONITOR); > > > > what did you say your host model is? > > # dmidecode -t1 > # dmidecode 2.12 > SMBIOS 2.4 present. > > Handle 0x0021, DMI type 1, 27 bytes > System Information > Manufacturer: Apple Computer, Inc. > Product Name: MacPro1,1 > Version: 1.0 > Serial Number: G87030UEUPZ > UUID: 9CFE245E-D0C8-BD45-A79F-54EA5FBD3D97 > Wake-up Type: Power Switch > SKU Number: System SKU# > Family: MacPro
And, probably more usefully: [... ommitting 0,1,2 ...] processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU 5150 @ 2.66GHz stepping : 6 microcode : 0xd2 cpu MHz : 2659.998 cache size : 4096 KB physical id : 3 siblings : 2 core id : 0 cpu cores : 2 apicid : 6 initial apicid : 6 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca lahf_lm tpr_shadow dtherm bugs : bogomips : 5320.05 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:
