add 18th iteration of classifier

1 files changed, 159 insertions, 0 deletions

diff --git a/results/classifier/118/all/1806824 b/results/classifier/118/all/1806824
new file mode 100644
index 000000000..bfa277737
--- /dev/null
+++ b/results/classifier/118/all/1806824
@@ -0,0 +1,159 @@
+permissions: 0.987
+debug: 0.985
+peripherals: 0.981
+assembly: 0.978
+architecture: 0.977
+semantic: 0.975
+hypervisor: 0.974
+device: 0.973
+virtual: 0.972
+arm: 0.971
+user-level: 0.970
+VMM: 0.969
+register: 0.968
+TCG: 0.966
+PID: 0.965
+performance: 0.964
+kernel: 0.963
+socket: 0.963
+boot: 0.956
+vnc: 0.954
+KVM: 0.952
+risc-v: 0.949
+files: 0.932
+mistranslation: 0.925
+ppc: 0.904
+network: 0.889
+graphic: 0.877
+x86: 0.770
+i386: 0.689
+
+SIE-200 (TrustZone) MPC: BLK_MAX returns an incorrect value
+
+Version: 
+$ qemu-system-arm --version
+QEMU emulator version 3.0.92 (v3.1.0-rc2-31-gd522fba244)
+
+Arm SIE-200 Technical Reference Manual describes that BLK_MAX indicates the maximum value of "block based index register" (BLK_IDX). For example, the value 1 would indicate that BLK_IDX can be 0 or 1. According to my experiments, the AN505 FPGA image apparently follows this behavior.
+
+In the current implementation of QEMU, it appears to indicate the number of possible values for BLK_IDX, i.e., one plus the value it's supposed to return.
+
+As per https://www.qemu.org/contribute/report-a-bug/ could you please provide:
+
+  - the command line you are using
+  - details about the guest you are running (or test case)
+
+
+Command line:
+
+    $ qemu-system-arm -kernel Image.elf -machine mps2-an505 -nographic -d guest_errors -s -semihosting
+
+The guest I'm running is an unreleased program for a research purpose. I'm not aware of any publicly-known application or operating system that make use of the hardware register concerned by this issue.
+
+The attached program is an artificial example that reproduces the issue. The program writes a random value to every LUT block within [0, BLK_MAX]. After that, it examines the content of every LUT block to see if it has the intended value or not.
+
+With the AN505 FPGA image, you get the following output (via UART1, 115200 baud):
+
+    ==== The test program has started ====
+     LUT[0x00000000] = 07345a3f
+     LUT[0x00000001] = 020c7cc6
+    ==== The test program has completed ====
+
+With QEMU, you get the following output because the LUT index 0x00000040 doesn't actually exist and is wrapped around to the first block:
+    
+    $ make qemu
+    qemu-system-arm -kernel Image.elf -machine mps2-an505 -nographic -d guest_errors -s -semihosting
+    ==== The test program has started ====
+     LUT[0x00000000] = 07345a3f
+     LUT[0x00000001] = 020c7cc6
+     ...
+     LUT[0x0000003f] = ce3b657b
+     LUT[0x00000040] = f01ed211
+    [ERROR] Verify failed at 0x00000000 - expected 0x07345a3f, got 0xf01ed211.
+    ==== The test program has completed ====
+
+Thanks for the bug report and the test program. The fix seems straightforward -- just adjust what we return for the register value. I've sent a patch:
+http://patchwork.ozlabs.org/patch/1013034/
+
+
+
+Peter Maydell <email address hidden> writes:
+
+> Thanks for the bug report and the test program. The fix seems straightforward -- just adjust what we return for the register value. I've sent a patch:
+> http://patchwork.ozlabs.org/patch/1013034/
+
+I know you had a bunch of M-profile test cases. Once we get tcg system
+tests enabled would it be worth porting some of those into the QEMU src
+tree?
+
+There is already one other ARM system test pending for the microbit
+tests.
+
+
+>
+>
+> ** Changed in: qemu
+>        Status: New => In Progress
+
+
+--
+Alex Bennée
+
+
+On Fri, 14 Dec 2018 at 13:56, Alex Bennée <email address hidden> wrote:
+>
+>
+> Peter Maydell <email address hidden> writes:
+>
+> > Thanks for the bug report and the test program. The fix seems straightforward -- just adjust what we return for the register value. I've sent a patch:
+> > http://patchwork.ozlabs.org/patch/1013034/
+>
+> I know you had a bunch of M-profile test cases. Once we get tcg system
+> tests enabled would it be worth porting some of those into the QEMU src
+> tree?
+
+I don't have anything suitable -- unless we have
+support for "system test of this guest kernel", in which case
+we could add the arm trusted firmware boot/selftests.
+
+thanks
+-- PMM
+
+
+
+Peter Maydell <email address hidden> writes:
+
+> On Fri, 14 Dec 2018 at 13:56, Alex Bennée <email address hidden> wrote:
+>>
+>>
+>> Peter Maydell <email address hidden> writes:
+>>
+>> > Thanks for the bug report and the test program. The fix seems straightforward -- just adjust what we return for the register value. I've sent a patch:
+>> > http://patchwork.ozlabs.org/patch/1013034/
+>>
+>> I know you had a bunch of M-profile test cases. Once we get tcg system
+>> tests enabled would it be worth porting some of those into the QEMU src
+>> tree?
+>
+> I don't have anything suitable -- unless we have
+> support for "system test of this guest kernel", in which case
+> we could add the arm trusted firmware boot/selftests.
+
+That's the next step, enabling the building of a known good test case
+from an external tree and depositing the images in the right place so we
+can use them as tests.
+
+Things like LTP, kvm-unit-tests and various kernels.
+
+>
+> thanks
+> -- PMM
+
+
+--
+Alex Bennée
+
+
+This is now fixed in git master, in commit 619d54a8d854e797bf562, and will be in the upcoming 4.0 release.
+
+