2 files changed, 84 insertions, 0 deletions
diff --git a/results/classifier/108/other/1155 b/results/classifier/108/other/1155
new file mode 100644
index 00000000..fcefa339
--- /dev/null
+++ b/results/classifier/108/other/1155
@@ -0,0 +1,42 @@
+debug: 0.874
+KVM: 0.861
+graphic: 0.794
+device: 0.681
+permissions: 0.630
+performance: 0.399
+semantic: 0.398
+other: 0.388
+vnc: 0.374
+PID: 0.370
+boot: 0.304
+network: 0.277
+socket: 0.243
+files: 0.125
+
+RISC-V: Instruction fetch exceptions can have invalid tval/epc combination
+Description of problem:
+Instruction page fault / guest-page fault / access fault exceptions can have invalid `epc`/`tval` combinations, for example as shown in the debug log:
+
+```
+riscv_cpu_do_interrupt: hart:0, async:0, cause:0000000000000014, epc:0xffffffff802fec76, tval:0xffffffff802ff000, desc=guest_exec_page_fault
+riscv_cpu_do_interrupt: hart:0, async:0, cause:0000000000000014, epc:0xffffffff80243fe6, tval:0xffffffff80244000, desc=guest_exec_page_fault
+```
+
+From the privileged spec:
+
+> If `mtval` is written with a nonzero value when an instruction access-fault or page-fault exception occurs on a system with variable-length instructions, then `mtval` will contain the virtual address of the portion of the instruction that caused the fault, while `mepc` will point to the beginning of the instruction.
+
+Currently RISC-V only has 32-bit and 16-bit instructions, so the difference `tval - epc` should be either `0` or `2`. In the examples above the differences are `906` and `26` respectively.
+
+Possibly notable: all occurrences of these invalid combinations to have `tval` aligned to a page-boundary.
+Steps to reproduce:
+This one only gives invalid `tval`/`epc` combinations with instruction guest-page faults, but I've found it to be the easiest reproducer to describe, since presumably running KVM in RISC-V QEMU is a standard setup. I have not otherwise been able to find a more minimal case.
+
+1. Start a QEMU-based `riscv64` machine
+2. Start a KVM-based virtual machine with QEMU inside it
+3. Do some stuff in the KVM-based virtual machine to increase the chance of page faults
+4. Look in the debug log of the outer QEMU for `guest_exec_page_fault` exceptions with `tval` ending in `000`, but `epc` ending in neither `000` nor `ffe`
+
+Everything in both layers of guests should otherwise work without issue, but other/future software that relies on the spec-mandated relationship of `epc`/`tval` may break.
+Additional information:
+
diff --git a/results/classifier/108/other/1155677 b/results/classifier/108/other/1155677
new file mode 100644
index 00000000..d6a06f38
--- /dev/null
+++ b/results/classifier/108/other/1155677
@@ -0,0 +1,42 @@
+device: 0.816
+graphic: 0.723
+performance: 0.635
+other: 0.621
+semantic: 0.577
+network: 0.576
+debug: 0.508
+PID: 0.455
+boot: 0.428
+permissions: 0.417
+socket: 0.331
+vnc: 0.313
+KVM: 0.087
+files: 0.041
+
+snapshot=on fails with non file-based storage
+
+The snapshot=on option doesn't work with an nbd block device:
+
+/usr/bin/qemu-system-x86_64 \
+[...]
+    -device virtio-scsi-pci,id=scsi \
+    -drive file=nbd:localhost:61930,snapshot=on,format=raw,id=hd0,if=none \
+    -device scsi-hd,drive=hd0 \
+[...]
+
+gives the error:
+
+qemu-system-x86_64: -drive file=nbd:localhost:61930,snapshot=on,format=raw,id=hd0,if=none: could not open disk image nbd:localhost:61930: No such file or directory
+
+If you remove the snapshot=on flag, it works (although that of course means that the block device is writable which we don't want).
+
+Previously reported here:
+
+  http://permalink.gmane.org/gmane.comp.emulators.qemu/148390
+
+and I can confirm this still happens in qemu 1.4.0.
+
+Triaging old bug tickets... I think this has likely been fixed in 2013 ... or can you still reproduce this issue with the latest version of QEMU? Could we close this ticket nowadays?
+
+Let's close this.  libguestfs doesn't use snapshot=on any longer.
+