2 files changed, 93 insertions, 0 deletions
diff --git a/results/classifier/108/other/1696 b/results/classifier/108/other/1696
new file mode 100644
index 000000000..89429d933
--- /dev/null
+++ b/results/classifier/108/other/1696
@@ -0,0 +1,54 @@
+boot: 0.708
+performance: 0.676
+device: 0.664
+files: 0.593
+debug: 0.492
+graphic: 0.480
+semantic: 0.428
+PID: 0.343
+vnc: 0.318
+network: 0.315
+socket: 0.296
+other: 0.264
+permissions: 0.216
+KVM: 0.073
+
+Linux kernel hangs rarely when booting on the latest qemu
+Description of problem:
+(Downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=2213346)
+
+In Fedora we have noticed that the latest Linux kernel (rarely) hangs when booting
+on the latest qemu.  It hangs after printing:
+
+```
+[    0.070120] x86/cpu: User Mode Instruction Prevention (UMIP) activated
+[    0.070120] Last level iTLB entries: 4KB 512, 2MB 255, 4MB 127
+[    0.070120] Last level dTLB entries: 4KB 512, 2MB 255, 4MB 127, 1GB 0
+[    0.070120] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
+[    0.070120] Spectre V2 : Mitigation: Retpolines
+[    0.070120] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch
+[    0.070120] Spectre V2 : Spectre v2 / SpectreRSB : Filling RSB on VMEXIT
+[    0.070120] Spectre V2 : Enabling Speculation Barrier for firmware calls
+[    0.070120] RETBleed: Mitigation: untrained return thunk
+[    0.070120] Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier
+[    0.070120] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl
+[    0.070120] Freeing SMP alternatives memory: 48K
+```
+
+The next line which would be printed (if it didn't hang) is:
+
+```
+[    0.070794] smpboot: CPU0: AMD Ryzen 9 3900X 12-Core Processor (family: 0x17, model: 0x71, stepping: 0x0)
+```
+
+We've seen this hang on both AMD and Intel.  It probably happens one in every 300 boots.
+Steps to reproduce:
+By far the easiest way to reproduce this is to just run guestfish in a loop:
+
+```
+$ while guestfish -a /dev/null -v run >& /tmp/log; do echo -n . ; done 
+```
+Additional information:
+The full qemu command is rather long but you can find it in this log file:
+
+https://bugzilla-attachments.redhat.com/attachment.cgi?id=1969620
diff --git a/results/classifier/108/other/1696746 b/results/classifier/108/other/1696746
new file mode 100644
index 000000000..58862fb5f
--- /dev/null
+++ b/results/classifier/108/other/1696746
@@ -0,0 +1,39 @@
+network: 0.803
+socket: 0.698
+device: 0.672
+graphic: 0.648
+semantic: 0.569
+performance: 0.425
+permissions: 0.344
+other: 0.323
+PID: 0.322
+boot: 0.197
+vnc: 0.195
+debug: 0.183
+files: 0.077
+KVM: 0.066
+
+netdev user,restrict=on prevents forwarded ports from being accessed from other systems
+
+I've got a guest only network and I'm wanting to access SSH on one of the guests externally.
+I'm using -netdev user,id=usernet0,hostfwd=tcp::2222-:22,restrict=yes -device virtio-net-pci,netdev=usernet0
+to forward 2222 to 22 in the guest.
+
+The docs state:
+restrict=on|off
+
+    If this option is enabled, the guest will be isolated, i.e. it will not be able to contact the host and no guest IP packets will be routed over the host to the outside. This option does not affect any explicitly set forwarding rules.
+
+
+However, with restrict=on, the forwarded port is only accessible from the host. Other systems receive no data.
+
+This was tested with qemu 2.8. Changelog for 2.9 doesn't mention any (relevant) user networking changes, so that should also fail.
+
+slirp (i.e. user networking) has been moved to a separate project... does this problem still persist with the latest version of QEMU? If so, could you please report it to the libslirp project instead:
+
+https://gitlab.freedesktop.org/slirp/libslirp/-/issues
+
+Thanks!
+
+[Expired for QEMU because there has been no activity for 60 days.]
+