On 2013-09-30 11:08, Jan Kiszka wrote: > On 2013-09-26 17:04, Paolo Bonzini wrote: >> Il 16/09/2013 10:11, Arthur Chunqi Li ha scritto: >>> This patch contains the following two changes: >>> 1. Fix the bug in nested preemption timer support. If vmexit L2->L0 >>> with some reasons not emulated by L1, preemption timer value should >>> be save in such exits. >>> 2. Add support of "Save VMX-preemption timer value" VM-Exit controls >>> to nVMX. >>> >>> With this patch, nested VMX preemption timer features are fully >>> supported. >>> >>> Signed-off-by: Arthur Chunqi Li <yzt...@gmail.com> >>> --- >>> ChangeLog to v4: >>> Format changes and remove a flag in nested_vmx. >>> arch/x86/include/uapi/asm/msr-index.h | 1 + >>> arch/x86/kvm/vmx.c | 44 >>> +++++++++++++++++++++++++++++++-- >>> 2 files changed, 43 insertions(+), 2 deletions(-) >> >> Hi all, >> >> the test fails for me if the preemption timer value is set to a value >> that is above ~2000 (which means ~65000 TSC cycles on this machine). >> The preemption timer seems to count faster than what is expected, for >> example only up to 4 million cycles if you set it to one million. >> So, I am leaving the patch out of kvm/queue for now, until I can >> test it on more processors. > > I've done some measurements with the help of ftrace on the time it takes > to let the preemption timer trigger (no adjustments via Arthur's patch > were involved): On my Core i7-620M, the preemption timer seems to tick > almost 10 times faster than spec and scale value (5) suggests. I've > loaded a value of 100000, and it took about 130 µs until I got a vmexit > with reason PREEMPTION_TIMER (no other exists in between). > > qemu-system-x86-13765 [003] 298562.966079: bprint: > prepare_vmcs02: preempt val 100000 > qemu-system-x86-13765 [003] 298562.966083: kvm_entry: vcpu 0 > qemu-system-x86-13765 [003] 298562.966212: kvm_exit: reason > PREEMPTION_TIMER rip 0x401fea info 0 0 > > That's a frequency of ~769 MHz. The TSC ticks at 2.66 GHz. But 769 MHz * > 2^5 is 24.6 GHz. I've read the spec several times, but it seems pretty > clear on this. It just doesn't match reality. Very strange.
...but documented: I found an related errata for my processor (AAT59) and also for Xeon 5500 (AAK139). At least current Haswell generation is no affected. I can test the patch on a Haswell board I have at work later this week. Jan
signature.asc
Description: OpenPGP digital signature
