| Message ID | 1409150751-22763-1-git-send-email-chris.j.arges@canonical.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Il 27/08/2014 16:45, Chris J Arges ha scritto: > In unittests.cfg one can add a line like the following: > check = /proc/sys/kernel/nmi_watchdog=0 /proc/sys/kernel/ostype=Linux > > run_tests.sh will now check for those values (if defined) and only run > the test if all conditions are true. > > Signed-off-by: Chris J Arges <chris.j.arges@canonical.com> > --- > run_tests.sh | 21 +++++++++++++++++++-- > 1 file changed, 19 insertions(+), 2 deletions(-) > > diff --git a/run_tests.sh b/run_tests.sh > index 4758573..e48f1db 100755 > --- a/run_tests.sh > +++ b/run_tests.sh > @@ -18,6 +18,7 @@ function run() > local kernel="$4" > local opts="$5" > local arch="$6" > + local check="$7" > > if [ -z "$testname" ]; then > return > @@ -32,6 +33,18 @@ function run() > return > fi > > + # check a file for a particular value before running a test > + # the check line can contain multiple files to check separated by a space > + # but each check parameter needs to be of the form <path>=<value> > + for check_param in ${check[@]}; do > + path=${check_param%%=*} > + value=${check_param#*=} > + if [ "$path" ] && [ "$(cat $path)" != "$value" ]; then > + echo "skip $1 ($path not equal to $value)" > + return > + fi > + done > + > cmdline="./$TEST_DIR-run $kernel -smp $smp $opts" > if [ $verbose != 0 ]; then > echo $cmdline > @@ -57,18 +70,20 @@ function run_all() > local opts > local groups > local arch > + local check > > exec {config_fd}<$config > > while read -u $config_fd line; do > if [[ "$line" =~ ^\[(.*)\]$ ]]; then > - run "$testname" "$groups" "$smp" "$kernel" "$opts" "$arch" > + run "$testname" "$groups" "$smp" "$kernel" "$opts" "$arch" "$check" > testname=${BASH_REMATCH[1]} > smp=1 > kernel="" > opts="" > groups="" > arch="" > + check="" > elif [[ $line =~ ^file\ *=\ *(.*)$ ]]; then > kernel=$TEST_DIR/${BASH_REMATCH[1]} > elif [[ $line =~ ^smp\ *=\ *(.*)$ ]]; then > @@ -79,10 +94,12 @@ function run_all() > groups=${BASH_REMATCH[1]} > elif [[ $line =~ ^arch\ *=\ *(.*)$ ]]; then > arch=${BASH_REMATCH[1]} > + elif [[ $line =~ ^check\ *=\ *(.*)$ ]]; then > + check=${BASH_REMATCH[1]} > fi > done > > - run "$testname" "$groups" "$smp" "$kernel" "$opts" "$arch" > + run "$testname" "$groups" "$smp" "$kernel" "$opts" "$arch" "$check" > > exec {config_fd}<&- > } > Thanks, looks good. Are there more failures? Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
<snip> > Thanks, looks good. Are there more failures? > > Paolo > Paolo, Thanks for applying those patches! I now only see the two failures on my machine: model name : Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz I'm running with the tip of kvm master: 0ac625df43ce9d085d4ff54c1f739611f4308b13 (Merge tag 'kvm-s390-20140825') sudo ./x86-run x86/apic.flat -smp 2 -cpu qemu64,+x2apic,+tsc-deadline | grep -v PASS qemu-system-x86_64 -enable-kvm -device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 -display none -serial stdio -device pci-testdev -kernel x86/apic.flat -smp 2 -cpu qemu64,+x2apic,+tsc-deadline enabling apic enabling apic paging enabled cr0 = 80010011 cr3 = 7fff000 cr4 = 20 apic version: 1050014 x2apic enabled FAIL: tsc deadline timer clearing tsc deadline timer enabled SUMMARY: 16 tests, 1 unexpected failures Return value from qemu: 3 sudo ./x86-run x86/kvmclock_test.flat -smp 2 --append "10000000 `date +%s`" qemu-system-x86_64 -enable-kvm -device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 -display none -serial stdio -device pci-testdev -kernel x86/kvmclock_test.flat -smp 2 --append 10000000 1409174399 enabling apic enabling apic kvm-clock: cpu 0, msr 0x:44d4c0 kvm-clock: cpu 0, msr 0x:44d4c0 Wallclock test, threshold 5 Seconds get from host: 1409174399 Seconds get from kvmclock: 1409173176 Offset: -1223 offset too large! Check the stability of raw cycle ... Worst warp -1222831419357 Total vcpus: 2 Test loops: 10000000 Total warps: 1 Total stalls: 0 Worst warp: -1222831419357 Raw cycle is not stable Monotonic cycle test: Worst warp -1219118621614 Total vcpus: 2 Test loops: 10000000 Total warps: 1 Total stalls: 0 Worst warp: -1219118621614 Measure the performance of raw cycle ... Total vcpus: 2 Test loops: 10000000 TSC cycles: 1065145046 Measure the performance of adjusted cycle ... Total vcpus: 2 Test loops: 10000000 TSC cycles: 1126981511 Return value from qemu: 3 Let me know if anything comes to mind. I can also look more deeply into these failures. Thanks, --chris j arges -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
----- Messaggio originale ----- > Da: "Chris J Arges" <chris.j.arges@canonical.com> > A: "Paolo Bonzini" <pbonzini@redhat.com>, kvm@vger.kernel.org > Inviato: Mercoledì, 27 agosto 2014 23:24:14 > Oggetto: kvm-unit-test failures (was: [PATCH 1/2 v3] add check parameter to run_tests configuration) > > <snip> > > Thanks, looks good. Are there more failures? > > > > Paolo > > > > Paolo, > Thanks for applying those patches! > > I now only see the two failures on my machine: > model name : Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz > > I'm running with the tip of kvm master: > 0ac625df43ce9d085d4ff54c1f739611f4308b13 (Merge tag 'kvm-s390-20140825') > > sudo ./x86-run x86/apic.flat -smp 2 -cpu qemu64,+x2apic,+tsc-deadline | > grep -v PASS > qemu-system-x86_64 -enable-kvm -device pc-testdev -device > isa-debug-exit,iobase=0xf4,iosize=0x4 -display none -serial stdio > -device pci-testdev -kernel x86/apic.flat -smp 2 -cpu > qemu64,+x2apic,+tsc-deadline > enabling apic > enabling apic > paging enabled > cr0 = 80010011 > cr3 = 7fff000 > cr4 = 20 > apic version: 1050014 > x2apic enabled > FAIL: tsc deadline timer clearing > tsc deadline timer enabled This is fixed in kvm/next (3.18). > SUMMARY: 16 tests, 1 unexpected failures > Return value from qemu: 3 > > sudo ./x86-run x86/kvmclock_test.flat -smp 2 --append "10000000 `date +%s`" > qemu-system-x86_64 -enable-kvm -device pc-testdev -device > isa-debug-exit,iobase=0xf4,iosize=0x4 -display none -serial stdio > -device pci-testdev -kernel x86/kvmclock_test.flat -smp 2 --append > 10000000 1409174399 > enabling apic > enabling apic > kvm-clock: cpu 0, msr 0x:44d4c0 > kvm-clock: cpu 0, msr 0x:44d4c0 > Wallclock test, threshold 5 > Seconds get from host: 1409174399 > Seconds get from kvmclock: 1409173176 > Offset: -1223 Weird, your clock is 20 minutes behind in the VM than it is in the host. Is the offset always around -1200? What happens if you reboot? (I get 0, 1 or sometimes 2). Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 08/27/2014 05:05 PM, Paolo Bonzini wrote: > > > ----- Messaggio originale ----- >> Da: "Chris J Arges" <chris.j.arges@canonical.com> >> A: "Paolo Bonzini" <pbonzini@redhat.com>, kvm@vger.kernel.org >> Inviato: Mercoledì, 27 agosto 2014 23:24:14 >> Oggetto: kvm-unit-test failures (was: [PATCH 1/2 v3] add check parameter to run_tests configuration) >> >> <snip> >>> Thanks, looks good. Are there more failures? >>> >>> Paolo >>> >> >> Paolo, >> Thanks for applying those patches! >> >> I now only see the two failures on my machine: >> model name : Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz >> >> I'm running with the tip of kvm master: >> 0ac625df43ce9d085d4ff54c1f739611f4308b13 (Merge tag 'kvm-s390-20140825') >> >> sudo ./x86-run x86/apic.flat -smp 2 -cpu qemu64,+x2apic,+tsc-deadline | >> grep -v PASS >> qemu-system-x86_64 -enable-kvm -device pc-testdev -device >> isa-debug-exit,iobase=0xf4,iosize=0x4 -display none -serial stdio >> -device pci-testdev -kernel x86/apic.flat -smp 2 -cpu >> qemu64,+x2apic,+tsc-deadline >> enabling apic >> enabling apic >> paging enabled >> cr0 = 80010011 >> cr3 = 7fff000 >> cr4 = 20 >> apic version: 1050014 >> x2apic enabled >> FAIL: tsc deadline timer clearing >> tsc deadline timer enabled > > This is fixed in kvm/next (3.18). > >> SUMMARY: 16 tests, 1 unexpected failures >> Return value from qemu: 3 >> >> sudo ./x86-run x86/kvmclock_test.flat -smp 2 --append "10000000 `date +%s`" >> qemu-system-x86_64 -enable-kvm -device pc-testdev -device >> isa-debug-exit,iobase=0xf4,iosize=0x4 -display none -serial stdio >> -device pci-testdev -kernel x86/kvmclock_test.flat -smp 2 --append >> 10000000 1409174399 >> enabling apic >> enabling apic >> kvm-clock: cpu 0, msr 0x:44d4c0 >> kvm-clock: cpu 0, msr 0x:44d4c0 >> Wallclock test, threshold 5 >> Seconds get from host: 1409174399 >> Seconds get from kvmclock: 1409173176 >> Offset: -1223 > > Weird, your clock is 20 minutes behind in the VM than it > is in the host. Is the offset always around -1200? What > happens if you reboot? > > (I get 0, 1 or sometimes 2). > > Paolo > Hi Paolo, Results building with kvm queue tree (fd2752352bbc98850d83b5448a288d8991590317): CPU: model name : Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz I still get failures with the following test, I actually tested on multiple machines with identical hardware and the same failure occurred. In v3.13/v3.16 series kernels this passes. I'll look into which commit changed this result for me. I suspect it was fairly recent. ./x86-run x86/kvmclock_test.flat -smp 2 --append "10000000 `date +%s`" | grep -v PASS qemu-system-x86_64 -enable-kvm -device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 -display none -serial stdio -device pci-testdev -kernel x86/kvmclock_test.flat -smp 2 --append 10000000 1409160326 enabling apic enabling apic kvm-clock: cpu 0, msr 0x:44d520 kvm-clock: cpu 0, msr 0x:44d520 Wallclock test, threshold 5 Seconds get from host: 1409160326 Seconds get from kvmclock: 1409153484 Offset: -6842 offset too large! Check the stability of raw cycle ... Worst warp -6841795339348 Total vcpus: 2 Test loops: 10000000 Total warps: 1 Total stalls: 0 Worst warp: -6841795339348 Raw cycle is not stable Monotonic cycle test: Worst warp -6836691572679 Total vcpus: 2 Test loops: 10000000 Total warps: 1 Total stalls: 0 Worst warp: -6836691572679 Measure the performance of raw cycle ... Total vcpus: 2 Test loops: 10000000 TSC cycles: 1098400654 Measure the performance of adjusted cycle ... Total vcpus: 2 Test loops: 10000000 TSC cycles: 1106302952 Return value from qemu: 3 This is another test that fails or hangs, this passes in 3.13, but fails on 3.16 with my testing. I'll dig into this more perhaps to find out which commit changes things. ./x86-run x86/vmx.flat -smp 1 -cpu host,+vmx | grep -v PASS qemu-system-x86_64 -enable-kvm -device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 -display none -serial stdio -device pci-testdev -kernel x86/vmx.flat -smp 1 -cpu host,+vmx enabling apic paging enabled cr0 = 80010011 cr3 = 7fff000 cr4 = 20 Test suite: VMX capability reporting Test suite: vmenter Test suite: preemption timer Test suite: control field PAT Test suite: control field EFER Test suite: CR shadowing Test suite: I/O bitmap Test suite: instruction intercept Test suite: EPT framework FAIL: EPT violation - paging structure Test suite: interrupt `ASS: running a guest with interrupt acknowledgement set Test suite: debug controls SUMMARY: 109 tests, 1 unexpected failures Return value from qemu: 3 Here is the test case hanging: ./x86-run x86/vmx.flat -smp 1 -cpu host,+vmx | grep -v PASS qemu-system-x86_64 -enable-kvm -device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 -display none -serial stdio -device pci-testdev -kernel x86/vmx.flat -smp 1 -cpu host,+vmx enabling apic paging enabled cr0 = 80010011 cr3 = 7fff000 cr4 = 20 Test suite: VMX capability reporting Test suite: vmenter Test suite: preemption timer Test suite: control field PAT Test suite: control field EFER Test suite: CR shadowing Test suite: I/O bitmap Test suite: instruction intercept Test suite: EPT framework FAIL: EPT violation - paging structure FAIL: EPT - MMIO access Test suite: interrupt FAIL: intercepted interrupt + hlt Thanks, --chris j arges -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 08/29/2014 12:36 PM, Chris J Arges wrote: > On 08/27/2014 05:05 PM, Paolo Bonzini wrote: >> >> >> ----- Messaggio originale ----- >>> Da: "Chris J Arges" <chris.j.arges@canonical.com> >>> A: "Paolo Bonzini" <pbonzini@redhat.com>, kvm@vger.kernel.org >>> Inviato: Mercoledì, 27 agosto 2014 23:24:14 >>> Oggetto: kvm-unit-test failures (was: [PATCH 1/2 v3] add check parameter to run_tests configuration) >>> >>> <snip> >>>> Thanks, looks good. Are there more failures? >>>> >>>> Paolo >>>> >>> >>> Paolo, >>> Thanks for applying those patches! >>> >>> I now only see the two failures on my machine: >>> model name : Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz >>> >>> I'm running with the tip of kvm master: >>> 0ac625df43ce9d085d4ff54c1f739611f4308b13 (Merge tag 'kvm-s390-20140825') >>> >>> sudo ./x86-run x86/apic.flat -smp 2 -cpu qemu64,+x2apic,+tsc-deadline | >>> grep -v PASS >>> qemu-system-x86_64 -enable-kvm -device pc-testdev -device >>> isa-debug-exit,iobase=0xf4,iosize=0x4 -display none -serial stdio >>> -device pci-testdev -kernel x86/apic.flat -smp 2 -cpu >>> qemu64,+x2apic,+tsc-deadline >>> enabling apic >>> enabling apic >>> paging enabled >>> cr0 = 80010011 >>> cr3 = 7fff000 >>> cr4 = 20 >>> apic version: 1050014 >>> x2apic enabled >>> FAIL: tsc deadline timer clearing >>> tsc deadline timer enabled >> >> This is fixed in kvm/next (3.18). >> >>> SUMMARY: 16 tests, 1 unexpected failures >>> Return value from qemu: 3 >>> >>> sudo ./x86-run x86/kvmclock_test.flat -smp 2 --append "10000000 `date +%s`" >>> qemu-system-x86_64 -enable-kvm -device pc-testdev -device >>> isa-debug-exit,iobase=0xf4,iosize=0x4 -display none -serial stdio >>> -device pci-testdev -kernel x86/kvmclock_test.flat -smp 2 --append >>> 10000000 1409174399 >>> enabling apic >>> enabling apic >>> kvm-clock: cpu 0, msr 0x:44d4c0 >>> kvm-clock: cpu 0, msr 0x:44d4c0 >>> Wallclock test, threshold 5 >>> Seconds get from host: 1409174399 >>> Seconds get from kvmclock: 1409173176 >>> Offset: -1223 >> >> Weird, your clock is 20 minutes behind in the VM than it >> is in the host. Is the offset always around -1200? What >> happens if you reboot? >> >> (I get 0, 1 or sometimes 2). >> >> Paolo >> > > Hi Paolo, > > Results building with kvm queue tree > (fd2752352bbc98850d83b5448a288d8991590317): > CPU: > model name : Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz > > I still get failures with the following test, I actually tested on > multiple machines with identical hardware and the same failure occurred. > In v3.13/v3.16 series kernels this passes. I'll look into which commit > changed this result for me. I suspect it was fairly recent. > I did a quick grep through the patches between v3.16 and the latest and I found: (0d3da0d26e3c3515997c99451ce3b0ad1a69a36c KVM: x86: fix TSC matching). I reverted this patch and the test case passed for me. Looking at the patch, I added an extra else statement as so: if (!matched) { kvm->arch.nr_vcpus_matched_tsc = 0; } else if (!already_matched) { kvm->arch.nr_vcpus_matched_tsc++; } else { printk("kvm: do we get here?\n"); } And indeed there is a condition where matched && already_matched are both true. In this case we don't zero or increment nr_vcpus_matched_tsc. Incrementing nr_vcpus_matched_tsc in that last else clause allows the test to pass; however this is identical to the logic before the patch. Any suggestions for fixing this case? Thanks, --chris j arges > ./x86-run x86/kvmclock_test.flat -smp 2 --append "10000000 `date +%s`" | > grep -v PASS > qemu-system-x86_64 -enable-kvm -device pc-testdev -device > isa-debug-exit,iobase=0xf4,iosize=0x4 -display none -serial stdio > -device pci-testdev -kernel x86/kvmclock_test.flat -smp 2 --append > 10000000 1409160326 > enabling apic > enabling apic > kvm-clock: cpu 0, msr 0x:44d520 > kvm-clock: cpu 0, msr 0x:44d520 > Wallclock test, threshold 5 > Seconds get from host: 1409160326 > Seconds get from kvmclock: 1409153484 > Offset: -6842 > offset too large! > Check the stability of raw cycle ... > Worst warp -6841795339348 > Total vcpus: 2 > Test loops: 10000000 > Total warps: 1 > Total stalls: 0 > Worst warp: -6841795339348 > Raw cycle is not stable > Monotonic cycle test: > Worst warp -6836691572679 > Total vcpus: 2 > Test loops: 10000000 > Total warps: 1 > Total stalls: 0 > Worst warp: -6836691572679 > Measure the performance of raw cycle ... > Total vcpus: 2 > Test loops: 10000000 > TSC cycles: 1098400654 > Measure the performance of adjusted cycle ... > Total vcpus: 2 > Test loops: 10000000 > TSC cycles: 1106302952 > Return value from qemu: 3 > > This is another test that fails or hangs, this passes in 3.13, but fails > on 3.16 with my testing. I'll dig into this more perhaps to find out > which commit changes things. > > ./x86-run x86/vmx.flat -smp 1 -cpu host,+vmx | grep -v PASS > qemu-system-x86_64 -enable-kvm -device pc-testdev -device > isa-debug-exit,iobase=0xf4,iosize=0x4 -display none -serial stdio > -device pci-testdev -kernel x86/vmx.flat -smp 1 -cpu host,+vmx > enabling apic > paging enabled > cr0 = 80010011 > cr3 = 7fff000 > cr4 = 20 > > Test suite: VMX capability reporting > > Test suite: vmenter > > Test suite: preemption timer > > Test suite: control field PAT > > Test suite: control field EFER > > Test suite: CR shadowing > > Test suite: I/O bitmap > > Test suite: instruction intercept > > Test suite: EPT framework > FAIL: EPT violation - paging structure > > Test suite: interrupt > `ASS: running a guest with interrupt acknowledgement set > > Test suite: debug controls > > SUMMARY: 109 tests, 1 unexpected failures > Return value from qemu: 3 > > Here is the test case hanging: > > ./x86-run x86/vmx.flat -smp 1 -cpu host,+vmx | grep -v PASS > qemu-system-x86_64 -enable-kvm -device pc-testdev -device > isa-debug-exit,iobase=0xf4,iosize=0x4 -display none -serial stdio > -device pci-testdev -kernel x86/vmx.flat -smp 1 -cpu host,+vmx > enabling apic > paging enabled > cr0 = 80010011 > cr3 = 7fff000 > cr4 = 20 > > Test suite: VMX capability reporting > > Test suite: vmenter > > Test suite: preemption timer > > Test suite: control field PAT > > Test suite: control field EFER > > Test suite: CR shadowing > > Test suite: I/O bitmap > > Test suite: instruction intercept > > Test suite: EPT framework > FAIL: EPT violation - paging structure > FAIL: EPT - MMIO access > > Test suite: interrupt > FAIL: intercepted interrupt + hlt > > Thanks, > --chris j arges > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Il 29/08/2014 19:36, Chris J Arges ha scritto: > I still get failures with the following test, I actually tested on > multiple machines with identical hardware and the same failure occurred. > In v3.13/v3.16 series kernels this passes. I'll look into which commit > changed this result for me. I suspect it was fairly recent. I would try bisecting between 0e5ac3a8b100469ea154f87dd57b685fbdd356f6 (might be bad) and 41fa4215f8e8150bdc5d2a5f8704915f1b059fa8 (might be good). Is this a laptop or desktop? Any relationship between the "Offset" and how long the machine has been up? Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 08/29/2014 04:08 PM, Paolo Bonzini wrote: > Il 29/08/2014 19:36, Chris J Arges ha scritto: >> I still get failures with the following test, I actually tested on >> multiple machines with identical hardware and the same failure occurred. >> In v3.13/v3.16 series kernels this passes. I'll look into which commit >> changed this result for me. I suspect it was fairly recent. > > I would try bisecting between 0e5ac3a8b100469ea154f87dd57b685fbdd356f6 > (might be bad) and 41fa4215f8e8150bdc5d2a5f8704915f1b059fa8 (might be good). > Just sent the other email with my bisect results, the 'bad' commit for me is: 0d3da0d26e3c3515997c99451ce3b0ad1a69a36c A revert on this commit allows the tests to pass again. > Is this a laptop or desktop? Any relationship between the "Offset" and > how long the machine has been up? > > Paolo > This is a server; and no, I've reboot the machine and re-run the test. I've also run it after days of uptime. --chris -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Il 29/08/2014 23:05, Chris J Arges ha scritto: > And indeed there is a condition where matched && already_matched are > both true. In this case we don't zero or increment nr_vcpus_matched_tsc. > Incrementing nr_vcpus_matched_tsc in that last else clause allows the > test to pass; however this is identical to the logic before the patch. Can you please trace the test using trace-cmd (http://www.linux-kvm.org/page/Tracing) and send the output? Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 08/31/2014 11:05 AM, Paolo Bonzini wrote: > Il 29/08/2014 23:05, Chris J Arges ha scritto: >> And indeed there is a condition where matched && already_matched are >> both true. In this case we don't zero or increment nr_vcpus_matched_tsc. >> Incrementing nr_vcpus_matched_tsc in that last else clause allows the >> test to pass; however this is identical to the logic before the patch. > > Can you please trace the test using trace-cmd > (http://www.linux-kvm.org/page/Tracing) and send the output? > > Paolo > Paolo, I have posted the trace data here: http://people.canonical.com/~arges/kvm/trace.dat.xz Here is the output from the actual test case: enabling apic enabling apic kvm-clock: cpu 0, msr 0x:44d4c0 kvm-clock: cpu 0, msr 0x:44d4c0 Wallclock test, threshold 5 Seconds get from host: 1409687073 Seconds get from kvmclock: 1409333034 Offset: -354039 offset too large! Check the stability of raw cycle ... Worst warp -354462672821748 Total vcpus: 2 Test loops: 10000000 Total warps: 1 Total stalls: 0 Worst warp: -354462672821748 Raw cycle is not stable Monotonic cycle test: Worst warp -354455286691490 Total vcpus: 2 Test loops: 10000000 Total warps: 1 Total stalls: 0 Worst warp: -354455286691490 Measure the performance of raw cycle ... Total vcpus: 2 Test loops: 10000000 TSC cycles: 1234719818 Measure the performance of adjusted cycle ... Total vcpus: 2 Test loops: 10000000 TSC cycles: 1234750103 I also enabled dynamic debugging on arch/x86/kvm/x86.c (on a separate run): [354558.460867] kvm_get_time_scale: base_khz 1000000 => 2593993, shift 2, mul 2785278775 [354558.461034] kvm: new tsc generation 1, clock 0 [354558.461812] kvm_get_time_scale: base_khz 1000000 => 2593993, shift 2, mul 2785278775 [354558.461846] kvm: matched tsc offset for 0 [354558.477542] kvm: matched tsc offset for 0 [354558.477614] kvm: matched tsc offset for 0 [354558.513729] kvm: matched tsc offset for 0 [354558.541724] kvm: matched tsc offset for 0 [354558.741532] kvm_get_time_scale: base_khz 2593993 => 1000000, shift -1, mul 3311471770 [354558.742551] kvm_get_time_scale: base_khz 2593993 => 1000000, shift -1, mul 3311471770 Also I ensured that this was reproducible with the latest qemu, and these results were gathered with the latest version as of today. Any other places to look into? --chris j arges -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Il 02/09/2014 21:57, Chris J Arges ha scritto: >> > Can you please trace the test using trace-cmd >> > (http://www.linux-kvm.org/page/Tracing) and send the output? >> > >> > Paolo >> > > Paolo, > > I have posted the trace data here: > http://people.canonical.com/~arges/kvm/trace.dat.xz Can you try running the test again (no need to get a new trace) with clocksource=hpet on the kernel command line? Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/03/2014 09:47 AM, Paolo Bonzini wrote: > Il 02/09/2014 21:57, Chris J Arges ha scritto: >>>> Can you please trace the test using trace-cmd >>>> (http://www.linux-kvm.org/page/Tracing) and send the output? >>>> >>>> Paolo >>>> >> Paolo, >> >> I have posted the trace data here: >> http://people.canonical.com/~arges/kvm/trace.dat.xz > > Can you try running the test again (no need to get a new trace) with > clocksource=hpet on the kernel command line? > > Paolo > ./x86-run x86/kvmclock_test.flat -smp 2 --append "10000000 `date +%s`" qemu-system-x86_64 -enable-kvm -device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 -display none -serial stdio -device pci-testdev -kernel x86/kvmclock_test.flat -smp 2 --append 10000000 1409757645 enabling apic enabling apic kvm-clock: cpu 0, msr 0x:44d4c0 kvm-clock: cpu 0, msr 0x:44d4c0 Wallclock test, threshold 5 Seconds get from host: 1409757645 Seconds get from kvmclock: 1409757645 Offset: 0 Check the stability of raw cycle ... Total vcpus: 2 Test loops: 10000000 Total warps: 0 Total stalls: 0 Worst warp: 0 Raw cycle is stable Monotonic cycle test: Total vcpus: 2 Test loops: 10000000 Total warps: 0 Total stalls: 0 Worst warp: 0 Measure the performance of raw cycle ... Total vcpus: 2 Test loops: 10000000 TSC cycles: 1106490299 Measure the performance of adjusted cycle ... Total vcpus: 2 Test loops: 10000000 TSC cycles: 3463433372 Return value from qemu: 1 Ok this passes, I'll now try the patch without the cmdline option. --chris -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/run_tests.sh b/run_tests.sh index 4758573..e48f1db 100755 --- a/run_tests.sh +++ b/run_tests.sh @@ -18,6 +18,7 @@ function run() local kernel="$4" local opts="$5" local arch="$6" + local check="$7" if [ -z "$testname" ]; then return @@ -32,6 +33,18 @@ function run() return fi + # check a file for a particular value before running a test + # the check line can contain multiple files to check separated by a space + # but each check parameter needs to be of the form <path>=<value> + for check_param in ${check[@]}; do + path=${check_param%%=*} + value=${check_param#*=} + if [ "$path" ] && [ "$(cat $path)" != "$value" ]; then + echo "skip $1 ($path not equal to $value)" + return + fi + done + cmdline="./$TEST_DIR-run $kernel -smp $smp $opts" if [ $verbose != 0 ]; then echo $cmdline @@ -57,18 +70,20 @@ function run_all() local opts local groups local arch + local check exec {config_fd}<$config while read -u $config_fd line; do if [[ "$line" =~ ^\[(.*)\]$ ]]; then - run "$testname" "$groups" "$smp" "$kernel" "$opts" "$arch" + run "$testname" "$groups" "$smp" "$kernel" "$opts" "$arch" "$check" testname=${BASH_REMATCH[1]} smp=1 kernel="" opts="" groups="" arch="" + check="" elif [[ $line =~ ^file\ *=\ *(.*)$ ]]; then kernel=$TEST_DIR/${BASH_REMATCH[1]} elif [[ $line =~ ^smp\ *=\ *(.*)$ ]]; then @@ -79,10 +94,12 @@ function run_all() groups=${BASH_REMATCH[1]} elif [[ $line =~ ^arch\ *=\ *(.*)$ ]]; then arch=${BASH_REMATCH[1]} + elif [[ $line =~ ^check\ *=\ *(.*)$ ]]; then + check=${BASH_REMATCH[1]} fi done - run "$testname" "$groups" "$smp" "$kernel" "$opts" "$arch" + run "$testname" "$groups" "$smp" "$kernel" "$opts" "$arch" "$check" exec {config_fd}<&- }
In unittests.cfg one can add a line like the following: check = /proc/sys/kernel/nmi_watchdog=0 /proc/sys/kernel/ostype=Linux run_tests.sh will now check for those values (if defined) and only run the test if all conditions are true. Signed-off-by: Chris J Arges <chris.j.arges@canonical.com> --- run_tests.sh | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-)