diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/118/none/1838 | 31 | ||||
| -rw-r--r-- | results/classifier/118/none/1838228 | 58 | ||||
| -rw-r--r-- | results/classifier/118/none/1838277 | 237 | ||||
| -rw-r--r-- | results/classifier/118/none/1838569 | 128 | ||||
| -rw-r--r-- | results/classifier/118/none/1838658 | 194 |
5 files changed, 648 insertions, 0 deletions
diff --git a/results/classifier/118/none/1838 b/results/classifier/118/none/1838 new file mode 100644 index 00000000..2ac1d427 --- /dev/null +++ b/results/classifier/118/none/1838 @@ -0,0 +1,31 @@ +device: 0.766 +performance: 0.578 +network: 0.341 +graphic: 0.263 +kernel: 0.232 +permissions: 0.232 +semantic: 0.189 +architecture: 0.174 +hypervisor: 0.168 +debug: 0.164 +socket: 0.141 +register: 0.128 +user-level: 0.106 +boot: 0.103 +VMM: 0.092 +peripherals: 0.091 +arm: 0.084 +files: 0.082 +mistranslation: 0.064 +virtual: 0.063 +assembly: 0.040 +vnc: 0.039 +PID: 0.027 +risc-v: 0.026 +TCG: 0.014 +ppc: 0.011 +x86: 0.007 +KVM: 0.005 +i386: 0.001 + +Win9x on qemu 8.0.3 - Impossible to launch a win32 app diff --git a/results/classifier/118/none/1838228 b/results/classifier/118/none/1838228 new file mode 100644 index 00000000..e8903fbb --- /dev/null +++ b/results/classifier/118/none/1838228 @@ -0,0 +1,58 @@ +graphic: 0.561 +mistranslation: 0.424 +performance: 0.405 +semantic: 0.403 +device: 0.400 +virtual: 0.302 +network: 0.288 +user-level: 0.287 +socket: 0.251 +architecture: 0.236 +debug: 0.186 +ppc: 0.161 +register: 0.155 +hypervisor: 0.150 +vnc: 0.124 +permissions: 0.123 +boot: 0.099 +PID: 0.097 +assembly: 0.095 +kernel: 0.087 +files: 0.080 +x86: 0.078 +peripherals: 0.070 +arm: 0.070 +risc-v: 0.061 +i386: 0.059 +VMM: 0.051 +KVM: 0.047 +TCG: 0.046 + +Slirp Broadcast traffic + +Hi all, + +Version: QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-7+build1) + +I'm running some DHCP traffic to a *custom* DHCP server with user-mode networking in QEMU. I'm using port 30067 for the server, so this does not conflict with the built-in DHCP server. + +DHCP broadcasts to and from the server, and I'm observing issues with both sending and receiving packets. + +Firstly, from the VM, a packet sent to IPv4 x.x.x.2:30067 (gateway) makes it to the server, but a packet sent to 255.255.255.255 does not. I'd suspect that Slirp has to support sending to the broadcast IP address? Or is this something I can turn on with a configuration option? (My QEMU version too old?) + +Secondly, the source address in a DHCP IPv4 packet must be 0.0.0.0 (by RFC). That means that any return packet will have 0.0.0.0 swapped in as its destination address. However, that packet doesn't make it into the VM at all. I know that if you deliver this packet to Linux, a raw socket will spit it back out. The packets' destination address should not prevent the packet from being delivered to the right VM, since Slirp (should?) know exactly which VM the session belongs to. (It's a proxy, not a router.) + +WDYT? Did I miss some configuration options or use too old a version? + +Thanks, +Chris + +slirp has been moved to a standalone project, can you report here: +https://gitlab.freedesktop.org/slirp/libslirp/issues + +I don't have an answer off the top of my head, but I would suggest looking/tweaking at the network mask. And for the receive side, debugging from sorecvfrom(). + +Thanks. Opened https://gitlab.freedesktop.org/slirp/libslirp/issues/9. + +The ticket in the libslirp tracker has been closed a year ago, so I think we can close this ticket here, too. + diff --git a/results/classifier/118/none/1838277 b/results/classifier/118/none/1838277 new file mode 100644 index 00000000..86b12fff --- /dev/null +++ b/results/classifier/118/none/1838277 @@ -0,0 +1,237 @@ +user-level: 0.793 +VMM: 0.694 +permissions: 0.669 +risc-v: 0.638 +ppc: 0.629 +boot: 0.609 +TCG: 0.575 +device: 0.565 +peripherals: 0.564 +KVM: 0.557 +mistranslation: 0.550 +arm: 0.544 +register: 0.544 +debug: 0.536 +kernel: 0.535 +vnc: 0.531 +network: 0.525 +files: 0.517 +architecture: 0.513 +semantic: 0.506 +assembly: 0.504 +performance: 0.500 +PID: 0.477 +virtual: 0.453 +hypervisor: 0.442 +graphic: 0.436 +socket: 0.418 +x86: 0.360 +i386: 0.245 + +qemu-system-aarch64: regression in 3.1: breakpoint instructions always routed to EL_D even when current EL is higher + +Affects 3.1.0 (latest stable release) and latest commit (893dc8300c80e3dc32f31e968cf7aa0904da50c3) but did *not* affect 2.11 (qemu from bionic ubuntu LTS). + +With the following code and shell commands: + +test.s: + +.text +mov x0, #0x60000000 +msr vbar_el2, x0 +dsb sy +isb sy + +$ aarch64-none-elf-as test.s -o test.o +$ aarch64-none-elf-objcopy -S -O binary test.o test.bin +$ qemu-system-aarch64 -nographic -machine virt,virtualization=on -cpu cortex-a57 -kernel test.bin -s -S + +vbar_el2 is still 0 after the code, instead of being the expected 0x60000000. (see screenshot). + +This regression doesn't seem to happen for vbar_el1 & virtualization=off. + + + +Err, my bad. The following code does seem to work fine (somehow?), but the bug in my code is currently being caused by a JIT failure in mov sp, x8 (aligned value), causing a crash (with the same version considerations). + +If you can provide a repro case for that I'll have a look... + +Right, so basically I was working on https://github.com/Atmosphere-NX/Atmosphere/tree/hyp/thermosphere (make PLATFORM=qemu qemudbg). This uses Arm Trusted Firmware. + +While gdb now reports $VBAR_EL2 correctly (as opposed to what the title says), I observed the following effects: + +- at least before I fixed a bug in my exception handlers, I needed to add this JIT workaround I found by accident: https://github.com/Atmosphere-NX/Atmosphere/blob/hyp/thermosphere/src/start.s#L62 to get to main. Otherwise mov sp, x8 (with x8 aligned) crashed for no reason. + +- VBAR_EL2 is/was loaded before msr VBAR_EL2, x8 despite data and instruction barriers + +- From 3.1 onwards (or after 2.11): VBAR_EL2 is correctly reported (p $VBAR_EL2 gives $1 = 0x60001000 as exepected, and the read value of PSTATE is 0x3c5) but **QEMU acts as if VBAR_EL2 was 0** depending on crash site (but still reports it correctly when jumping to 0+0x200) (there's a __builtin_trap() call in function main) + +Attached elf and binary & built Arm TF build. Run flags: -nographic -machine virt,secure=on,virtualization=on,gic-version=2 -cpu cortex-a57 -smp 4 -m 1024 -bios bl1.bin -d unimp -semihosting-config enable,target=native -serial mon:stdio + +For me that test binary seems to work (with a QEMU built from upstream git commit 893dc8300c80e3dc32f3) : at least it boots and prints various messages ending with "Hello from Thermosphere!". + + +If you want me to investigate whatever the issue with 'mov sp, x8' crashing is you'll need to provide a binary that demonstrates that problem, not one with a workaround in it. + + +> For me that test binary seems to work (with a QEMU built from upstream git commit 893dc8300c80e3dc32f3) : at least it boots and prints various messages ending with "Hello from Thermosphere!" + +my bad, I wasn't precise enough. Right now, test binary should display a crash dump (=> exceptions.c) following __builtin_trap() but doesn't. + +Here is what happens: + +Expected behavior: code steps into $VBAR_EL2+0x200, $VBAR_EL2 being reported to be its expected value +Actual behavior: code steps into 0+0x200 + +(gdb) disas +Dump of assembler code for function main: + 0x00000000600000e8 <+0>: ldr w1, [x18, #16] + 0x00000000600000ec <+4>: str x30, [sp, #-16]! + 0x00000000600000f0 <+8>: cbnz w1, 0x60000110 <main+40> + 0x00000000600000f4 <+12>: mov w0, #0xc200 // #49664 + 0x00000000600000f8 <+16>: movk w0, #0x1, lsl #16 + 0x00000000600000fc <+20>: bl 0x60000d10 <uartInit> + 0x0000000060000100 <+24>: adrp x0, 0x60001000 <unknown_exception> + 0x0000000060000104 <+28>: add x0, x0, #0x8be + 0x0000000060000108 <+32>: bl 0x60000128 <serialLog> +=> 0x000000006000010c <+36>: brk #0x3e8 + 0x0000000060000110 <+40>: adrp x0, 0x60001000 <unknown_exception> + 0x0000000060000114 <+44>: add x0, x0, #0x8d8 + 0x0000000060000118 <+48>: bl 0x60000128 <serialLog> + 0x000000006000011c <+52>: mov w0, #0x0 // #0 + 0x0000000060000120 <+56>: ldr x30, [sp], #16 + 0x0000000060000124 <+60>: ret +End of assembler dump. +(gdb) stepi +^C +Thread 1 received signal SIGINT, Interrupt. +0x0000000000000200 in ?? () +(gdb) p $VBAR_EL2 +$10 = 0x60001000 + + +For the x20/mov sp, x8 crash, it happens on the previous commit, 511a9d86cd2de93f3a9956d248e54e46a89eabb9 (build attached). + +Workaround, not in the build, is to comment out start.s:45 (but not line 43). This time it goes into my exception handlers even before I set vbar_el2. + +Only one target "core" is on when the code runs. + +Can you please provide clear and exact reproduction instructions and binaries for whatever the bugs you think you're seeing are? Bear in mind that I know nothing at all about your guest binary or how it is supposed to behave, and I am not going to build versions of your binary from source. If I need to look at things via the gdb interface, give exact sequences of gdb commands I need to use to reproduce the behaviour and say what you were expecting the behaviour to be. + + +Sure. + +* For both: extract the archive in the same folder, chmod to it & run + +qemu-system-aarch64 -nographic -machine virt,secure=on,virtualization=on,gic-version=2 -cpu cortex-a57 -smp 2 -m 1024 -bios bl1.bin -d unimp -semihosting-config enable,target=native -serial mon:stdio -s -S + +* In another terminal window, same folder: + +aarch64-none-elf-gdb thermosphere.elf + +* while in GDB: + +target remote :1234 + +This .elf corresponds to bl33.bin which runs in EL2 (the other binary files are Arm Trusted Firmware). + +=================== + +For https://bugs.launchpad.net/qemu/+bug/1838277/+attachment/5279996/+files/example.zip: + +* in GDB: + +b *0x6000010C + +* GDB should report it placed a breakpoint in main.c, line 11 (this is on a brk instruction). Then: + +continue +disas + +* Here you should see => 0x000000006000010c <+36>: brk #0x3e8 + +* Notice VBAR_EL2 has a valid, non-zero value: + +p $VBAR_EL2 + +* gdb reports: $1 = 0x60001000 + +* Step the instruction, the control-C: + +stepi + +__Expected behavior__: qemu should have jumped to 0x60001000+0x200 +__Actual behavior__: qemu jumps to 0+0x200 + + +==================== + +Erratum: there was an issue in example #2, which was a bug on my part. Above regression still stands + +ie. there's x20 being wrongly used in start.s in some places, meaning #8 can be discarded, but this does not explain the vbar_el2 bug (the repro steps for which are above). + +qemu *did* correctly jump to 0x60001200 (synchronous exception from same EL with vbar_el2=0x60001000) in version 2.11, but not anymore. + +s/pstate is 0x3c5/pstate is whatever | 0x3c9, ie. qemu correctly reports the code is executing as EL2h + +Your example_x20_mov_sp_x8 binary performs an illegal-exception-return because it does an eret from EL2 to EL1 without having set HCR_EL2.RW to 1. That means that the CPU will continue execution from the exception-return "link address" in ELR_EL2 (and remain in EL2). That is 0, because we just loaded it from address +0x1938 in the binary, which is all-zeroes. Attempting to execute from 0x0 in EL2 triggers a prefetch abort which is taken to EL2 at entry point 0x60001200 (which is where we expect to enter given that VBAR_EL2 is 0x60001000 and this is a synchronous exception to the current EL). The earlier "mov sp, x8" seems to have executed as expected and the SP at the 'eret' is 0x60002ff0. + +This seems to me to be correct execution of a buggy guest binary. + +Note that if you are trying to debug this via the gdbstub you may be being misled by a bug in our handling of "single step" -- if you single step an instruction and it causes an exception (eg it is a load from a bad address) then instead of stopping execution at the exception-entry-point, we will execute one instruction at the exception-entry-point and then stop after that. So you get back control in gdb one instruction later than you expect. + + +Thanks for your repro instructions of comment #10. Something weird is indeed going on: the -d int logging reports: + +Taking exception 7 [Breakpoint] +...from EL2 to EL1 +...with ESR 0x3c/0xf20003e8 +...with ELR 0x6000010c +...to EL1 PC 0x200 PSTATE 0x3c5 + +but an exception should *never* get taken from a higher to a lower exception level. I will investigate further. + + +As I said, you should have ignored example_x20_mov_sp_x8 totally -- this was a bug on my end, which I fixed. + +What about https://bugs.launchpad.net/qemu/+bug/1838277/+attachment/5279996/+files/example.zip, the steps for which are in #10? This one does not return from exception, and executes a brk instruction in function main. It is supposed to jump to 0x60001200 but doesn't (does on version 2.11). The instruction following the brk is valid (adrp) & the instruction at 0x60001200 is mrs x18, esr_el2. + +Sorry, didn't saw #14 when I was posting #15. + +Thank you again for your patience. + +This bug is specific to our handling of the 'brk' insn (and other debug exceptions within the guest like singlestep or watchpoints or breakpoints) at EL2, so you can work around it for the moment by avoiding using hardcoded brk insns in your EL2 code. + + +To be precise, as I was doing my own investigation, this only happens when *both* the following hold: + +- a breakpoint instruction is executed in EL2 (as you mentionned). +- ELD is EL1. This does **not** happen **if ELD is EL2**, after setting e.g. MDCR_EL2.TDE to 1. + +As mentionned above, it's a regression in implementing "AArch64 Self-hosted Debug, D2.3 Routing debug exceptions". + +I'm not familiar with QEMU's codebase enough & I haven't tested the code below, but I think: + +raise_exception(env, EXCP_BKPT, syndrome, arm_debug_target_el(env)); + +should be replaced with something along the lines of: + +int debug_el = arm_debug_target_el(env); +int current_el = arm_current_el(env); +raise_exception(env, EXCP_BKPT, syndrome, debug_el >= current_el ? debug_el : current_el); + + +Just sent a patch out for review which I think should fix this: +https://<email address hidden>/ + + +Thanks a lot for the patch! + +Just nitpicking here, but commit message and in particular wiki changelog message (in 4.1/Planning) make it seem it was only an EL2 issue. I think it was also affecting EL3 (patch fixes both, anyway). + +The fix for this is now in git and will be in the 4.1.0 release. + + +Fix included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=987a23224218fa3bb + diff --git a/results/classifier/118/none/1838569 b/results/classifier/118/none/1838569 new file mode 100644 index 00000000..33326c48 --- /dev/null +++ b/results/classifier/118/none/1838569 @@ -0,0 +1,128 @@ +KVM: 0.691 +user-level: 0.686 +virtual: 0.674 +VMM: 0.663 +TCG: 0.658 +mistranslation: 0.644 +arm: 0.630 +performance: 0.628 +device: 0.625 +ppc: 0.621 +assembly: 0.604 +graphic: 0.602 +x86: 0.600 +vnc: 0.592 +risc-v: 0.586 +register: 0.583 +permissions: 0.575 +network: 0.570 +boot: 0.564 +peripherals: 0.547 +hypervisor: 0.545 +architecture: 0.539 +files: 0.507 +kernel: 0.504 +semantic: 0.478 +PID: 0.465 +socket: 0.451 +debug: 0.428 +i386: 0.398 + +virtio-balloon change breaks post 4.0 upgrade + +We upgraded the libvirt UCA packages from 3.6 to 4.0 as part of a queens upgrade and noticed that +virtio-ballon is broken when instances live migrate (started with a prior 3.6 version) with: + + +2019-07-24T06:46:49.487109Z qemu-system-x86_64: warning: Unknown firmware file in legacy mode: etc/msr_feature_control +2019-07-24T06:47:22.187749Z qemu-system-x86_64: VQ 2 size 0x80 < last_avail_idx 0xb57 - used_idx 0xb59 +2019-07-24T06:47:22.187768Z qemu-system-x86_64: Failed to load virtio-balloon:virtio +2019-07-24T06:47:22.187771Z qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:05.0/virtio-balloon' +2019-07-24T06:47:22.188194Z qemu-system-x86_64: load of migration failed: Operation not permitted +2019-07-24 06:47:22.430+0000: shutting down, reason=failed + +This seem to be the exact problem as reported by https://lists.gnu.org/archive/html/qemu-devel/2019-07/msg02228.html + +Listed the packages which changed: + +Start-Date: 2019-07-06 06:40:55 +Commandline: /usr/bin/apt-get -y -o Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confold install libvirt-bin python-libvirt qemu qemu-utils qemu-system qemu-system-arm qemu-system-mips qemu-system-ppc qemu-system-sparc qemu-system-x86 qemu-system-misc qemu-block-extra qemu-utils qemu-user qemu-kvm +Install: librdmacm1:amd64 (17.1-1ubuntu0.1~cloud0, automatic), libvirt-daemon-driver-storage-rbd:amd64 (4.0.0-1ubuntu8.10~cloud0, automatic), ipxe-qemu-256k-compat-efi-roms:amd64 (1.0.0+git-20150424.a25a16d-0ubuntu2~cloud0, automatic) +Upgrade: qemu-system-mips:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-system-misc:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-system-ppc:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), python-libvirt:amd64 (3.5.0-1build1~cloud0, 4.0.0-1~cloud0), qemu-system-x86:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), libvirt-clients:amd64 (3.6.0-1ubuntu6.8~cloud0, 4.0.0-1ubuntu8.10~cloud0), qemu-user:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), libvirt-bin:amd64 (3.6.0-1ubuntu6.8~cloud0, 4.0.0-1ubuntu8.10~cloud0), qemu:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-utils:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), libvirt-daemon-system:amd64 (3.6.0-1ubuntu6.8~cloud0, 4.0.0-1ubuntu8.10~cloud0), qemu-system-sparc:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-user-binfmt:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-kvm:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), libvirt0:amd64 (3.6.0-1ubuntu6.8~cloud0, 4.0.0-1ubuntu8.10~cloud0), qemu-system-arm:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-block-extra:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-system-common:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-system:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), libvirt-daemon:amd64 (3.6.0-1ubuntu6.8~cloud0, 4.0.0-1ubuntu8.10~cloud0) +End-Date: 2019-07-06 06:41:08 + +At this point the instances would have to be hard rebooted or stopped/started to fix the issue for future live migration attemps + +Hi Bjoern, + I don't think this is the same bug as the one you reference; that's a config space disagreement, not a virtio queue disagreeement. + +It almost feels like the old 4a1e48becab81020adfb74b22c76a595f2d02a01 stats migration fix; but that went in with 2.8 so shouldn't be a problem going 2.10 to 2.11 + + +In regard to "similar bugs" it sounds more like [1] to me. +Which was around needing [2]. + +But just like the commit David mentioned is in 2.8 this one is in since 2.6 (and backported). + +[1]: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1647389 +[2]: https://git.qemu.org/?p=qemu.git;a=commit;h=4eae2a657d1ff5ada56eb9b4966eae0eff333b0b + +Status changed to 'Confirmed' because the bug affects multiple users. + +With recent release of OpenStack Train this issue reappears... + +Upgrading from Stein to Train will require all VMs to be hard-rebooted to be migrated as a final step because Live Migration fails with: + +Oct 17 10:28:43 h2.1.openstack.r0cket.net libvirtd[1545]: Unable to read from monitor: Connection reset by peer +Oct 17 10:28:43 h2.1.openstack.r0cket.net libvirtd[1545]: internal error: qemu unexpectedly closed the monitor: 2019-10-17T10:28:42.981201Z qemu-system-x86_64: get_pci_config_device: Bad config data: i=0x10 read: a1 device: 1 cmask: ff wmask: c0 w1cmask:0 + 2019-10-17T10:28:42.981250Z qemu-system-x86_64: Failed to load PCIDevice:config + 2019-10-17T10:28:42.981263Z qemu-system-x86_64: Failed to load virtio-balloon:virtio + 2019-10-17T10:28:42.981272Z qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:05.0/virtio-balloon' + 2019-10-17T10:28:42.981391Z qemu-system-x86_64: warning: TSC frequency mismatch between VM (2532609 kHz) and host (2532608 kHz), and TSC scaling unavailable + 2019-10-17T10:28:42.983157Z qemu-system-x86_64: warning: TSC frequency mismatch between VM (2532609 kHz) and host (2532608 kHz), and TSC scaling unavailable + 2019-10-17T10:28:42.983672Z qemu-system-x86_64: load of migration failed: Invalid argument + + +Dnaiel: That's a different problem; 'Bad config data: i=0x10 read: a1 device: 1 cmask: ff wmask: c0 w1cmask:0'; so should probably be a separate bug. + +I'd bet on this being the one fixed by 2bbadb08ce272d65e1f78621002008b07d1e0f03 + +> I'd bet on this being the one fixed by +> 2bbadb08ce272d65e1f78621002008b07d1e0f03 + +But wasn't the breakage this fixes only added in qemu 4.0? +He reports his change is from qemu 2.10 to 2.11. + +Unfortunately 2bbadb08 doesn't have a "fixes" line, maybe Ubuntu has +something backported that makes the Ubuntu 2.11 being affected by it. +I checked the Delta but there was nothing related backported that I +could identify. + +But I agree, that first of all this should be a new bug instead of +reviving the old one here. + + +> I'd bet on this being the one fixed by +> 2bbadb08ce272d65e1f78621002008b07d1e0f03 + +But wasn't the breakage this fixes only added in qemu 4.0? +He reports his change is from qemu 2.10 to 2.11. + +Unfortunately 2bbadb08 doesn't have a "fixes" line, maybe Ubuntu has +something backported that makes the Ubuntu 2.11 being affected by it. +I checked the Delta but there was nothing related backported that I +could identify. + +But I agree, that first of all this should be a new bug instead of +reviving the old one here. + +P.S. this will race as I sent the same via mail :-/, but I need to extend. + +I have now realized that the later report (comment #4) is about Openstack Train which at least on Ubuntu would come with qemu 4.0 - and since 2bbadb08 was released only with 4.1 that would be an open issue. + + +I forked that new discussion into https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1848497 +Please follow there and leave this bug here to the originally reported error signature. + +It seems the fix is comitted with https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1848497. Closing this issue + diff --git a/results/classifier/118/none/1838658 b/results/classifier/118/none/1838658 new file mode 100644 index 00000000..6a472661 --- /dev/null +++ b/results/classifier/118/none/1838658 @@ -0,0 +1,194 @@ +permissions: 0.583 +TCG: 0.577 +boot: 0.576 +peripherals: 0.575 +register: 0.574 +graphic: 0.564 +network: 0.512 +user-level: 0.506 +PID: 0.503 +assembly: 0.473 +debug: 0.447 +risc-v: 0.423 +ppc: 0.421 +semantic: 0.410 +device: 0.406 +hypervisor: 0.406 +architecture: 0.396 +arm: 0.383 +performance: 0.365 +VMM: 0.338 +vnc: 0.337 +socket: 0.328 +x86: 0.326 +virtual: 0.312 +files: 0.308 +mistranslation: 0.292 +KVM: 0.280 +kernel: 0.242 +i386: 0.210 + +qemu 4.0.0 broken by glib update + +In brief, an install CD will successfully boot with qemu 4.0.0 built with glib 2.58.3, but freeze during boot with qemu 4.0.0 built with glib 2.60.0. I tracked it down to glib's GHashTable improvements. qemu is happy with a glib built from +``` + git checkout -f 2.60.4 + git revert --no-edit 86c6f7e2b..3bed8a13b + git revert --no-edit 75f8ec1df9b48b0c3a13a9125f2c7d7c5adf5159 + git revert --no-edit 603fb5958..d3074a748 + git revert --no-edit 0b45ddc55..0600dd322 +``` +When the GHashTable improvements were committed, there was already a preemptive note about any breakage being due to using private implementation details, hence mentioning it here rather than with glib. + +For the full saga, see: http://gnats.netbsd.org/54310 + +Fedora 30 has been shipping glib2 2.60.0 through to 2.60.5 and QEMU in general has been working normally AFAICT. + +From the netbsd bug report it looks like the reproducer was demoed using the sparc emulator - is that the only QEMU arch that is affected ? + +The test image that the netbsd bug points to no longer exists. + +If I pick the image currently available: + + http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/latest/images/NetBSD-9.99.2-sparc.iso + +And launch it in a QEMU built from today's GIT master, on Fedora 30 with glib2 2.60.5, NetBSD successfully boots and launches the installer... + + +$ ~/usr/qemu-git/bin/qemu-system-sparc -drive file=NetBSD-9.99.2-sparc.img,format=raw,media=disk,snapshot=off -cdrom /var/lib/libvirt/images/NetBSD-9.99.2-sparc.iso -boot d -nographic +Configuration device id QEMU version 1 machine id 32 +Probing SBus slot 0 offset 0 +Probing SBus slot 1 offset 0 +Probing SBus slot 2 offset 0 +Probing SBus slot 3 offset 0 +Probing SBus slot 4 offset 0 +Probing SBus slot 5 offset 0 +Invalid FCode start byte +CPUs: 1 x FMI,MB86904 +UUID: 00000000-0000-0000-0000-000000000000 +Welcome to OpenBIOS v1.1 built on Jul 1 2019 17:08 + Type 'help' for detailed information +Trying cdrom:d... +Not a bootable ELF image +Loading a.out image... +Loaded 65536 bytes +entry point is 0x4000 +bootpath: /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2,0:d +switching to new context: +>> NetBSD/sparc Secondary Boot, Revision 1.15 (Thu Aug 1 22:23:16 UTC 2019) +Booting netbsd +3375564+96668=0x34ffe0 +OBP version 3, revision 2.25 (plugin rev 2) +[ 1.0000000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, +[ 1.0000000] 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, +[ 1.0000000] 2018, 2019 The NetBSD Foundation, Inc. All rights reserved. +[ 1.0000000] Copyright (c) 1982, 1986, 1989, 1991, 1993 +[ 1.0000000] The Regents of the University of California. All rights reserved. + +[ 1.0000000] NetBSD 9.99.2 (INSTALL) #0: Thu Aug 1 22:23:16 UTC 2019 +[ 1.0000000] <email address hidden>:/usr/src/sys/arch/sparc/compile/INSTALL +[ 1.0000000] total memory = 111 MB +[ 1.0000000] avail memory = 106 MB +[ 1.0000000] bootpath: /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2,0:d +[ 1.0000000] mainbus0 (root): SUNW,SPARCstation-5: hostid 80123456 +[ 1.0000000] cpu0 at mainbus0: FMI,MB86904 @ 170 MHz, MB86910 or WTL1164/5 FPU +[ 1.0000000] cpu0: 16K instruction (32 b/l), 8K data (16 b/l), 512K external (32 b/l): cache enabled +[ 1.0000000] obio0 at mainbus0 +[ 1.0000000] clock0 at obio0 slot 0 offset 0x200000: mk48t08 +[ 1.0000000] timer0 at obio0 slot 0 offset 0xd00000: delay constant 201, frequency = 2000000 Hz +[ 1.0000050] zs0 at obio0 slot 0 offset 0x100000 level 12 softpri 6 +[ 1.0000050] zstty0 at zs0 channel 0 (console i/o) +[ 1.0000050] zstty1 at zs0 channel 1 +[ 1.0000050] zs1 at obio0 slot 0 offset 0x0 level 12 softpri 6 +[ 1.0000050] zstty2 at zs1 channel 0 +[ 1.0000050] kbd0 at zstty2 +[ 1.0000050] zstty3 at zs1 channel 1 +[ 1.0000050] ms0 at zstty3 +[ 1.0000050] wsmouse0 at ms0 mux 0 +[ 1.0000050] fdc0 at obio0 slot 0 offset 0x400000 level 11 softpri 4: chip 82077 +[ 1.0000050] fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec +[ 1.0000050] auxreg0 at obio0 slot 0 offset 0x900000 +[ 1.0000050] power0 at obio0 slot 0 offset 0x910000 level 2 +[ 1.0000050] slavioconfig at obio0 slot 0 offset 0x800000 not configured +[ 1.0000050] iommu0 at mainbus0 addr 0x10000000: version 0x5/0x0, page-size 4096, range 64MB +[ 1.0000050] sbus0 at iommu0: clock = 21.250 MHz +[ 1.0000050] dma0 at sbus0 slot 5 offset 0x8400000: DMA rev 2 +[ 1.0000050] esp0 at dma0 slot 5 offset 0x8800000 level 4: ESP200, 40MHz, SCSI ID 7 +[ 1.0000050] scsibus0 at esp0: 8 targets, 8 luns per target +[ 1.0000050] ledma0 at sbus0 slot 5 offset 0x8400010: DMA rev 2 +[ 1.0000050] le0 at ledma0 slot 5 offset 0x8c00000 level 6: address 52:54:00:12:34:56 +[ 1.0000050] le0: 8 receive buffers, 2 transmit buffers +[ 1.0000050] tcx0 at sbus0 slot 3 offset 0x800000 level 5 (ipl 9) (8-bit only TCX) +[ 1.0000050] tcx0: SUNW,tcx, 1024 x 768 +[ 1.0000050] tcx0: id 0, rev 0, sense 0 +[ 1.0000050] tcx0: attached to /dev/fb0 +[ 1.0000050] wsdisplay1 at tcx0 kbdmux 1 +[ 1.0000050] SUNW,CS4231 at sbus0 slot 4 offset 0xc000000 level 5 (ipl 9) not configured +[ 1.0000050] power-management at sbus0 slot 4 offset 0xa000000 not configured +[ 1.0000050] scsibus0: waiting 2 seconds for devices to settle... +[ 1.0000050] wskbd0 at kbd0 mux 1 +[ 3.4705415] sd0 at scsibus0 target 0 lun 0: <QEMU, QEMU HARDDISK, 2.5+> disk fixed +[ 3.4805320] sd0: 2048 MB, 4161 cyl, 16 head, 63 sec, 512 bytes/sect x 4194304 sectors +[ 3.4805320] cd0 at scsibus0 target 2 lun 0: <QEMU, QEMU CD-ROM, 2.5+> cdrom removable +[ 4.4805570] kbd0: reset failed +[ 4.5705505] root on md0a dumps on md0b +[ 4.5805965] root file system type: ffs +[ 4.5805965] kern.module.path=/stand/sparc/9.99.2/modules +Welcome to the NetBSD/sparc microroot setup utility. + +We've just completed the first stage of a two-stage procedure to load a +fully functional NetBSD installation environment on your machine. In the +second stage which is to follow now, a set of additional installation +utilities must be load from your NetBSD/sparc installation medium. + +This procedure supports one of the following media: + +1) cdrom +2) tape +3) floppy + +Installation medium to load the additional utilities from: + + +Can you confirm that you can still reproduce the original problem using QEMU git master, and latest NetBSD ISO image. + + +> From the netbsd bug report it looks like the reproducer was demoed +> using the sparc emulator - is that the only QEMU arch that is affected ? + +Only one arch is affected, but it's sparc64, not sparc. + + +> The test image that the netbsd bug points to no longer exists. + +Please try this one instead: + + https://www.gson.org/bugs/qemu/NetBSD-8.99.47-sparc64.iso + +I just verified that this image works for reproducing the bug. + + + +Doh, sorry for my comment earlier where I mistakenly used sparc instead of sparc64. + +I've now tested QEMU git master with that sparc64 ISO and qemu-system-sparc64. + +I still can't reproduce it though - it boots past the disk probing, and into the installer, where it asks for the terminal type. + +So looks like there's some further variable involved beyond just the glib update - perhaps something about the host OS is combining with the glib update to trigger it. + + +> So looks like there's some further variable involved beyond just the +> glib update - perhaps something about the host OS is combining with +> the glib update to trigger it. + +Agreed - I just retested using a Fedora 30 instance on EC2, with +glib2-2.60.1-2.fc30.x86_64, and was also unable to reproduce the +issue there. + + +The linked NetBSD bug report http://gnats.netbsd.org/54310 now has confirmation that this crash was the result of a memory corruption bug in QEMU which happened to manifest with the newer glib version. That bug is fixed in QEMU master in commit ef905eff421c5a06a01 which will be in the 5.2 release, so we can mark this as 'fix committed'. + + +Released with QEMU v5.2.0. + |