add 18th iteration of classifier

1 files changed, 103 insertions, 0 deletions

diff --git a/results/classifier/118/permissions/1815721 b/results/classifier/118/permissions/1815721
new file mode 100644
index 000000000..4b321fa3f
--- /dev/null
+++ b/results/classifier/118/permissions/1815721
@@ -0,0 +1,103 @@
+permissions: 0.905
+debug: 0.876
+arm: 0.841
+risc-v: 0.835
+PID: 0.820
+device: 0.812
+performance: 0.803
+user-level: 0.800
+semantic: 0.800
+virtual: 0.799
+vnc: 0.797
+peripherals: 0.779
+graphic: 0.778
+architecture: 0.743
+register: 0.740
+hypervisor: 0.729
+files: 0.724
+network: 0.718
+KVM: 0.708
+VMM: 0.706
+assembly: 0.699
+boot: 0.696
+TCG: 0.674
+socket: 0.668
+mistranslation: 0.664
+ppc: 0.649
+kernel: 0.645
+x86: 0.591
+i386: 0.588
+
+RISC-V PLIC enable interrupt for multicore
+
+Hello all,
+
+There is a bug in Qemu related to the enabling of external interrupts for multicores (Virt machine). 
+
+After correcting Qemu as described in #1815078  (https://bugs.launchpad.net/qemu/+bug/1815078), when we try to enable interrupts for core 1 at address 0x0C00_2080 we don't seem to be able to trigger an external interrupt  (e.g. UART0).
+
+This works perfectly for core 0, but fore core 1 it does not work at all. I assume that given bug #1815078 does not enable any external interrupt then this feature has not been tested. I tried to look at the qemu source code but with no luck so far.
+
+I guess the problem is related to function parse_hart_config (in sfive_plic.c) that initializes incorrectly the plic->addr_config[addrid].hartid, which is later on read in sifive_plic_update. But this is a guess.
+
+Best regards,
+Pharos team
+
+Hi,
+
+After some debugging (and luck), the problem (at least in the Virt board) was that the PLIC code inside QEMU addresses the core x 2 instead of just the core (core=hart). That is why it worked for core 0 (0x2 = 0) but for core 1 it has to address the PLIC memory area for core 2.
+
+For example, the interrupt enable address for core 1 starts at offset 0x002080 (see https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc) but we actually have to change the enable bit for core 2 (at 0x002100) to make to work for core 1.
+
+The same is true for the priority threshold and claim complete registers (we need to multiply the core by 2)
+
+Either the documentation at https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc does not have the correct memory addresses for qemu virt board, or qemu appears to be wrong.
+
+On Tue, Mar 24, 2020 at 4:20 PM RTOS Pharos <email address hidden> wrote:
+>
+> Hi,
+>
+> After some debugging (and luck), the problem (at least in the Virt
+> board) was that the PLIC code inside QEMU addresses the core x 2 instead
+> of just the core (core=hart). That is why it worked for core 0 (0x2 = 0)
+> but for core 1 it has to address the PLIC memory area for core 2.
+>
+> For example, the interrupt enable address for core 1 starts at offset
+> 0x002080 (see https://github.com/riscv/riscv-plic-spec/blob/master
+> /riscv-plic.adoc) but we actually have to change the enable bit for core
+> 2 (at 0x002100) to make to work for core 1.
+
+
+https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc says:
+
+"base + 0x002080: Enable bits for sources 0-31 on context 1"
+
+This is context 1, not core 1.
+
+It looks to me you were running an image built for SiFive FU540.
+Please test your image against "sifive_u" machine instead.
+
+>
+> The same is true for the priority threshold and claim complete registers
+> (we need to multiply the core by 2)
+>
+> Either the documentation at https://github.com/riscv/riscv-plic-
+> spec/blob/master/riscv-plic.adoc does not have the correct memory
+> addresses for qemu virt board, or qemu appears to be wrong.
+>
+> --
+
+Regards,
+Bin
+
+
+Thank you for the explanation. I actually built it for "Virt" machine. I'll try the "sifive_u" when I can. 
+
+But I guess your explanation is correct so this bug could be closed from my part.
+
+Hello as far as I can tell, there is a major problem with PLIC implementation. When decompiling DTB on virt board with X harts, I see that hartid 0 has MEI and SEI, hartid 1 has MEI and SEI, etc... But when configuring context 1 (hartid 0 SEI) no interrupt is generated, but context 0, 2, 4 etc... work. So for me the problem is within PLIC or RISC-V implementation... If anyone wants to correct it, I can help. Best regards. Serge Teodori
+
+I'm going to close this bug as it seems like the issue that RTOS Pharos raised is not an issue.
+
+@Teodori Serge please open a new issue if you have a bug. Make sure to include as much detail as possible and steps to reproduce it.
+