2016-09-14 20:03 GMT+08:00 Radim Krčmář <rkrcmar@xxxxxxxxxx>: > 2016-09-14 11:40+0200, Paolo Bonzini: >> On 14/09/2016 09:58, Wanpeng Li wrote: >>> From: Wanpeng Li <wanpeng.li@xxxxxxxxxxx> >>> >>> I observed that kvmvapic(to optimize flexpriority=N or AMD) is used >>> to boost TPR access when testing kvm-unit-test/eventinj.flat tpr case >>> on my haswell desktop (w/ flexpriority, w/o APICv). Commit (8d14695f9542 >>> x86, apicv: add virtual x2apic support) disable virtual x2apic mode >>> completely if w/o APICv, and the author also told me that windows guest >>> can't enter into x2apic mode when he developed the APICv feature several >>> years ago. However, it is not truth currently, Interrupt Remapping and >>> vIOMMU is added to qemu and the developers from Intel test windows 8 can >>> work in x2apic mode w/ Interrupt Remapping enabled recently. >>> >>> This patch enables TPR shadow for virtual x2apic mode to boost >>> windows guest in x2apic mode even if w/o APICv. >>> >>> Can pass the kvm-unit-test. >> >> Ok, now I see what you meant; this actually makes sense. I don't expect >> much speedup though, because Linux doesn't touch the TPR and Windows is >> likely going to use the Hyper-V APIC MSRs when APICv is disabled. For >> this reason I'm not sure if the patch is useful in practice. > > I agree with Paolo on the use case -- what configurations benefit from > this change? > >> To test this patch, you have to run kvm-unit-tests with Hyper-V >> synthetic interrupt enabled. Did you do this? > > The patch is buggy. MSR bitmaps are global and we'd have a CVE if one > guests used synic (=> disabled apicv) and one didn't. > You'd want a new set of bitmaps and assign them in vmx_set_msr_bitmap() > (or completely rewrite our management). Do you think introduce per-VM x2apic msr bitmap make sense? Regards, Wanpeng Li -- 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
