restructure results

4 files changed, 0 insertions, 1152 deletions

diff --git a/results/classifier/012/graphic/30680944 b/results/classifier/012/graphic/30680944
deleted file mode 100644
index 865959d9..00000000
--- a/results/classifier/012/graphic/30680944
+++ /dev/null
@@ -1,613 +0,0 @@
-graphic: 0.965
-semantic: 0.953
-other: 0.944
-register: 0.941
-assembly: 0.940
-performance: 0.937
-debug: 0.936
-device: 0.935
-permissions: 0.933
-architecture: 0.927
-PID: 0.913
-arm: 0.910
-socket: 0.864
-boot: 0.840
-files: 0.835
-risc-v: 0.830
-TCG: 0.828
-kernel virtual machine: 0.818
-vnc: 0.815
-network: 0.813
-mistranslation: 0.799
-x86: 0.661
-
-[BUG]QEMU jump into interrupt when single-stepping on aarch64
-
-Dear, folks,
-
-I try to debug Linux kernel with QEMU in single-stepping mode on aarch64 
-platform,
-the added breakpoint hits but after I type `step`, the gdb always jumps into 
-interrupt.
-
-My env:
-
-        gdb-10.2
-        qemu-6.2.0
-        host kernel: 5.10.84
-        VM kernel: 5.10.84
-
-The steps to reproduce:
-        # host console: run a VM with only one core, the import arg: <qemu:arg 
-value='-s'/>
-        # details can be found here:
-https://www.redhat.com/en/blog/debugging-kernel-qemulibvirt
-virsh create dev_core0.xml
-        
-        # run gdb client
-        gdb ./vmlinux
-
-        # gdb client on host console
-        (gdb) dir 
-./usr/src/debug/kernel-5.10.84/linux-5.10.84-004.alpha.ali5000.alios7.aarch64
-        (gdb) target remote localhost:1234
-        (gdb) info b
-        Num     Type           Disp Enb Address            What
-        1       breakpoint     keep y   <MULTIPLE>
-        1.1                         y   0xffff800010361444 
-mm/memory-failure.c:1318
-        1.2                         y   0xffff800010361450 in memory_failure
-                                                   at mm/memory-failure.c:1488
-        (gdb) c
-        Continuing.
-
-        # console in VM, use madvise to inject a hwposion at virtual address 
-vaddr,
-        # which will hit the b inmemory_failur: madvise(vaddr, pagesize, 
-MADV_HWPOISON);
-        # and the VM pause
-        ./run_madvise.c
-
-        # gdb client on host console
-        (gdb)
-        Continuing.
-        Breakpoint 1, 0xffff800010361444 in memory_failure () at 
-mm/memory-failure.c:1318
-        1318                    res = -EHWPOISON;
-        (gdb) n
-        vectors () at arch/arm64/kernel/entry.S:552
-        552             kernel_ventry   1, irq                          // IRQ 
-EL1h
-        (gdb) n
-        (gdb) n
-        (gdb) n
-        (gdb) n
-        gic_handle_irq (regs=0xffff8000147c3b80) at 
-drivers/irqchip/irq-gic-v3.c:721
-        # after several step, I got the irqnr
-        (gdb) p irqnr
-        $5 = 8262
-
-Sometimes, the irqnr is 27， which is used for arch_timer.
-
-I was wondering do you have any comments on this? And feedback are welcomed.
-
-Thank you.
-
-Best Regards.
-Shuai
-
-On 4/6/22 09:30, Shuai Xue wrote:
-Dear, folks,
-
-I try to debug Linux kernel with QEMU in single-stepping mode on aarch64 
-platform,
-the added breakpoint hits but after I type `step`, the gdb always jumps into 
-interrupt.
-
-My env:
-
-        gdb-10.2
-        qemu-6.2.0
-        host kernel: 5.10.84
-        VM kernel: 5.10.84
-
-The steps to reproduce:
-        # host console: run a VM with only one core, the import arg: <qemu:arg 
-value='-s'/>
-        # details can be found here:
-https://www.redhat.com/en/blog/debugging-kernel-qemulibvirt
-virsh create dev_core0.xml
-        
-        # run gdb client
-        gdb ./vmlinux
-
-        # gdb client on host console
-        (gdb) dir 
-./usr/src/debug/kernel-5.10.84/linux-5.10.84-004.alpha.ali5000.alios7.aarch64
-        (gdb) target remote localhost:1234
-        (gdb) info b
-        Num     Type           Disp Enb Address            What
-        1       breakpoint     keep y   <MULTIPLE>
-        1.1                         y   0xffff800010361444 
-mm/memory-failure.c:1318
-        1.2                         y   0xffff800010361450 in memory_failure
-                                                    at mm/memory-failure.c:1488
-        (gdb) c
-        Continuing.
-
-        # console in VM, use madvise to inject a hwposion at virtual address 
-vaddr,
-        # which will hit the b inmemory_failur: madvise(vaddr, pagesize, 
-MADV_HWPOISON);
-        # and the VM pause
-        ./run_madvise.c
-
-        # gdb client on host console
-        (gdb)
-        Continuing.
-        Breakpoint 1, 0xffff800010361444 in memory_failure () at 
-mm/memory-failure.c:1318
-        1318                    res = -EHWPOISON;
-        (gdb) n
-        vectors () at arch/arm64/kernel/entry.S:552
-        552             kernel_ventry   1, irq                          // IRQ 
-EL1h
-The 'n' command is not a single-step: use stepi, which will suppress interrupts.
-Anyway, not a bug.
-
-r~
-
-在 2022/4/7 AM12:57, Richard Henderson 写道:
->
-On 4/6/22 09:30, Shuai Xue wrote:
->
-> Dear, folks,
->
->
->
-> I try to debug Linux kernel with QEMU in single-stepping mode on aarch64
->
-> platform,
->
-> the added breakpoint hits but after I type `step`, the gdb always jumps into
->
-> interrupt.
->
->
->
-> My env:
->
->
->
->     gdb-10.2
->
->     qemu-6.2.0
->
->     host kernel: 5.10.84
->
->     VM kernel: 5.10.84
->
->
->
-> The steps to reproduce:
->
->     # host console: run a VM with only one core, the import arg: <qemu:arg
->
-> value='-s'/>
->
->     # details can be found here:
->
->
-https://www.redhat.com/en/blog/debugging-kernel-qemulibvirt
->
->     virsh create dev_core0.xml
->
->    Â
->
->     # run gdb client
->
->     gdb ./vmlinux
->
->
->
->     # gdb client on host console
->
->     (gdb) dir
->
-> ./usr/src/debug/kernel-5.10.84/linux-5.10.84-004.alpha.ali5000.alios7.aarch64
->
->     (gdb) target remote localhost:1234
->
->     (gdb) info b
->
->     Num     Type           Disp Enb Address            What
->
->     1       breakpoint     keep y   <MULTIPLE>
->
->     1.1                         y   0xffff800010361444
->
-> mm/memory-failure.c:1318
->
->     1.2                         y   0xffff800010361450 in memory_failure
->
->                                                     at
->
-> mm/memory-failure.c:1488
->
->     (gdb) c
->
->     Continuing.
->
->
->
->     # console in VM, use madvise to inject a hwposion at virtual address
->
-> vaddr,
->
->     # which will hit the b inmemory_failur: madvise(vaddr, pagesize,
->
-> MADV_HWPOISON);
->
->     # and the VM pause
->
->     ./run_madvise.c
->
->
->
->     # gdb client on host console
->
->     (gdb)
->
->     Continuing.
->
->     Breakpoint 1, 0xffff800010361444 in memory_failure () at
->
-> mm/memory-failure.c:1318
->
->     1318                    res = -EHWPOISON;
->
->     (gdb) n
->
->     vectors () at arch/arm64/kernel/entry.S:552
->
->     552             kernel_ventry   1, irq                          // IRQ
->
-> EL1h
->
->
-The 'n' command is not a single-step: use stepi, which will suppress
->
-interrupts.
->
-Anyway, not a bug.
->
->
-r~
-Hi, Richard,
-
-Thank you for your quick reply, I also try `stepi`, but it does NOT work either.
-
-        (gdb) c
-        Continuing.
-
-        Breakpoint 1, memory_failure (pfn=1273982, flags=1) at 
-mm/memory-failure.c:1488
-        1488    {
-        (gdb) stepi
-        vectors () at arch/arm64/kernel/entry.S:552
-        552             kernel_ventry   1, irq                          // IRQ 
-EL1h
-
-According to QEMU doc[1]: the default single stepping behavior is step with the 
-IRQs
-and timer service routines off. I checked the MASK bits used to control the 
-single
-stepping IE on my machine as bellow:
-
-        # gdb client on host (x86 plafrom)
-        (gdb) maintenance packet qqemu.sstepbits
-        sending: "qqemu.sstepbits"
-        received: "ENABLE=1,NOIRQ=2,NOTIMER=4"
-
-The sstep MASK looks as expected, but does not work as expected.
-
-I also try the same kernel and qemu version on X86 platform:
->
->     gdb-10.2
->
->     qemu-6.2.0
->
->     host kernel: 5.10.84
->
->     VM kernel: 5.10.84
-The command `n` jumps to the next instruction.
-
-        # gdb client on host (x86 plafrom)
-        (gdb) b memory-failure.c:1488
-        Breakpoint 1, memory_failure (pfn=1128931, flags=1) at 
-mm/memory-failure.c:1488
-        1488    {
-        (gdb) n
-        1497            if (!sysctl_memory_failure_recovery)
-        (gdb) stepi
-        0xffffffff812efdbc      1497            if 
-(!sysctl_memory_failure_recovery)
-        (gdb) stepi
-        0xffffffff812efdbe      1497            if 
-(!sysctl_memory_failure_recovery)
-        (gdb) n
-        1500            p = pfn_to_online_page(pfn);
-        (gdb) l
-        1496
-        1497            if (!sysctl_memory_failure_recovery)
-        1498                    panic("Memory failure on page %lx", pfn);
-        1499
-        1500            p = pfn_to_online_page(pfn);
-        1501            if (!p) {
-
-Best Regrades,
-Shuai
-
-
-[1]
-https://github.com/qemu/qemu/blob/master/docs/system/gdb.rst
-
-在 2022/4/7 PM12:10, Shuai Xue 写道:
->
-在 2022/4/7 AM12:57, Richard Henderson 写道:
->
-> On 4/6/22 09:30, Shuai Xue wrote:
->
->> Dear, folks,
->
->>
->
->> I try to debug Linux kernel with QEMU in single-stepping mode on aarch64
->
->> platform,
->
->> the added breakpoint hits but after I type `step`, the gdb always jumps
->
->> into interrupt.
->
->>
->
->> My env:
->
->>
->
->>     gdb-10.2
->
->>     qemu-6.2.0
->
->>     host kernel: 5.10.84
->
->>     VM kernel: 5.10.84
->
->>
->
->> The steps to reproduce:
->
->>     # host console: run a VM with only one core, the import arg: <qemu:arg
->
->> value='-s'/>
->
->>     # details can be found here:
->
->>
-https://www.redhat.com/en/blog/debugging-kernel-qemulibvirt
->
->>     virsh create dev_core0.xml
->
->>    Â
->
->>     # run gdb client
->
->>     gdb ./vmlinux
->
->>
->
->>     # gdb client on host console
->
->>     (gdb) dir
->
->> ./usr/src/debug/kernel-5.10.84/linux-5.10.84-004.alpha.ali5000.alios7.aarch64
->
->>     (gdb) target remote localhost:1234
->
->>     (gdb) info b
->
->>     Num     Type           Disp Enb Address            What
->
->>     1       breakpoint     keep y   <MULTIPLE>
->
->>     1.1                         y   0xffff800010361444
->
->> mm/memory-failure.c:1318
->
->>     1.2                         y   0xffff800010361450 in memory_failure
->
->>                                                     at
->
->> mm/memory-failure.c:1488
->
->>     (gdb) c
->
->>     Continuing.
->
->>
->
->>     # console in VM, use madvise to inject a hwposion at virtual address
->
->> vaddr,
->
->>     # which will hit the b inmemory_failur: madvise(vaddr, pagesize,
->
->> MADV_HWPOISON);
->
->>     # and the VM pause
->
->>     ./run_madvise.c
->
->>
->
->>     # gdb client on host console
->
->>     (gdb)
->
->>     Continuing.
->
->>     Breakpoint 1, 0xffff800010361444 in memory_failure () at
->
->> mm/memory-failure.c:1318
->
->>     1318                    res = -EHWPOISON;
->
->>     (gdb) n
->
->>     vectors () at arch/arm64/kernel/entry.S:552
->
->>     552             kernel_ventry   1, irq                          // IRQ
->
->> EL1h
->
->
->
-> The 'n' command is not a single-step: use stepi, which will suppress
->
-> interrupts.
->
-> Anyway, not a bug.
->
->
->
-> r~
->
->
-Hi, Richard,
->
->
-Thank you for your quick reply, I also try `stepi`, but it does NOT work
->
-either.
->
->
-(gdb) c
->
-Continuing.
->
->
-Breakpoint 1, memory_failure (pfn=1273982, flags=1) at
->
-mm/memory-failure.c:1488
->
-1488    {
->
-(gdb) stepi
->
-vectors () at arch/arm64/kernel/entry.S:552
->
-552             kernel_ventry   1, irq                          // IRQ
->
-EL1h
->
->
-According to QEMU doc[1]: the default single stepping behavior is step with
->
-the IRQs
->
-and timer service routines off. I checked the MASK bits used to control the
->
-single
->
-stepping IE on my machine as bellow:
->
->
-# gdb client on host (x86 plafrom)
->
-(gdb) maintenance packet qqemu.sstepbits
->
-sending: "qqemu.sstepbits"
->
-received: "ENABLE=1,NOIRQ=2,NOTIMER=4"
->
->
-The sstep MASK looks as expected, but does not work as expected.
->
->
-I also try the same kernel and qemu version on X86 platform:
->
->>     gdb-10.2
->
->>     qemu-6.2.0
->
->>     host kernel: 5.10.84
->
->>     VM kernel: 5.10.84
->
->
->
-The command `n` jumps to the next instruction.
->
->
-# gdb client on host (x86 plafrom)
->
-(gdb) b memory-failure.c:1488
->
-Breakpoint 1, memory_failure (pfn=1128931, flags=1) at
->
-mm/memory-failure.c:1488
->
-1488    {
->
-(gdb) n
->
-1497            if (!sysctl_memory_failure_recovery)
->
-(gdb) stepi
->
-0xffffffff812efdbc      1497            if
->
-(!sysctl_memory_failure_recovery)
->
-(gdb) stepi
->
-0xffffffff812efdbe      1497            if
->
-(!sysctl_memory_failure_recovery)
->
-(gdb) n
->
-1500            p = pfn_to_online_page(pfn);
->
-(gdb) l
->
-1496
->
-1497            if (!sysctl_memory_failure_recovery)
->
-1498                    panic("Memory failure on page %lx", pfn);
->
-1499
->
-1500            p = pfn_to_online_page(pfn);
->
-1501            if (!p) {
->
->
-Best Regrades,
->
-Shuai
->
->
->
-[1]
-https://github.com/qemu/qemu/blob/master/docs/system/gdb.rst
-Hi, Richard,
-
-I was wondering that do you have any comments to this?
-
-Best Regrades,
-Shuai
-
diff --git a/results/classifier/012/graphic/46572227 b/results/classifier/012/graphic/46572227
deleted file mode 100644
index 6a17e5ed..00000000
--- a/results/classifier/012/graphic/46572227
+++ /dev/null
@@ -1,424 +0,0 @@
-semantic: 0.965
-graphic: 0.962
-debug: 0.958
-permissions: 0.955
-mistranslation: 0.946
-PID: 0.937
-performance: 0.935
-assembly: 0.931
-architecture: 0.930
-other: 0.927
-arm: 0.923
-register: 0.913
-vnc: 0.904
-device: 0.901
-boot: 0.900
-x86: 0.897
-kernel virtual machine: 0.891
-TCG: 0.890
-files: 0.879
-risc-v: 0.872
-network: 0.841
-socket: 0.841
-
-[Qemu-devel] [Bug?] Windows 7's time drift obviously while RTC rate switching frequently between high and low timer rate
-
-Hi,
-
-We tested with the latest QEMU, and found that time drift obviously (clock fast 
-in guest)
-in Windows 7 64 bits guest in some cases.
-
-It is easily to reproduce, using the follow QEMU command line to start windows 
-7:
-
-# x86_64-softmmu/qemu-system-x86_64 -name win7_64_2U_raw -machine 
-pc-i440fx-2.6,accel=kvm,usb=off -cpu host -m 2048 -realtime mlock=off -smp 
-4,sockets=2,cores=2,threads=1 -rtc base=utc,clock=vm,driftfix=slew -no-hpet 
--global kvm-pit.lost_tick_policy=discard -hda /mnt/nfs/win7_sp1_32_2U_raw -vnc 
-:11 -netdev tap,id=hn0,vhost=off -device rtl8139,id=net-pci0,netdev=hn0 -device 
-piix3-usb-uhci,id=usb -device usb-tablet,id=input0 -device usb-mouse,id=input1 
--device usb-kbd,id=input2 -monitor stdio
-
-Adjust the VM's time to host time, and run java application or run the follow 
-program
-in windows 7:
-
-#pragma comment(lib, "winmm")
-#include <stdio.h>
-#include <windows.h>
-
-#define SWITCH_PEROID  13
-
-int main()
-{
-        DWORD count = 0;
-
-        while (1)
-        {
-                count++;
-                timeBeginPeriod(1);
-                DWORD start = timeGetTime();
-                Sleep(40);
-                timeEndPeriod(1);
-                if ((count % SWITCH_PEROID) == 0) {
-                        Sleep(1);
-                }
-        }
-        return 0;
-}
-
-After few minutes, you will find that the time in windows 7 goes ahead of the
-host time, drifts about several seconds.
-
-I have dug deeper in this problem. For windows systems that use the CMOS timer,
-the base interrupt rate is usually 64Hz, but running some application in VM
-will raise the timer rate to 1024Hz, running java application and or above
-program will raise the timer rate.
-Besides, Windows operating systems generally keep time by counting timer
-interrupts (ticks). But QEMU seems not emulate the rate converting fine.
-
-We update the timer in function periodic_timer_update():
-static void periodic_timer_update(RTCState *s, int64_t current_time)
-{
-
-        cur_clock = muldiv64(current_time, RTC_CLOCK_RATE, get_ticks_per_sec());
-        next_irq_clock = (cur_clock & ~(period - 1)) + period;
-                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Here we calculate the next interrupt time by align the current clock with the
-new period, I'm a little confused that why we care about the *history* time ?
-If VM switches from high rate to low rate, the next interrupt time may come
-earlier than it supposed to be. We have observed it in our test. we printed the
-interval time of interrupts and the VM's current time (We got the time from VM).
-
-Here is part of the log:
-... ...
-period=512 irq inject 1534: 15625 us
-Tue Mar 29 04:38:00 2016
-*irq_num_period_32=0, irq_num_period_512=64: [3]: Real time interval is 999696 
-us
-... ...
-*irq_num_period_32=893, irq_num_period_512=9 [81]: Real time interval is 951086 
-us
-Convert 32 --- > 512: 703: 96578 us
-period=512 irq inject 44391: 12702 us
-Convert 512 --- > 32: 704: 12704 us11
-period=32 irq inject 44392: 979 us
-... ...
-32 --- > 512: 705: 24388 us
-period=512 irq inject 44417: 6834 us
-Convert 512 --- > 32: 706: 6830 us
-period=32 irq inject 44418: 978 us
-... ...
-Convert 32 --- > 512: 707: 60525 us
-period=512 irq inject 44480: 1945 us
-Convert 512 --- > 32: 708: 1955 us
-period=32 irq inject 44481: 977 us
-... ...
-Convert 32 --- > 512: 709: 36105 us
-period=512 irq inject 44518: 10741 us
-Convert 512 --- > 32: 710: 10736 us
-period=32 irq inject 44519: 989 us
-... ...
-Convert 32 --- > 512: 711: 123998 us
-period=512 irq inject 44646: 974 us
-period=512 irq inject 44647: 15607 us
-Convert 512 --- > 32: 712: 16560 us
-period=32 irq inject 44648: 980 us
-... ...
-period=32 irq inject 44738: 974 us
-Convert 32 --- > 512: 713: 88828 us
-period=512 irq inject 44739: 4885 us
-Convert 512 --- > 32: 714: 4882 us
-period=32 irq inject 44740: 989 us
-... ...
-period=32 irq inject 44842: 974 us
-Convert 32 --- > 512: 715: 100537 us
-period=512 irq inject 44843: 8788 us
-Convert 512 --- > 32: 716: 8789 us
-period=32 irq inject 44844: 972 us
-... ...
-period=32 irq inject 44941: 979 us
-Convert 32 --- > 512: 717: 95677 us
-period=512 irq inject 44942: 13661 us
-Convert 512 --- > 32: 718: 13657 us
-period=32 irq inject 44943: 987 us
-... ...
-Convert 32 --- > 512: 719: 94690 us
-period=512 irq inject 45040: 14643 us
-Convert 512 --- > 32: 720: 14642 us
-period=32 irq inject 45041: 974 us
-... ...
-Convert 32 --- > 512: 721: 88848 us
-period=512 irq inject 45132: 4892 us
-Convert 512 --- > 32: 722: 4931 us
-period=32 irq inject 45133: 964 us
-... ...
-Tue Mar 29 04:39:19 2016
-*irq_num_period_32:835, irq_num_period_512:11 [82], Real time interval is 
-911520 us
-
-For windows 7, it has got 835 IRQs which injected during the period of 32,
-and got 11 IRQs that injected during the period of 512. it updated the 
-wall-clock
-time with one second, because it supposed it has counted
-(835*976.5+11*15625)= 987252.5 us, but the real interval time is 911520 us.
-
-IMHO, we should calculate the next interrupt time based on the time of last
-interrupt injected, and it seems to be more similar with hardware CMOS timer
-in this way.
-Maybe someone can tell me the reason why we calculated the interrupt timer
-in that way, or is it a bug ? ;)
-
-Thanks,
-Hailiang
-
-ping...
-
-It seems that we can eliminate the drift by the following patch.
-(I tested it for two hours, and there is no drift, before, the timer
-in Windows 7 drifts about 2 seconds per minute.) I'm not sure if it is
-the right way to solve the problem.
-Any comments are welcomed. Thanks.
-
-From bd6acd577cbbc9d92d6376c770219470f184f7de Mon Sep 17 00:00:00 2001
-From: zhanghailiang <address@hidden>
-Date: Thu, 31 Mar 2016 16:36:15 -0400
-Subject: [PATCH] timer/mc146818rtc: fix timer drift in Windows OS while RTC
- rate converting frequently
-
-Signed-off-by: zhanghailiang <address@hidden>
----
- hw/timer/mc146818rtc.c | 25 ++++++++++++++++++++++---
- 1 file changed, 22 insertions(+), 3 deletions(-)
-
-diff --git a/hw/timer/mc146818rtc.c b/hw/timer/mc146818rtc.c
-index 2ac0fd3..e39d2da 100644
---- a/hw/timer/mc146818rtc.c
-+++ b/hw/timer/mc146818rtc.c
-@@ -79,6 +79,7 @@ typedef struct RTCState {
-     /* periodic timer */
-     QEMUTimer *periodic_timer;
-     int64_t next_periodic_time;
-+    uint64_t last_periodic_time;
-     /* update-ended timer */
-     QEMUTimer *update_timer;
-     uint64_t next_alarm_time;
-@@ -152,7 +153,8 @@ static void rtc_coalesced_timer(void *opaque)
- static void periodic_timer_update(RTCState *s, int64_t current_time)
- {
-     int period_code, period;
--    int64_t cur_clock, next_irq_clock;
-+    int64_t cur_clock, next_irq_clock, pre_irq_clock;
-+    bool change = false;
-
-     period_code = s->cmos_data[RTC_REG_A] & 0x0f;
-     if (period_code != 0
-@@ -165,14 +167,28 @@ static void periodic_timer_update(RTCState *s, int64_t 
-current_time)
-         if (period != s->period) {
-             s->irq_coalesced = (s->irq_coalesced * s->period) / period;
-             DPRINTF_C("cmos: coalesced irqs scaled to %d\n", s->irq_coalesced);
-+            if (s->period && period) {
-+                change = true;
-+            }
-         }
-         s->period = period;
- #endif
-         /* compute 32 khz clock */
-         cur_clock =
-             muldiv64(current_time, RTC_CLOCK_RATE, NANOSECONDS_PER_SECOND);
-+        if (change) {
-+            int offset = 0;
-
--        next_irq_clock = (cur_clock & ~(period - 1)) + period;
-+            pre_irq_clock = muldiv64(s->last_periodic_time, RTC_CLOCK_RATE,
-+                                    NANOSECONDS_PER_SECOND);
-+            if ((cur_clock - pre_irq_clock) >  period) {
-+                offset =  (cur_clock - pre_irq_clock) / period;
-+            }
-+            s->irq_coalesced += offset;
-+            next_irq_clock = pre_irq_clock + (offset + 1) * period;
-+        } else {
-+            next_irq_clock = (cur_clock & ~(period - 1)) + period;
-+        }
-         s->next_periodic_time = muldiv64(next_irq_clock, 
-NANOSECONDS_PER_SECOND,
-                                          RTC_CLOCK_RATE) + 1;
-         timer_mod(s->periodic_timer, s->next_periodic_time);
-@@ -187,7 +203,9 @@ static void periodic_timer_update(RTCState *s, int64_t 
-current_time)
- static void rtc_periodic_timer(void *opaque)
- {
-     RTCState *s = opaque;
--
-+    int64_t next_periodic_time;
-+
-+    next_periodic_time = s->next_periodic_time;
-     periodic_timer_update(s, s->next_periodic_time);
-     s->cmos_data[RTC_REG_C] |= REG_C_PF;
-     if (s->cmos_data[RTC_REG_B] & REG_B_PIE) {
-@@ -204,6 +222,7 @@ static void rtc_periodic_timer(void *opaque)
-                 DPRINTF_C("cmos: coalesced irqs increased to %d\n",
-                           s->irq_coalesced);
-             }
-+            s->last_periodic_time = next_periodic_time;
-         } else
- #endif
-         qemu_irq_raise(s->irq);
---
-1.8.3.1
-
-
-On 2016/3/29 19:58, Hailiang Zhang wrote:
-Hi,
-
-We tested with the latest QEMU, and found that time drift obviously (clock fast 
-in guest)
-in Windows 7 64 bits guest in some cases.
-
-It is easily to reproduce, using the follow QEMU command line to start windows 
-7:
-
-# x86_64-softmmu/qemu-system-x86_64 -name win7_64_2U_raw -machine 
-pc-i440fx-2.6,accel=kvm,usb=off -cpu host -m 2048 -realtime mlock=off -smp 
-4,sockets=2,cores=2,threads=1 -rtc base=utc,clock=vm,driftfix=slew -no-hpet 
--global kvm-pit.lost_tick_policy=discard -hda /mnt/nfs/win7_sp1_32_2U_raw -vnc 
-:11 -netdev tap,id=hn0,vhost=off -device rtl8139,id=net-pci0,netdev=hn0 -device 
-piix3-usb-uhci,id=usb -device usb-tablet,id=input0 -device usb-mouse,id=input1 
--device usb-kbd,id=input2 -monitor stdio
-
-Adjust the VM's time to host time, and run java application or run the follow 
-program
-in windows 7:
-
-#pragma comment(lib, "winmm")
-#include <stdio.h>
-#include <windows.h>
-
-#define SWITCH_PEROID  13
-
-int main()
-{
-        DWORD count = 0;
-
-        while (1)
-        {
-                count++;
-                timeBeginPeriod(1);
-                DWORD start = timeGetTime();
-                Sleep(40);
-                timeEndPeriod(1);
-                if ((count % SWITCH_PEROID) == 0) {
-                        Sleep(1);
-                }
-        }
-        return 0;
-}
-
-After few minutes, you will find that the time in windows 7 goes ahead of the
-host time, drifts about several seconds.
-
-I have dug deeper in this problem. For windows systems that use the CMOS timer,
-the base interrupt rate is usually 64Hz, but running some application in VM
-will raise the timer rate to 1024Hz, running java application and or above
-program will raise the timer rate.
-Besides, Windows operating systems generally keep time by counting timer
-interrupts (ticks). But QEMU seems not emulate the rate converting fine.
-
-We update the timer in function periodic_timer_update():
-static void periodic_timer_update(RTCState *s, int64_t current_time)
-{
-
-          cur_clock = muldiv64(current_time, RTC_CLOCK_RATE, 
-get_ticks_per_sec());
-          next_irq_clock = (cur_clock & ~(period - 1)) + period;
-                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Here we calculate the next interrupt time by align the current clock with the
-new period, I'm a little confused that why we care about the *history* time ?
-If VM switches from high rate to low rate, the next interrupt time may come
-earlier than it supposed to be. We have observed it in our test. we printed the
-interval time of interrupts and the VM's current time (We got the time from VM).
-
-Here is part of the log:
-... ...
-period=512 irq inject 1534: 15625 us
-Tue Mar 29 04:38:00 2016
-*irq_num_period_32=0, irq_num_period_512=64: [3]: Real time interval is 999696 
-us
-... ...
-*irq_num_period_32=893, irq_num_period_512=9 [81]: Real time interval is 951086 
-us
-Convert 32 --- > 512: 703: 96578 us
-period=512 irq inject 44391: 12702 us
-Convert 512 --- > 32: 704: 12704 us11
-period=32 irq inject 44392: 979 us
-... ...
-32 --- > 512: 705: 24388 us
-period=512 irq inject 44417: 6834 us
-Convert 512 --- > 32: 706: 6830 us
-period=32 irq inject 44418: 978 us
-... ...
-Convert 32 --- > 512: 707: 60525 us
-period=512 irq inject 44480: 1945 us
-Convert 512 --- > 32: 708: 1955 us
-period=32 irq inject 44481: 977 us
-... ...
-Convert 32 --- > 512: 709: 36105 us
-period=512 irq inject 44518: 10741 us
-Convert 512 --- > 32: 710: 10736 us
-period=32 irq inject 44519: 989 us
-... ...
-Convert 32 --- > 512: 711: 123998 us
-period=512 irq inject 44646: 974 us
-period=512 irq inject 44647: 15607 us
-Convert 512 --- > 32: 712: 16560 us
-period=32 irq inject 44648: 980 us
-... ...
-period=32 irq inject 44738: 974 us
-Convert 32 --- > 512: 713: 88828 us
-period=512 irq inject 44739: 4885 us
-Convert 512 --- > 32: 714: 4882 us
-period=32 irq inject 44740: 989 us
-... ...
-period=32 irq inject 44842: 974 us
-Convert 32 --- > 512: 715: 100537 us
-period=512 irq inject 44843: 8788 us
-Convert 512 --- > 32: 716: 8789 us
-period=32 irq inject 44844: 972 us
-... ...
-period=32 irq inject 44941: 979 us
-Convert 32 --- > 512: 717: 95677 us
-period=512 irq inject 44942: 13661 us
-Convert 512 --- > 32: 718: 13657 us
-period=32 irq inject 44943: 987 us
-... ...
-Convert 32 --- > 512: 719: 94690 us
-period=512 irq inject 45040: 14643 us
-Convert 512 --- > 32: 720: 14642 us
-period=32 irq inject 45041: 974 us
-... ...
-Convert 32 --- > 512: 721: 88848 us
-period=512 irq inject 45132: 4892 us
-Convert 512 --- > 32: 722: 4931 us
-period=32 irq inject 45133: 964 us
-... ...
-Tue Mar 29 04:39:19 2016
-*irq_num_period_32:835, irq_num_period_512:11 [82], Real time interval is 
-911520 us
-
-For windows 7, it has got 835 IRQs which injected during the period of 32,
-and got 11 IRQs that injected during the period of 512. it updated the 
-wall-clock
-time with one second, because it supposed it has counted
-(835*976.5+11*15625)= 987252.5 us, but the real interval time is 911520 us.
-
-IMHO, we should calculate the next interrupt time based on the time of last
-interrupt injected, and it seems to be more similar with hardware CMOS timer
-in this way.
-Maybe someone can tell me the reason why we calculated the interrupt timer
-in that way, or is it a bug ? ;)
-
-Thanks,
-Hailiang
-
diff --git a/results/classifier/012/graphic/55961334 b/results/classifier/012/graphic/55961334
deleted file mode 100644
index aa4de30e..00000000
--- a/results/classifier/012/graphic/55961334
+++ /dev/null
@@ -1,57 +0,0 @@
-graphic: 0.909
-x86: 0.812
-architecture: 0.788
-semantic: 0.775
-files: 0.766
-device: 0.764
-performance: 0.758
-mistranslation: 0.718
-other: 0.715
-vnc: 0.709
-kernel virtual machine: 0.702
-network: 0.697
-PID: 0.683
-socket: 0.636
-debug: 0.604
-arm: 0.601
-boot: 0.569
-permissions: 0.560
-risc-v: 0.488
-register: 0.485
-TCG: 0.429
-assembly: 0.395
-
-[Bug] "-ht" flag ignored under KVM - guest still reports HT
-
-Hi Community,
-We have observed that the 'ht' feature bit cannot be disabled when QEMU runs
-with KVM acceleration.
-qemu-system-x86_64 \
-  --enable-kvm \
-  -machine q35 \
-  -cpu host,-ht \
-  -smp 4 \
-  -m 4G \
-  -drive file=rootfs.img,format=raw \
-  -nographic \
-  -append 'console=ttyS0 root=/dev/sda rw'
-Because '-ht' is specified, the guest should expose no HT capability
-(cpuid.1.edx[28] = 0), and /proc/cpuinfo shouldn't show HT feature, but we still
-saw ht in linux guest when run 'cat /proc/cpuinfo'.
-XiaoYao mentioned that:
-
-It has been the behavior of QEMU since
-
-  commit 400281af34e5ee6aa9f5496b53d8f82c6fef9319
-  Author: Andre Przywara <andre.przywara@amd.com>
-  Date:   Wed Aug 19 15:42:42 2009 +0200
-
-    set CPUID bits to present cores and threads topology
-
-that we cannot remove HT CPUID bit from guest via "-cpu xxx,-ht" if the
-VM has >= 2 vcpus.
-I'd like to know whether there's a plan to address this issue, or if the current
-behaviour is considered acceptable.
-Best regards,
-Ewan.
-
diff --git a/results/classifier/012/graphic/70868267 b/results/classifier/012/graphic/70868267
deleted file mode 100644
index e2952af5..00000000
--- a/results/classifier/012/graphic/70868267
+++ /dev/null
@@ -1,58 +0,0 @@
-graphic: 0.706
-device: 0.643
-semantic: 0.635
-files: 0.552
-mistranslation: 0.537
-register: 0.530
-performance: 0.525
-debug: 0.521
-architecture: 0.433
-PID: 0.420
-socket: 0.418
-network: 0.411
-x86: 0.348
-kernel virtual machine: 0.316
-permissions: 0.265
-risc-v: 0.243
-assembly: 0.240
-other: 0.236
-vnc: 0.227
-boot: 0.197
-arm: 0.189
-TCG: 0.159
-
-[Qemu-devel] [BUG] Failed to compile using gcc7.1
-
-Hi all,
-
-After upgrading gcc from 6.3.1 to 7.1.1, qemu can't be compiled with gcc.
-
-The error is:
-
-------
-  CC      block/blkdebug.o
-block/blkdebug.c: In function 'blkdebug_refresh_filename':
-block/blkdebug.c:693:31: error: '%s' directive output may be truncated
-writing up to 4095 bytes into a region of size 4086
-[-Werror=format-truncation=]
-"blkdebug:%s:%s", s->config_file ?: "",
-                               ^~
-In file included from /usr/include/stdio.h:939:0,
-                 from /home/adam/qemu/include/qemu/osdep.h:68,
-                 from block/blkdebug.c:25:
-/usr/include/bits/stdio2.h:64:10: note: '__builtin___snprintf_chk'
-output 11 or more bytes (assuming 4106) into a destination of size 4096
-return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
-          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-        __bos (__s), __fmt, __va_arg_pack ());
-        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-cc1: all warnings being treated as errors
-make: *** [/home/adam/qemu/rules.mak:69: block/blkdebug.o] Error 1
-------
-
-It seems that gcc 7 is introducing more restrict check for printf.
-If using clang, although there are some extra warning, it can at least
-pass the compile.
-Thanks,
-Qu
-