diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/266 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/2660 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/2661 | 48 | ||||
| -rw-r--r-- | results/classifier/108/other/2662 | 26 | ||||
| -rw-r--r-- | results/classifier/108/other/2664 | 24 | ||||
| -rw-r--r-- | results/classifier/108/other/2665 | 26 | ||||
| -rw-r--r-- | results/classifier/108/other/2666 | 37 | ||||
| -rw-r--r-- | results/classifier/108/other/2669 | 33 |
8 files changed, 226 insertions, 0 deletions
diff --git a/results/classifier/108/other/266 b/results/classifier/108/other/266 new file mode 100644 index 000000000..0059d0f95 --- /dev/null +++ b/results/classifier/108/other/266 @@ -0,0 +1,16 @@ +device: 0.742 +semantic: 0.592 +network: 0.416 +files: 0.382 +permissions: 0.364 +other: 0.357 +graphic: 0.350 +performance: 0.314 +boot: 0.238 +debug: 0.208 +socket: 0.112 +vnc: 0.084 +PID: 0.050 +KVM: 0.032 + +'mtfsf' instruction can clear FI incorrectly diff --git a/results/classifier/108/other/2660 b/results/classifier/108/other/2660 new file mode 100644 index 000000000..3a14284f3 --- /dev/null +++ b/results/classifier/108/other/2660 @@ -0,0 +1,16 @@ +device: 0.612 +network: 0.468 +performance: 0.437 +graphic: 0.329 +debug: 0.311 +semantic: 0.235 +permissions: 0.157 +other: 0.152 +boot: 0.123 +vnc: 0.079 +PID: 0.058 +socket: 0.052 +files: 0.024 +KVM: 0.008 + +EDK2 subhook submodule missing diff --git a/results/classifier/108/other/2661 b/results/classifier/108/other/2661 new file mode 100644 index 000000000..fb76ae47b --- /dev/null +++ b/results/classifier/108/other/2661 @@ -0,0 +1,48 @@ +performance: 0.854 +device: 0.800 +other: 0.796 +PID: 0.775 +graphic: 0.763 +boot: 0.730 +files: 0.711 +debug: 0.657 +network: 0.653 +socket: 0.620 +permissions: 0.601 +semantic: 0.531 +vnc: 0.403 +KVM: 0.104 + +powerpc: MSR_LE implemented incorrectly for processors before PPC970 +Description of problem: +qemu does not emulate MSR_LE correctly for CPUs prior to PPC970. + +The implementation used in this scenario appears to be correct for newer PowerPC CPUs, but not for earlier ones. + +When MSR_LE is enabled on PowerPC G4 and prior CPUs, big endian accesses are performed, with the lower address bits XORed by a constant derived from the size of the access (8-bit: XOR 7, 16-bit: XOR 6, 32-bit: XOR 4, 64-bit and above: no operation). This means that anything loaded in big-endian mode, when byteswapped as 64-bit values, appears in the correct place in little endian mode. + +Any unaligned access is dealt with at the same time. I have not verified exactly what the real hardware does, but the following appears to be correct for 16- and 32-bit accesses (and technically 8-bit accesses too given that all operations but the XOR do nothing in that case): +```c +// sizeof_access is the access size in bytes +size_t temp = ea & (sizeof_access - 1); // get offset of unaligned access +ea &= ~sizeof_access; // align the address +ea ^= (sizeof(uint64_t) - sizeof_access); // perform MSR_LE swizzle +ea -= temp; // correct the address for the unaligned access +``` + +Note that the algorithm can be run again on a swizzled address, which will compute the original non-swizzled address. + +Additionally, GDB memory accesses need to be performed byte-wise using the same algorithm. (there's probably a faster way to do this involving bswap64, though!) + +As for the rest of the system: different chipsets did different things. Some memory controllers (for example those used in early PReP systems) had an endianness swap bit that endianness swapped all of memory and MMIO correctly (given MSR_LE swizzled addresses); later systems with a PCI bus had an endianness swap bit in the PCI host controller (Apple "Bandit", Motorola MPC105/6/7) that endianness swapped PCI address space from the CPU side and provided a correct view of main memory from PCI DMA. + +I'm not sure how to implement any of that, hence testing with mac99, where the PCI host controller is big-endian only (there is a uni-north register to swap PCI endianness, but it isn't implemented in hardware and flipping it does nothing). On such systems, hardware access-related swapping must be handled in software. +Steps to reproduce: +Booting from the correct `nt_arcfw_mac99.iso` will crash on a black screen instead of running the ppcel stage2 bootloader. +Additional information: +The following patch is my implementation. This is my first attempt at QEMU TCG-related code; in some places it may be 'too' safe (running the swizzling algorithm again to revert it in case the EA is used again afterwards), and it also uses the "internal only" `tcg_temp_free_*` functions, to avoid wasting temporary variables. So hopefully some more experienced devs can improve it. + +[msr_le.patch](/uploads/3f829ac58d9943faa0cad7b817569f1d/msr_le.patch) + +The following ISO is the one used for testing. +[nt_arcfw_mac99.iso](/uploads/16aa5406284bab55ada205d6598e399a/nt_arcfw_mac99.iso) diff --git a/results/classifier/108/other/2662 b/results/classifier/108/other/2662 new file mode 100644 index 000000000..68563d4e9 --- /dev/null +++ b/results/classifier/108/other/2662 @@ -0,0 +1,26 @@ +device: 0.692 +semantic: 0.503 +graphic: 0.441 +other: 0.366 +files: 0.324 +network: 0.311 +permissions: 0.208 +socket: 0.173 +boot: 0.155 +vnc: 0.151 +performance: 0.123 +debug: 0.109 +PID: 0.090 +KVM: 0.025 + +powerpc: MSR_ILE bit must not be restored in rfi +Description of problem: +On processors that implement the MSR_ILE bit (that is, G4 and prior), the MSR_ILE bit is not restored by the `rfi` instruction. + +qemu, however, does restore this bit from `srr1`. + +Some ppcel operating systems rely on MSR_ILE not being restored by `rfi`, for example, Windows NT when taking a syscall. +Additional information: +Patch provided: [rfi_msr_ile.patch](/uploads/aa661fc8bcbb47585ff63f8e4ebb38ba/rfi_msr_ile.patch) + +The correct behaviour for G4 and prior is performed for later processors too. Given PPC970 and later have that bit documented as reserved, this should not be a problem. diff --git a/results/classifier/108/other/2664 b/results/classifier/108/other/2664 new file mode 100644 index 000000000..a68d8202b --- /dev/null +++ b/results/classifier/108/other/2664 @@ -0,0 +1,24 @@ +device: 0.811 +graphic: 0.651 +performance: 0.493 +debug: 0.433 +semantic: 0.309 +boot: 0.271 +network: 0.213 +vnc: 0.155 +files: 0.130 +socket: 0.112 +PID: 0.086 +permissions: 0.037 +other: 0.028 +KVM: 0.001 + +Building in Windows MSYS2/Mingw64 fails +Description of problem: + +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/108/other/2665 b/results/classifier/108/other/2665 new file mode 100644 index 000000000..dc774555f --- /dev/null +++ b/results/classifier/108/other/2665 @@ -0,0 +1,26 @@ +device: 0.821 +graphic: 0.749 +boot: 0.642 +semantic: 0.639 +performance: 0.543 +other: 0.498 +vnc: 0.407 +debug: 0.392 +PID: 0.362 +files: 0.341 +socket: 0.309 +network: 0.307 +permissions: 0.231 +KVM: 0.219 + +target/arm: cannot boot when CPU supports SME +Description of problem: +On macOS 15.2 beta, Apple's Hypervisor.framework exposes the SME feat flag to QEMU. As a result, in `arm_cpu_sme_finalize`, `cpu_isar_feature(aa64_sme, cpu)` returns true and the program will always exit with the following: + +``` +qemu-aarch64-softmmu: cannot disable sme4224 +All SME vector lengths are disabled. +With SME enabled, at least one vector length must be enabled. +``` + +This is because `vq_supported` and `vq_init` are both 0 as they are not initialized anywhere. It seems that in the original commit e74c097638d38b46d9c68f11565432034afc0ad0 the only place `cpu->sme_vq.supported` is initialized is with `aarch64_max_initfn` when KVM and HVF are not used as the backend. diff --git a/results/classifier/108/other/2666 b/results/classifier/108/other/2666 new file mode 100644 index 000000000..8111272b1 --- /dev/null +++ b/results/classifier/108/other/2666 @@ -0,0 +1,37 @@ +device: 0.856 +boot: 0.851 +graphic: 0.822 +semantic: 0.712 +performance: 0.580 +socket: 0.407 +vnc: 0.404 +files: 0.380 +PID: 0.345 +permissions: 0.289 +other: 0.255 +debug: 0.235 +network: 0.158 +KVM: 0.062 + +OPENSTEP 4.2 for Intel does not boot from SCSI cd connected to am53c974 +Description of problem: +Get OPENSTEP 4.2 installation media from +https://fsck.technology/software/NeXT/OpenStep%20Installation%20Media/ + +Boot qemu like command line above + +Follow on-screen instruction, do not forgot to "change floppy0 path_to_driver_disk.img" in qemu monitor +Additional information: + + +driver select screen + + + +it boots .. + + + +find a bit too much LUNs and eventually give up after scanning them all + +Note there is 0-sized disk "detected" in there somewhere diff --git a/results/classifier/108/other/2669 b/results/classifier/108/other/2669 new file mode 100644 index 000000000..accf84658 --- /dev/null +++ b/results/classifier/108/other/2669 @@ -0,0 +1,33 @@ +graphic: 0.871 +debug: 0.851 +device: 0.818 +vnc: 0.742 +semantic: 0.726 +performance: 0.683 +boot: 0.676 +permissions: 0.583 +socket: 0.557 +PID: 0.495 +network: 0.494 +KVM: 0.471 +files: 0.434 +other: 0.422 + +CPU Hotplug (Host Model) Causes the Windows VM to BSOD +Description of problem: +The QEMU runs on a host with the Intel(R) Xeon(R) CPU E3-1230 v6 CPU which supports Software Guard Extension (SGX). I start a VM with Windows Server 2019 inside and with `-cpu host,...`. When I attempts to hotplug additional CPU (when the VM is running), the OS issues a bug check 0x3e (`MULTIPROCESSOR_CONFIGURATION_NOT_SUPPORTED`). The problem is that the newly hotplugged CPU is not evaluated as "equivalent enough" compared to the already present CPUs. I did some more digging and reverse engineering and it looks like the CPU being hotplugged has SGX turned off. This seems to be fixed when the VM reboots. + +I tried to disable SGX through `-cpu host,-sgx` which helps (the VM successfully accepts the hotplugged CPU), however, `+sgx` does not help (seems to have no effect on the CPU being hotplugged). + +My goal is to be able to hotplug CPUs even when the host CPU supports SGX. + +I tested with QEMU 8.0.0, 9.1.0, 9.1.1 and 9.1.50 (current master) but with no luck. +Steps to reproduce: +1. Create a simple Windows VM, +2. start the VM, +3. use `qpm-shell` to hotplug a CPU (https://www.qemu.org/docs/master/system/cpu-hotplug.html). + +I can provide you the VM as well but its image (QCOW2) has around 10G in size. + +Best regards +Martin Dráb |