diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/1034 | 32 | ||||
| -rw-r--r-- | results/classifier/108/other/1034423 | 369 |
2 files changed, 401 insertions, 0 deletions
diff --git a/results/classifier/108/other/1034 b/results/classifier/108/other/1034 new file mode 100644 index 000000000..2379f9da1 --- /dev/null +++ b/results/classifier/108/other/1034 @@ -0,0 +1,32 @@ +semantic: 0.805 +performance: 0.737 +graphic: 0.658 +device: 0.564 +other: 0.491 +permissions: 0.479 +PID: 0.357 +network: 0.323 +boot: 0.322 +socket: 0.317 +debug: 0.295 +vnc: 0.235 +files: 0.205 +KVM: 0.157 + +Erlang/OTP 25 JIT on AArch64 fails in user mode emulation +Description of problem: +Compiling Erlang/OTP 25 fails with segfault when using user mode (but works in system mode), the Erlang devs have tracked it down in [ErlangForums](https://erlangforums.com/t/otp-25-0-rc3-release-candidate-3-is-released/1317/24) and give this explanation: + +> Thanks, I’ve found a bug in QEMU that explains this. The gist of it is: +> +> Instead of interpreting guest code, QEMU dynamically translates it to the host architecture. When the guest overwrites code for one reason or another, the translation is invalidated and redone if needed. +> +> Our JIT:ed code is mapped in two regions to work in the face of W^X restrictions: one executable but not writable, and one writable but not executable. Both of these regions point to the same physical memory and writes to the writable region are “magically” reflected in the executable one. +> +> I would’ve expected QEMU to honor the IC IVAU / ISB instructions we use to tell the processor that we’ve altered code at a particular address, but for some reason QEMU just ignores them 3 and relies entirely on trapping writes to previously translated code. +> +> In system mode QEMU emulates the MMU and sees that these two regions point at the same memory, and has no problem invalidating the executable region after writing to the writable region. +> +> In user mode it instead calls mprotect(..., PROT_READ) on all code regions it has translated, and invalidates translations in the signal handler. The problem is that we never write to the executable region – just the writable one – so the code doesn’t get invalidated. + +There doesn't seem to a open or closed QEMU bug that actually describes this problem. diff --git a/results/classifier/108/other/1034423 b/results/classifier/108/other/1034423 new file mode 100644 index 000000000..1c1d83de7 --- /dev/null +++ b/results/classifier/108/other/1034423 @@ -0,0 +1,369 @@ +permissions: 0.908 +semantic: 0.905 +graphic: 0.902 +other: 0.893 +network: 0.885 +device: 0.873 +KVM: 0.845 +PID: 0.832 +vnc: 0.825 +socket: 0.822 +boot: 0.816 +debug: 0.809 +performance: 0.788 +files: 0.754 + +Guests running OpenIndiana (and relatives) fail to boot on AMD hardware + +First observed with OpenSolaris 2009.06, and also applies to the latest OpenIndiana release. + +Version: qemu-kvm 1.1.1 + +Hardware: + +2 x AMD Opteron 6128 8-core processors, 64GB RAM. + +These guests boot on equivalent Intel hardware. + +To reproduce: + +qemu-kvm -nodefaults -m 512 -cpu host -vga cirrus -usbdevice tablet -vnc :99 -monitor stdio -hda drive.img -cdrom oi-dev-151a5-live-x86.iso -boot order=dc + +I've tested with "-vga std" and various different emulated CPU types, to no effect. + +What happens: + +GRUB loads, and offers multiple boot options, but none work. Some kind of kernel panic flies by very fast before restarting the VM, and careful use of the screenshot button reveals that it reads as follows: + +panic[cpu0]/thread=fec22de0: BAD TRAP: type=8 (#df Double fault) rp=fec2b48c add r=0 + +#df Double fault +pid=0, pc=0xault +pid=0, pc=0xfe800377, sp=0xfec40090, eflags=0x202 +cr0: 80050011<pg,wp,et,pe> cr4:b8<pge,pae,pse,de> +cr2: 0cr3: ae2f000 + gs: 1b0 fs: 0 es: 160 ds: 160 + edi: 0 esi: 0 ebp: 0 esp: fec2b4c4 + ebx: c0010015 edx: 0 ecx: 0 eax: fec40400 + trp: 8 err: 0 eip: fe800377 cs: 158 + efl: 202 usp: fec40090 ss: 160 +tss.tss_link: 0x0 +tss.tss_esp0: 0x0 +tss.tss_ss0: 0x160 +tss.tss_esp1: 0x0 +tss.tss_ss1: 0x0 +tss.tss esp2: 0x0 +tss.tss_ss2: 0x0 +tss.tss_cr3: 0xae2f000 +tss.tss_eip: 0xfec40400 +tss.tss_eflags: 0x202 +tss.tss_eax: 0xfec40400 +tss.tss_ebx: 0xc0010015 +tss.tss_ecx: 0xc0010000 +tss.tss_edx: 0x0 +tss.tss_esp: 0xfec40090 + +Warning - stack not written to the dumpbuf +fec2b3c8 unix:due+e4 (8, fec2b48c, 0, 0) +fec2b478 unix:trap+12fa (fec2b48c, 0, 0) +fec2b48c unix:_cmntrap+7c (1b0, 0, 160, 160, 0) + +If there's any more, I haven't managed to catch it. + +Solaris 11 does not seem to suffer from the same issue, although the first message that appears at boot (after the version info) is "trap: Unkown trap type 8 in user mode". Could be related? + +As always, thanks in advance and please let me know if I can help to test, or provide any more information. + +Triaging old bug tickets ... can you still reproduce this issue with the latest version of QEMU (currently v2.9)? + +This is an old ticket! I had completely forgotten about it, but will test +when I get a chance and let you know. + +Cheers, + +Owen + +On Fri, May 19, 2017 at 11:25 AM, Thomas Huth <email address hidden> +wrote: + +> Triaging old bug tickets ... can you still reproduce this issue with the +> latest version of QEMU (currently v2.9)? +> +> ** Changed in: qemu +> Status: New => Incomplete +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1034423 +> +> Title: +> Guests running OpenIndiana (and relatives) fail to boot on AMD +> hardware +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> First observed with OpenSolaris 2009.06, and also applies to the +> latest OpenIndiana release. +> +> Version: qemu-kvm 1.1.1 +> +> Hardware: +> +> 2 x AMD Opteron 6128 8-core processors, 64GB RAM. +> +> These guests boot on equivalent Intel hardware. +> +> To reproduce: +> +> qemu-kvm -nodefaults -m 512 -cpu host -vga cirrus -usbdevice tablet +> -vnc :99 -monitor stdio -hda drive.img -cdrom oi-dev- +> 151a5-live-x86.iso -boot order=dc +> +> I've tested with "-vga std" and various different emulated CPU types, +> to no effect. +> +> What happens: +> +> GRUB loads, and offers multiple boot options, but none work. Some kind +> of kernel panic flies by very fast before restarting the VM, and +> careful use of the screenshot button reveals that it reads as follows: +> +> panic[cpu0]/thread=fec22de0: BAD TRAP: type=8 (#df Double fault) +> rp=fec2b48c add r=0 +> +> #df Double fault +> pid=0, pc=0xault +> pid=0, pc=0xfe800377, sp=0xfec40090, eflags=0x202 +> cr0: 80050011<pg,wp,et,pe> cr4:b8<pge,pae,pse,de> +> cr2: 0cr3: ae2f000 +> gs: 1b0 fs: 0 es: +> 160 ds: 160 +> edi: 0 esi: 0 ebp: +> 0 esp: fec2b4c4 +> ebx: c0010015 edx: 0 ecx: 0 eax: +> fec40400 +> trp: 8 err: 0 eip: fe800377 +> cs: 158 +> efl: 202 usp: fec40090 ss: 160 +> tss.tss_link: 0x0 +> tss.tss_esp0: 0x0 +> tss.tss_ss0: 0x160 +> tss.tss_esp1: 0x0 +> tss.tss_ss1: 0x0 +> tss.tss esp2: 0x0 +> tss.tss_ss2: 0x0 +> tss.tss_cr3: 0xae2f000 +> tss.tss_eip: 0xfec40400 +> tss.tss_eflags: 0x202 +> tss.tss_eax: 0xfec40400 +> tss.tss_ebx: 0xc0010015 +> tss.tss_ecx: 0xc0010000 +> tss.tss_edx: 0x0 +> tss.tss_esp: 0xfec40090 +> +> Warning - stack not written to the dumpbuf +> fec2b3c8 unix:due+e4 (8, fec2b48c, 0, 0) +> fec2b478 unix:trap+12fa (fec2b48c, 0, 0) +> fec2b48c unix:_cmntrap+7c (1b0, 0, 160, 160, 0) +> +> If there's any more, I haven't managed to catch it. +> +> Solaris 11 does not seem to suffer from the same issue, although the +> first message that appears at boot (after the version info) is "trap: +> Unkown trap type 8 in user mode". Could be related? +> +> As always, thanks in advance and please let me know if I can help to +> test, or provide any more information. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1034423/+subscriptions +> + + +[Expired for QEMU because there has been no activity for 60 days.] + +Despite the age of the report, I am also reproducing the issue. + +I am using Qemu 6.2.0 with KVM on Linux kernel 6.0.5 under Linux Mint 21. + +The guest is OpenIndiana Hipster 2021.10. + +A guest console capture is attached. + +The guest is managed using libvirt 8.0.0 + +The dump of the libvirt domain configuration is as follows: + +<domain type='kvm' id='62'> + <name>openindiana</name> + <uuid>7a7adcc0-889c-4daf-a73b-21a3fac3d8e7</uuid> + <metadata> + <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0"> + <libosinfo:os id="http://libosinfo.org/linux/2020"/> + </libosinfo:libosinfo> + </metadata> + <memory unit='KiB'>2097152</memory> + <currentMemory unit='KiB'>2097152</currentMemory> + <vcpu placement='static'>4</vcpu> + <resource> + <partition>/machine</partition> + </resource> + <os> + <type arch='x86_64' machine='pc-i440fx-jammy'>hvm</type> + <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE_4M.fd</loader> + <nvram template='/usr/share/OVMF/OVMF_VARS_4M.fd'>/var/lib/libvirt/qemu/nvram/openindiana_VARS.fd</nvram> + </os> + <features> + <acpi/> + <apic/> + <vmport state='off'/> + </features> + <cpu mode='host-passthrough' check='none' migratable='on'/> + <clock offset='utc'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <pm> + <suspend-to-mem enabled='no'/> + <suspend-to-disk enabled='no'/> + </pm> + <devices> + <emulator>/usr/bin/qemu-system-x86_64</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/srv/vhd/openindiana.qcow2' index='2'/> + <backingStore/> + <target dev='sda' bus='sata'/> + <alias name='sata0-0-0'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw'/> + <source file='/srv/img/OI-hipster-minimal-20211031.iso' index='1'/> + <backingStore/> + <target dev='sdb' bus='sata'/> + <readonly/> + <boot order='1'/> + <alias name='sata0-0-1'/> + <address type='drive' controller='0' bus='0' target='0' unit='1'/> + </disk> + <controller type='usb' index='0' model='ich9-ehci1'> + <alias name='usb'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x7'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci1'> + <alias name='usb'/> + <master startport='0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0' multifunction='on'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci2'> + <alias name='usb'/> + <master startport='2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x1'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci3'> + <alias name='usb'/> + <master startport='4'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pci-root'> + <alias name='pci.0'/> + </controller> + <controller type='ide' index='0'> + <alias name='ide'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <controller type='virtio-serial' index='0'> + <alias name='virtio-serial0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> + </controller> + <controller type='sata' index='0'> + <alias name='sata0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> + </controller> + <interface type='network'> + <mac address='52:54:00:20:40:9c'/> + <source network='default' portid='77a38fbb-c35e-4f78-b377-e823963eb30e' bridge='virbr0'/> + <target dev='vnet61'/> + <model type='e1000'/> + <alias name='net0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <serial type='pty'> + <source path='/dev/pts/3'/> + <target type='isa-serial' port='0'> + <model name='isa-serial'/> + </target> + <alias name='serial0'/> + </serial> + <console type='pty' tty='/dev/pts/3'> + <source path='/dev/pts/3'/> + <target type='serial' port='0'/> + <alias name='serial0'/> + </console> + <channel type='spicevmc'> + <target type='virtio' name='com.redhat.spice.0' state='disconnected'/> + <alias name='channel0'/> + <address type='virtio-serial' controller='0' bus='0' port='1'/> + </channel> + <input type='tablet' bus='usb'> + <alias name='input0'/> + <address type='usb' bus='0' port='1'/> + </input> + <input type='mouse' bus='ps2'> + <alias name='input1'/> + </input> + <input type='keyboard' bus='ps2'> + <alias name='input2'/> + </input> + <graphics type='spice'> + <listen type='none'/> + <image compression='off'/> + </graphics> + <sound model='ac97'> + <alias name='sound0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </sound> + <audio id='1' type='spice'/> + <video> + <model type='vga' vram='16384' heads='1' primary='yes'/> + <alias name='video0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <redirdev bus='usb' type='spicevmc'> + <alias name='redir0'/> + <address type='usb' bus='0' port='2'/> + </redirdev> + <redirdev bus='usb' type='spicevmc'> + <alias name='redir1'/> + <address type='usb' bus='0' port='3'/> + </redirdev> + <memballoon model='virtio'> + <alias name='balloon0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> + </memballoon> + </devices> + <seclabel type='dynamic' model='apparmor' relabel='yes'> + <label>libvirt-7a7adcc0-889c-4daf-a73b-21a3fac3d8e7</label> + <imagelabel>libvirt-7a7adcc0-889c-4daf-a73b-21a3fac3d8e7</imagelabel> + </seclabel> + <seclabel type='dynamic' model='dac' relabel='yes'> + <label>+64055:+130</label> + <imagelabel>+64055:+130</imagelabel> + </seclabel> +</domain> + + +This bug tracker here is not used anymore. Could you please open a new ticket here: + +https://gitlab.com/qemu-project/qemu/-/issues + +Thanks! + |