3 files changed, 149 insertions, 0 deletions
diff --git a/results/classifier/108/other/1899 b/results/classifier/108/other/1899
new file mode 100644
index 00000000..bd70fbd3
--- /dev/null
+++ b/results/classifier/108/other/1899
@@ -0,0 +1,56 @@
+graphic: 0.749
+other: 0.604
+device: 0.598
+semantic: 0.571
+performance: 0.570
+boot: 0.508
+PID: 0.503
+socket: 0.422
+network: 0.370
+debug: 0.357
+permissions: 0.351
+vnc: 0.260
+files: 0.213
+KVM: 0.209
+
+AArch64: Wrong SCR_EL3 after turning on secondary cores via PSCI
+Description of problem:
+The system fails to boot when using "direct kernel boot" with EL3 enabled. After the guest OS enables secondary cores via PSCI, those have an incorrectly set up `SCR_EL3`. When the OS then executes an intruction which traps into (QEMU provided fake) EL3, the core ends up in an endless loop of "Undefined Instruction" exceptions.
+
+This is nicely visible with `-serial stdio -append "earlycon=pl011,0x9000000 console=/dev/ttyAMA0" -d int`:
+
+```plaintext
+[    0.173173][    T1] smp: Bringing up secondary CPUs ...
+(...)
+Taking exception 11 [Hypervisor Call] on CPU 0
+...from EL1 to EL2
+...with ESR 0x16/0x5a000000
+...handled as PSCI call
+Taking exception 5 [IRQ] on CPU 0
+...from EL1 to EL1
+...with ESR 0x16/0x5a000000
+...with ELR 0xffffa9ff8b593438
+...to EL1 PC 0xffffa9ff8aa11280 PSTATE 0x3c5
+Exception return from AArch64 EL1 to AArch64 EL1 PC 0xffffa9ff8b593438
+Exception return from AArch64 EL1 to AArch64 EL1 PC 0x41f7832c
+Taking exception 1 [Undefined Instruction] on CPU 1
+...from EL1 to EL3
+...with ESR 0x18/0x62300882
+...with ELR 0xffffa9ff8aa3d0d8
+...to EL3 PC 0x400 PSTATE 0x3cd
+Taking exception 1 [Undefined Instruction] on CPU 1
+...from EL3 to EL3
+...with ESR 0x0/0x2000000
+...with ELR 0x400
+...to EL3 PC 0x200 PSTATE 0x3cd
+(repeats forever, CPU 1 is stuck)
+```
+Steps to reproduce:
+1. `qemu-system-aarch64 -M virt,secure=on -cpu max -smp 1 -kernel linux` works
+2. `qemu-system-aarch64 -M virt,secure=on -cpu max -smp 2 -kernel linux` does not
+Additional information:
+The setup for `SCR_EL3` is done by `do_cpu_reset` in hw/arm/boot.c, but this is only called on full system reset. The PSCI call ends up in `arm_set_cpu_on_async_work` (target/arm/arm-powerctl.c) which calls `cpu_reset`. This clears `SCR_EL3` to the architectural reset value, not the one needed for direct kernel boot.
+
+`arm_set_cpu_on_async_work` has code for `SCR_HCE`, but none of the other flags handled by `do_cpu_reset`. It would probably work after copying all of `do_cpu_reset` into `arm_set_cpu_on_async_work`, but that seems wrong. I prepared a patch which makes `do_cpu_reset` public such that `arm_set_cpu_on_async_work` can call it (works here), but I'm not sure whether that's the right way.
+
+CC @pm215
diff --git a/results/classifier/108/other/1899728 b/results/classifier/108/other/1899728
new file mode 100644
index 00000000..e6623427
--- /dev/null
+++ b/results/classifier/108/other/1899728
@@ -0,0 +1,55 @@
+device: 0.762
+semantic: 0.740
+graphic: 0.706
+PID: 0.663
+performance: 0.662
+other: 0.633
+permissions: 0.627
+network: 0.600
+vnc: 0.573
+debug: 0.481
+socket: 0.465
+files: 0.445
+boot: 0.433
+KVM: 0.393
+
+Qemu-5.1.0 build from source man entry not found
+
+Hello together,
+
+i build qemu-5.1.0 from source on centos 8 withe the following command:
+
+../configure --prefix=/usr --target-list=x86_64-softmmu,x86_64-linux-user
+
+make -j4
+
+make install
+
+The build and the installation finished successfully. But when i try the command
+
+man qemu-system-x86_64
+
+i got the message "No manual entry found". What i do wrong ?
+
+Best regards
+Damian
+
+You probably don't have the necessary dependencies to build the manual pages. Since 5.0 we have required Sphinx to be installed to build the docs (see https://wiki.qemu.org/ChangeLog/5.0#Build_Dependencies).
+
+Pass --enable-docs to configure if you want to force the docs to be built (and then configure will stop with an error if Sphinx or another required tool is missing); otherwise configure will default to "build docs if possible, skip if required tools are missing".
+
+
+There is only one shared man-page for all qemu-system-xxx binaries ... have you tried to simply run "man qemu" ?
+
+Hello together,
+
+build with enable-docs and install the required packages now it works with man qemu. 
+
+Many thanks for you help
+
+Problem resolved :-)
+
+Best regards
+Damian
+
+
diff --git a/results/classifier/108/other/1899733 b/results/classifier/108/other/1899733
new file mode 100644
index 00000000..63ee562c
--- /dev/null
+++ b/results/classifier/108/other/1899733
@@ -0,0 +1,38 @@
+graphic: 0.777
+other: 0.760
+performance: 0.583
+device: 0.537
+semantic: 0.494
+permissions: 0.397
+PID: 0.295
+socket: 0.264
+debug: 0.241
+vnc: 0.226
+files: 0.223
+network: 0.205
+boot: 0.177
+KVM: 0.057
+
+Qemu 5.1.0-1 GPU passthrough - MacOS vm starts only if hdmi is attached
+
+Hi,
+I have a macOS 10.15.7 vm with GPU passthrough (NVIDIA GTX Titan Black), libvirt xml has path to vbios too.
+Qemu 5.1.0-1 with libvirt 6.5.0-2 are installed in manjaro architect 20.1.1 (two kernels tried: 5.4.67 LTS and 5.8.11 stable, no difference).
+I have two monitors, one with hdmi and one with vga inputs.
+Usually the gpu is connected to one monitor with hdmi, the other one with DVI (on gpu)-->vga adapter, so:
+1st monitor: hdmi-->hdmi
+2nd monitor: DVI-->vga adapter-->vga
+
+With this setup, launching "virsh start Catalina" has no problem.
+
+If I detach the hdmi cable from monitor 1, I cannot start qemu anymore: the 2nd monitor turns black, it doesn't seem it has "no-signal", but only a black screen with the power led blinking (usually a window on the monitor floats around with "no signal" displayed when there is no signal to monitor).
+I say "qemu doesn't start" because in /var/log/libvirt/qemu/Catalina.log there's no trace.
+
+Detaching hdmi works with qemu 4.2 and libvirt 5.10, so this could be related to qemu update.
+
+Apologize, I know there aren't much information here, if someone can guide me to test the issue I would be grateful.
+
+Thanks for your attention
+
+Sorry, this is invalid, not related to qemu, the root of the issue is with OVMF_CODE.fd and OVMF_VARS.fd from v. 202005 or v. 202008 stable.
+