* [PATCH] KVM: add KVM_CAP_VMX_APICV to advertise hardware apic-v support @ 2014-12-11 8:07 zhanghailiang 2014-12-11 11:48 ` Paolo Bonzini 2014-12-11 13:08 ` Radim Krčmář 0 siblings, 2 replies; 11+ messages in thread From: zhanghailiang @ 2014-12-11 8:07 UTC (permalink / raw) To: kvm; +Cc: gleb, pbonzini, peter.huangpeng, zhanghailiang User space (i.e. QEMU) should be able to check whether KVM supports apic-v. User space will use this to decide whether enable emulated MSR-based APIC (i.e. hyperv-vapic). Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com> --- arch/x86/kvm/x86.c | 6 ++++++ include/uapi/linux/kvm.h | 1 + 2 files changed, 7 insertions(+) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 0033df3..aad4437 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -2775,6 +2775,12 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) case KVM_CAP_TSC_DEADLINE_TIMER: r = boot_cpu_has(X86_FEATURE_TSC_DEADLINE_TIMER); break; + case KVM_CAP_VMX_APICV: + if (kvm) + r = kvm_apic_vid_enabled(kvm); + else + r = 0; + break; default: r = 0; break; diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h index 6076882..1a55d1a 100644 --- a/include/uapi/linux/kvm.h +++ b/include/uapi/linux/kvm.h @@ -761,6 +761,7 @@ struct kvm_ppc_smmu_info { #define KVM_CAP_PPC_FIXUP_HCALL 103 #define KVM_CAP_PPC_ENABLE_HCALL 104 #define KVM_CAP_CHECK_EXTENSION_VM 105 +#define KVM_CAP_VMX_APICV 106 #ifdef KVM_CAP_IRQ_ROUTING -- 1.8.3.4 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH] KVM: add KVM_CAP_VMX_APICV to advertise hardware apic-v support 2014-12-11 8:07 [PATCH] KVM: add KVM_CAP_VMX_APICV to advertise hardware apic-v support zhanghailiang @ 2014-12-11 11:48 ` Paolo Bonzini 2014-12-11 12:53 ` zhanghailiang 2014-12-11 13:08 ` Radim Krčmář 1 sibling, 1 reply; 11+ messages in thread From: Paolo Bonzini @ 2014-12-11 11:48 UTC (permalink / raw) To: zhanghailiang, kvm; +Cc: gleb, peter.huangpeng On 11/12/2014 09:07, zhanghailiang wrote: > User space (i.e. QEMU) should be able to check whether KVM > supports apic-v. User space will use this to decide whether enable > emulated MSR-based APIC (i.e. hyperv-vapic). Did you see an improvement in some workload? I think it's a Windows bug---it should prefer x2apic to hv-vapic if both are available. Paolo ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] KVM: add KVM_CAP_VMX_APICV to advertise hardware apic-v support 2014-12-11 11:48 ` Paolo Bonzini @ 2014-12-11 12:53 ` zhanghailiang 2014-12-11 13:28 ` Radim Krčmář 2014-12-11 17:15 ` Paolo Bonzini 0 siblings, 2 replies; 11+ messages in thread From: zhanghailiang @ 2014-12-11 12:53 UTC (permalink / raw) To: Paolo Bonzini, kvm; +Cc: gleb, peter.huangpeng On 2014/12/11 19:48, Paolo Bonzini wrote: > > > On 11/12/2014 09:07, zhanghailiang wrote: >> User space (i.e. QEMU) should be able to check whether KVM >> supports apic-v. User space will use this to decide whether enable >> emulated MSR-based APIC (i.e. hyperv-vapic). > > Did you see an improvement in some workload? > Yes, compared with using hyperv-vapic, using apic-v reduces lots of VM exit. The bellow is the qemu command and perf data: qemu/x86_64-softmmu/qemu-system-x86_64 -name win2008_st_r2_64_2U -S -machine pc-i440fx-2.2,accel=kvm,usb=off -cpu Haswell,+abm,+pdpe1gb,+rdrand,+f16c,+osxsave,+dca,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme,hv_relaxed,hv_vapic,hv_spinlocks=0x1000 -m 4096 -realtime mlock=off -smp 6,maxcpus=12,sockets=1,cores=12,threads=1 -uuid e7fca4b5-10a2-4fa5-a71b-b5e9eaa41d4d -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/win2008_st_r2_64_2U.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/data/win2008_st_r2_64_2U.DataCenter.40G.base.virtio.02,if=none,id=drive-ide0-0-0,format=raw,cache=none, aio=native -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=! 52:54:00 :48:70:80,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 0.0.0.0:0 -device cirrus-vga,id=video0,vgamem_mb=8,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on (note: -cpu is Haswell, so x2apic is enable in default) (1) Using Hyperv-vapic UVP:/data # perf stat -e "kvm:*" -a sleep 10s Performance counter stats for 'sleep 10s': 1215390 kvm:kvm_entry [100.00%] 0 kvm:kvm_hypercall [100.00%] 0 kvm:kvm_hv_hypercall [100.00%] 8397 kvm:kvm_pio [100.00%] 0 kvm:kvm_cpuid [100.00%] 693288 kvm:kvm_apic [100.00%] 1228026 kvm:kvm_exit [100.00%] 0 kvm:kvm_inj_virq [100.00%] 3 kvm:kvm_inj_exception [100.00%] 39 kvm:kvm_page_fault [100.00%] 536450 kvm:kvm_msr [100.00%] 0 kvm:kvm_cr [100.00%] 1340 kvm:kvm_pic_set_irq [100.00%] 164441 kvm:kvm_apic_ipi [100.00%] 376239 kvm:kvm_apic_accept_irq [100.00%] 377100 kvm:kvm_eoi [100.00%] 0 kvm:kvm_pv_eoi [100.00%] 0 kvm:kvm_nested_vmrun [100.00%] 0 kvm:kvm_nested_intercepts [100.00%] 0 kvm:kvm_nested_vmexit [100.00%] 0 kvm:kvm_nested_vmexit_inject [100.00%] 0 kvm:kvm_nested_intr_vmexit [100.00%] 0 kvm:kvm_invlpga [100.00%] 0 kvm:kvm_skinit [100.00%] 528 kvm:kvm_emulate_insn [100.00%] 444 kvm:vcpu_match_mmio [100.00%] 0 kvm:kvm_write_tsc_offset [100.00%] 0 kvm:kvm_update_master_clock [100.00%] 0 kvm:kvm_track_tsc [100.00%] 630 kvm:kvm_userspace_exit [100.00%] 1394 kvm:kvm_set_irq [100.00%] 1396 kvm:kvm_ioapic_set_irq [100.00%] 212003 kvm:kvm_msi_set_irq [100.00%] 4092 kvm:kvm_ack_irq [100.00%] 901 kvm:kvm_mmio [100.00%] 710971 kvm:kvm_fpu [100.00%] 0 kvm:kvm_age_page [100.00%] 0 kvm:kvm_try_async_get_page [100.00%] 0 kvm:kvm_async_pf_doublefault [100.00%] 0 kvm:kvm_async_pf_not_present [100.00%] 0 kvm:kvm_async_pf_ready [100.00%] 0 kvm:kvm_async_pf_completed 10.000959015 seconds time elapsed (2) Using apic-v perf stat -e "kvm:*" -a sleep 10s Performance counter stats for 'sleep 10s': 888948 kvm:kvm_entry [100.00%] 0 kvm:kvm_hypercall [100.00%] 6 kvm:kvm_hv_hypercall [100.00%] 12510 kvm:kvm_pio [100.00%] 0 kvm:kvm_cpuid [100.00%] 324926 kvm:kvm_apic [100.00%] 898841 kvm:kvm_exit [100.00%] 0 kvm:kvm_inj_virq [100.00%] 0 kvm:kvm_inj_exception [100.00%] 259 kvm:kvm_page_fault [100.00%] 60 kvm:kvm_msr [100.00%] 0 kvm:kvm_cr [100.00%] 2046 kvm:kvm_pic_set_irq [100.00%] 164641 kvm:kvm_apic_ipi [100.00%] 371867 kvm:kvm_apic_accept_irq [100.00%] 665 kvm:kvm_eoi [100.00%] 0 kvm:kvm_pv_eoi [100.00%] 0 kvm:kvm_nested_vmrun [100.00%] 0 kvm:kvm_nested_intercepts [100.00%] 0 kvm:kvm_nested_vmexit [100.00%] 0 kvm:kvm_nested_vmexit_inject [100.00%] 0 kvm:kvm_nested_intr_vmexit [100.00%] 0 kvm:kvm_invlpga [100.00%] 0 kvm:kvm_skinit [100.00%] 1418 kvm:kvm_emulate_insn [100.00%] 465 kvm:vcpu_match_mmio [100.00%] 0 kvm:kvm_write_tsc_offset [100.00%] 0 kvm:kvm_update_master_clock [100.00%] 0 kvm:kvm_track_tsc [100.00%] 368303 kvm:kvm_ple_window [100.00%] 3948 kvm:kvm_userspace_exit [100.00%] 2088 kvm:kvm_set_irq [100.00%] 2090 kvm:kvm_ioapic_set_irq [100.00%] 0 kvm:kvm_ioapic_delayed_eoi_inj [100.00%] 208975 kvm:kvm_msi_set_irq [100.00%] 688 kvm:kvm_ack_irq [100.00%] 949 kvm:kvm_mmio [100.00%] 743624 kvm:kvm_fpu [100.00%] 0 kvm:kvm_age_page [100.00%] 0 kvm:kvm_try_async_get_page [100.00%] 0 kvm:kvm_async_pf_doublefault [100.00%] 0 kvm:kvm_async_pf_not_present [100.00%] 0 kvm:kvm_async_pf_ready [100.00%] 0 kvm:kvm_async_pf_completed 10.000829758 seconds time elapsed > I think it's a Windows bug---it should prefer x2apic to hv-vapic if both > are available. > No, i don't think it is a windows bug, it has nothing to do with x2apic, but apic-v (need hardware support, i.e. Haswell cpu). When we don't passthough host cpu model to Guest os, it has no idea about whether it supports apic-v in host, so the choose should be done by qemu. Actually, qemu has a option 'hv_vapic' for -cpu, we can choose not to configure it if we know there is apic-v support in host. But IMHO, we'd better to do it automatically. PS: This is the perf data when we configure x2apic but without configure hv-vapic and disable apic-v in kvm. It is the worst result, compared with the above two cases. UVP:/data # perf stat -e "kvm:*" -a sleep 10s Performance counter stats for 'sleep 10s': 1616665 kvm:kvm_entry [100.00%] 0 kvm:kvm_hypercall [100.00%] 0 kvm:kvm_hv_hypercall [100.00%] 8766 kvm:kvm_pio [100.00%] 0 kvm:kvm_cpuid [100.00%] 896485 kvm:kvm_apic [100.00%] 1634073 kvm:kvm_exit [100.00%] 363649 kvm:kvm_inj_virq [100.00%] 0 kvm:kvm_inj_exception [100.00%] 38 kvm:kvm_page_fault [100.00%] 0 kvm:kvm_msr [100.00%] 0 kvm:kvm_cr [100.00%] 1444 kvm:kvm_pic_set_irq [100.00%] 181544 kvm:kvm_apic_ipi [100.00%] 368012 kvm:kvm_apic_accept_irq [100.00%] 368745 kvm:kvm_eoi [100.00%] 0 kvm:kvm_pv_eoi [100.00%] 0 kvm:kvm_nested_vmrun [100.00%] 0 kvm:kvm_nested_intercepts [100.00%] 0 kvm:kvm_nested_vmexit [100.00%] 0 kvm:kvm_nested_vmexit_inject [100.00%] 0 kvm:kvm_nested_intr_vmexit [100.00%] 0 kvm:kvm_invlpga [100.00%] 0 kvm:kvm_skinit [100.00%] 556213 kvm:kvm_emulate_insn [100.00%] 463 kvm:vcpu_match_mmio [100.00%] 0 kvm:kvm_write_tsc_offset [100.00%] 0 kvm:kvm_update_master_clock [100.00%] 0 kvm:kvm_track_tsc [100.00%] 378556 kvm:kvm_ple_window [100.00%] 1125 kvm:kvm_userspace_exit [100.00%] 1490 kvm:kvm_set_irq [100.00%] 1492 kvm:kvm_ioapic_set_irq [100.00%] 0 kvm:kvm_ioapic_delayed_eoi_inj [100.00%] 187316 kvm:kvm_msi_set_irq [100.00%] 4137 kvm:kvm_ack_irq [100.00%] 568249 kvm:kvm_mmio [100.00%] 763264 kvm:kvm_fpu [100.00%] 0 kvm:kvm_age_page [100.00%] 0 kvm:kvm_try_async_get_page [100.00%] 0 kvm:kvm_async_pf_doublefault [100.00%] 0 kvm:kvm_async_pf_not_present [100.00%] 0 kvm:kvm_async_pf_ready [100.00%] 0 kvm:kvm_async_pf_completed 10.001000787 seconds time elapsed Thanks, zhanghailiang ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] KVM: add KVM_CAP_VMX_APICV to advertise hardware apic-v support 2014-12-11 12:53 ` zhanghailiang @ 2014-12-11 13:28 ` Radim Krčmář 2014-12-11 17:15 ` Paolo Bonzini 1 sibling, 0 replies; 11+ messages in thread From: Radim Krčmář @ 2014-12-11 13:28 UTC (permalink / raw) To: zhanghailiang; +Cc: Paolo Bonzini, kvm, gleb, peter.huangpeng 2014-12-11 20:53+0800, zhanghailiang: > On 2014/12/11 19:48, Paolo Bonzini wrote: > >On 11/12/2014 09:07, zhanghailiang wrote: > >>User space (i.e. QEMU) should be able to check whether KVM > >>supports apic-v. User space will use this to decide whether enable > >>emulated MSR-based APIC (i.e. hyperv-vapic). > > > >Did you see an improvement in some workload? > > > > Yes, compared with using hyperv-vapic, using apic-v reduces lots of VM exit. > > (1) Using Hyperv-vapic > 693288 kvm:kvm_apic [100.00%] > 1228026 kvm:kvm_exit [100.00%] > 536450 kvm:kvm_msr [100.00%] > 164441 kvm:kvm_apic_ipi [100.00%] > 377100 kvm:kvm_eoi [100.00%] > 901 kvm:kvm_mmio [100.00%] > (2) Using apic-v > 324926 kvm:kvm_apic [100.00%] > 898841 kvm:kvm_exit [100.00%] > 60 kvm:kvm_msr [100.00%] > 164641 kvm:kvm_apic_ipi [100.00%] > 665 kvm:kvm_eoi [100.00%] > 949 kvm:kvm_mmio [100.00%] > > >I think it's a Windows bug---it should prefer x2apic to hv-vapic if both > >are available. > > > > No, i don't think it is a windows bug, it has nothing to do with x2apic, but apic-v > (need hardware support, i.e. Haswell cpu). When we don't passthough host cpu model to Guest os, > it has no idea about whether it supports apic-v in host, so the choose should be done by qemu. Nice, thank you. > Actually, qemu has a option 'hv_vapic' for -cpu, we can choose not to configure it if we know > there is apic-v support in host. But IMHO, we'd better to do it automatically. hv-vapic has a legitimate use case with xapic without apic-v, so it makes sense to disable it there. (I'd dislike if QEMU disabled it without giving a control about it.) > PS: > This is the perf data when we configure x2apic but without configure hv-vapic and disable apic-v in kvm. > It is the worst result, compared with the above two cases. I'm not aware of any benefit of using the hyper-v MSR over x2apic MSR, so if Windows does that, I'd call it a bug too ... > 1616665 kvm:kvm_entry [100.00%] > 1634073 kvm:kvm_exit [100.00%] > 0 kvm:kvm_msr [100.00%] > 181544 kvm:kvm_apic_ipi [100.00%] > 368745 kvm:kvm_eoi [100.00%] > 568249 kvm:kvm_mmio [100.00%] and it's simple to see why, Windows doesn't do x2apic. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] KVM: add KVM_CAP_VMX_APICV to advertise hardware apic-v support 2014-12-11 12:53 ` zhanghailiang 2014-12-11 13:28 ` Radim Krčmář @ 2014-12-11 17:15 ` Paolo Bonzini 2014-12-17 22:17 ` Stefan Fritsch 1 sibling, 1 reply; 11+ messages in thread From: Paolo Bonzini @ 2014-12-11 17:15 UTC (permalink / raw) To: zhanghailiang, kvm; +Cc: gleb, peter.huangpeng On 11/12/2014 13:53, zhanghailiang wrote: > > >> I think it's a Windows bug---it should prefer x2apic to hv-vapic if both >> are available. >> > > No, i don't think it is a windows bug, it has nothing to do with x2apic, hv-vapic MSRs doesn't provide any performance improvement over x2apic MSRs. So Windows should use x2apic MSRs if both are available. Windows can use x2apic MSRs together with its EOI optimization, like Linux does. There definitely are Windows versions that know how to use x2apic (e.g. 2008R2). > but apic-v (need hardware support, i.e. Haswell cpu). APICv can use the x2apic MSRs. > When we don't passthough host cpu model to Guest os, > it has no idea about whether it supports apic-v in host, The presence of APICv should be totally transparent to the guest. > Actually, qemu has a option 'hv_vapic' for -cpu, we can choose not to > configure it if we know there is apic-v support in host. But IMHO, > we'd better to do it automatically. ... and cause the CPUID to change under the guest's feet if you migrate from a non-APICv to an APICv machines, or vice versa. Paolo ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] KVM: add KVM_CAP_VMX_APICV to advertise hardware apic-v support 2014-12-11 17:15 ` Paolo Bonzini @ 2014-12-17 22:17 ` Stefan Fritsch 2014-12-18 3:37 ` zhanghailiang 0 siblings, 1 reply; 11+ messages in thread From: Stefan Fritsch @ 2014-12-17 22:17 UTC (permalink / raw) To: Paolo Bonzini; +Cc: zhanghailiang, kvm, gleb, peter.huangpeng On Thursday 11 December 2014 18:15:39, Paolo Bonzini wrote: > On 11/12/2014 13:53, zhanghailiang wrote: > >> I think it's a Windows bug---it should prefer x2apic to hv-vapic > >> if both are available. > > > > No, i don't think it is a windows bug, it has nothing to do with > > x2apic, > hv-vapic MSRs doesn't provide any performance improvement over > x2apic MSRs. So Windows should use x2apic MSRs if both are > available. Windows can use x2apic MSRs together with its EOI > optimization, like Linux does. > > There definitely are Windows versions that know how to use x2apic > (e.g. 2008R2). > The Hyper-V specification (V3) has different bits for "supported" and "recommended". qemu always sets this bit (HV_X64_APIC_ACCESS_RECOMMENDED): Bit 3: Recommend using MSRs for accessing APIC registers EOI, ICR and TPR rather than their memory-mapped counterparts. But it does not seem to set this bit: Bit 8: Recommend using x2APIC MSRs. I guess that is why Windows does not use x2apic and qemu should always set this bit. But the HV_X64_APIC_ACCESS_RECOMMENDED bit should probably not be set if the host supports apic-v. I havn't done any testing, though. > > but apic-v (need hardware support, i.e. Haswell cpu). > > APICv can use the x2apic MSRs. > > > When we don't passthough host cpu model to Guest os, > > it has no idea about whether it supports apic-v in host, > > The presence of APICv should be totally transparent to the guest. > > > Actually, qemu has a option 'hv_vapic' for -cpu, we can choose not > > to configure it if we know there is apic-v support in host. But > > IMHO, we'd better to do it automatically. > > ... and cause the CPUID to change under the guest's feet if you > migrate from a non-APICv to an APICv machines, or vice versa. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] KVM: add KVM_CAP_VMX_APICV to advertise hardware apic-v support 2014-12-17 22:17 ` Stefan Fritsch @ 2014-12-18 3:37 ` zhanghailiang 2014-12-18 8:30 ` Paolo Bonzini 0 siblings, 1 reply; 11+ messages in thread From: zhanghailiang @ 2014-12-18 3:37 UTC (permalink / raw) To: Stefan Fritsch, Paolo Bonzini; +Cc: hangaohuai, kvm, gleb, peter.huangpeng On 2014/12/18 6:17, Stefan Fritsch wrote: > On Thursday 11 December 2014 18:15:39, Paolo Bonzini wrote: >> On 11/12/2014 13:53, zhanghailiang wrote: >>>> I think it's a Windows bug---it should prefer x2apic to hv-vapic >>>> if both are available. >>> >>> No, i don't think it is a windows bug, it has nothing to do with >>> x2apic, >> hv-vapic MSRs doesn't provide any performance improvement over >> x2apic MSRs. So Windows should use x2apic MSRs if both are >> available. Windows can use x2apic MSRs together with its EOI >> optimization, like Linux does. >> >> There definitely are Windows versions that know how to use x2apic >> (e.g. 2008R2). >> > > The Hyper-V specification (V3) has different bits for "supported" and > "recommended". > > qemu always sets this bit (HV_X64_APIC_ACCESS_RECOMMENDED): > > Bit 3: Recommend using MSRs for accessing APIC registers > EOI, ICR and TPR rather than their memory-mapped > counterparts. > > But it does not seem to set this bit: > > Bit 8: Recommend using x2APIC MSRs. > > I guess that is why Windows does not use x2apic and qemu should always I have test it when set bit 8, it seems that it is useless. The result is no difference, compared with not setting this bit. > set this bit. But the HV_X64_APIC_ACCESS_RECOMMENDED bit should > probably not be set if the host supports apic-v. I havn't done any That is what this patch want to do ;) > testing, though. > >>> but apic-v (need hardware support, i.e. Haswell cpu). >> >> APICv can use the x2apic MSRs. >> >>> When we don't passthough host cpu model to Guest os, >>> it has no idea about whether it supports apic-v in host, >> >> The presence of APICv should be totally transparent to the guest. >> >>> Actually, qemu has a option 'hv_vapic' for -cpu, we can choose not >>> to configure it if we know there is apic-v support in host. But >>> IMHO, we'd better to do it automatically. >> >> ... and cause the CPUID to change under the guest's feet if you >> migrate from a non-APICv to an APICv machines, or vice versa. > > > . > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] KVM: add KVM_CAP_VMX_APICV to advertise hardware apic-v support 2014-12-18 3:37 ` zhanghailiang @ 2014-12-18 8:30 ` Paolo Bonzini 2014-12-18 8:57 ` Stefan Fritsch 0 siblings, 1 reply; 11+ messages in thread From: Paolo Bonzini @ 2014-12-18 8:30 UTC (permalink / raw) To: zhanghailiang, Stefan Fritsch; +Cc: hangaohuai, kvm, gleb, peter.huangpeng On 18/12/2014 04:37, zhanghailiang wrote: >> set this bit. But the HV_X64_APIC_ACCESS_RECOMMENDED bit should >> probably not be set if the host supports apic-v. I havn't done any > > That is what this patch want to do ;) This would cause a guest ABI change upon migration from APICv to non-APICv hosts, so it is not possible. Perhaps we need to set bit 8 but not bit 3. Paolo ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] KVM: add KVM_CAP_VMX_APICV to advertise hardware apic-v support 2014-12-18 8:30 ` Paolo Bonzini @ 2014-12-18 8:57 ` Stefan Fritsch 2014-12-18 9:23 ` Paolo Bonzini 0 siblings, 1 reply; 11+ messages in thread From: Stefan Fritsch @ 2014-12-18 8:57 UTC (permalink / raw) To: Paolo Bonzini; +Cc: zhanghailiang, hangaohuai, kvm, gleb, peter.huangpeng On Thu, 18 Dec 2014, Paolo Bonzini wrote: > On 18/12/2014 04:37, zhanghailiang wrote: > >> set this bit. But the HV_X64_APIC_ACCESS_RECOMMENDED bit should > >> probably not be set if the host supports apic-v. I havn't done any > > > > That is what this patch want to do ;) > > This would cause a guest ABI change upon migration from APICv to > non-APICv hosts, so it is not possible. Perhaps we need to set bit 8 > but not bit 3. I think setting the "recommended" bits to be best for the host where the VM is first started should always be ok. When it migrates to a different host, performance may not be optimal but otherwise it will work just fine. After all, non-optimal performance is not different from the current situation. It's important not to change the "supported" bits dynamically, though. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] KVM: add KVM_CAP_VMX_APICV to advertise hardware apic-v support 2014-12-18 8:57 ` Stefan Fritsch @ 2014-12-18 9:23 ` Paolo Bonzini 0 siblings, 0 replies; 11+ messages in thread From: Paolo Bonzini @ 2014-12-18 9:23 UTC (permalink / raw) To: Stefan Fritsch; +Cc: zhanghailiang, hangaohuai, kvm, gleb, peter.huangpeng On 18/12/2014 09:57, Stefan Fritsch wrote: > I think setting the "recommended" bits to be best for the host where the > VM is first started should always be ok. When it migrates to a different > host, performance may not be optimal but otherwise it will work just fine. > After all, non-optimal performance is not different from the current > situation. What if, due to a bug, a guest mysteriously starts failing on some hosts of a cluster but not others? This is really not a path you want to walk down. Paolo ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] KVM: add KVM_CAP_VMX_APICV to advertise hardware apic-v support 2014-12-11 8:07 [PATCH] KVM: add KVM_CAP_VMX_APICV to advertise hardware apic-v support zhanghailiang 2014-12-11 11:48 ` Paolo Bonzini @ 2014-12-11 13:08 ` Radim Krčmář 1 sibling, 0 replies; 11+ messages in thread From: Radim Krčmář @ 2014-12-11 13:08 UTC (permalink / raw) To: zhanghailiang; +Cc: kvm, gleb, pbonzini, peter.huangpeng 2014-12-11 16:07+0800, zhanghailiang: > User space (i.e. QEMU) should be able to check whether KVM > supports apic-v. User space will use this to decide whether enable > emulated MSR-based APIC (i.e. hyperv-vapic). Userspace is able to look at enable_apicv module parameter. (This decision probably belongs to controls above QEMU.) Anyway, I haven't thought much about it, so to the patch itself: - KVM_CAP_VMX_APICV isn't a good name for a capability that doesn't require VMX. - The detection depends on irqchip_in_kernel(), which is awkward. ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2014-12-18 9:23 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-12-11 8:07 [PATCH] KVM: add KVM_CAP_VMX_APICV to advertise hardware apic-v support zhanghailiang 2014-12-11 11:48 ` Paolo Bonzini 2014-12-11 12:53 ` zhanghailiang 2014-12-11 13:28 ` Radim Krčmář 2014-12-11 17:15 ` Paolo Bonzini 2014-12-17 22:17 ` Stefan Fritsch 2014-12-18 3:37 ` zhanghailiang 2014-12-18 8:30 ` Paolo Bonzini 2014-12-18 8:57 ` Stefan Fritsch 2014-12-18 9:23 ` Paolo Bonzini 2014-12-11 13:08 ` Radim Krčmář
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox