diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/86 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/860 | 325 | ||||
| -rw-r--r-- | results/classifier/108/other/862 | 64 | ||||
| -rw-r--r-- | results/classifier/108/other/863 | 69 | ||||
| -rw-r--r-- | results/classifier/108/other/864 | 30 | ||||
| -rw-r--r-- | results/classifier/108/other/864490 | 34 | ||||
| -rw-r--r-- | results/classifier/108/other/865 | 60 | ||||
| -rw-r--r-- | results/classifier/108/other/865518 | 102 | ||||
| -rw-r--r-- | results/classifier/108/other/866 | 68 | ||||
| -rw-r--r-- | results/classifier/108/other/867 | 28 | ||||
| -rw-r--r-- | results/classifier/108/other/869 | 36 |
11 files changed, 832 insertions, 0 deletions
diff --git a/results/classifier/108/other/86 b/results/classifier/108/other/86 new file mode 100644 index 00000000..8efe744e --- /dev/null +++ b/results/classifier/108/other/86 @@ -0,0 +1,16 @@ +device: 0.915 +performance: 0.634 +graphic: 0.494 +network: 0.479 +debug: 0.420 +permissions: 0.417 +boot: 0.364 +files: 0.335 +other: 0.315 +semantic: 0.217 +socket: 0.186 +vnc: 0.156 +PID: 0.135 +KVM: 0.042 + +powerpc 7450 MMU initialization broken diff --git a/results/classifier/108/other/860 b/results/classifier/108/other/860 new file mode 100644 index 00000000..184c768e --- /dev/null +++ b/results/classifier/108/other/860 @@ -0,0 +1,325 @@ +graphic: 0.866 +other: 0.865 +device: 0.738 +semantic: 0.738 +permissions: 0.734 +PID: 0.713 +KVM: 0.704 +performance: 0.660 +network: 0.651 +vnc: 0.643 +debug: 0.630 +boot: 0.603 +socket: 0.566 +files: 0.539 + +Not able to launch guests in ppc64le P9 OPAL +Description of problem: +Not able to launch guests in ppc64le P9 OPAL +Steps to reproduce: +1. In a RHEL8 using 4.18.0-305.3.1.el8_4.ppc64le create a Fedora CoreOS VM using kernel-5.15.17-200.fc35.ppc64le. +2. Inside the FCOS vm run: +``` +virt-install --import \ + --name buildvm-ppc64le-fcos01.iad2.fedoraproject.org \ + --memory=32768,maxmemory=32768 \ + --vcpus=16,maxvcpus=16 \ + --feature nested-hv=on \ + --network bridge=br0,model=virtio,mac=RANDOM \ + --autostart \ + --memballoon virtio \ + --watchdog default \ + --rng /dev/random \ + --noautoconsole \ + --disk path=$PWD/fcos-ppc64le-builder.ign,format=raw,readonly=on,serial=ignition \ + --disk bus=virtio,path=/dev/vg_guests/buildvm-ppc64le-fcos01.iad2.fedoraproject.org,cache=unsafe,io=threads +``` + +3. Try to run it again and you will get: + +``` +KVM: Failed to create TCE64 table for liobn 0x71000002 +KVM: Failed to create TCE64 table for liobn 0x80000000 +KVM: unknown exit, hardware reason ffffffffffffffc9 +NIP 0000000000000100 LR 0000000000000000 CTR 0000000000000000 XER 0000000000000000 CPU#0 +MSR 8000000000001000 HID0 0000000000000000 HF 6c000004 iidx 3 didx 3 +TB 00000000 00000000 DECR 0 +GPR00 0000000000000000 0000000000000000 0000000000000000 000000007fe00000 +GPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +CR 00000000 [ - - - - - - - - ] RES ffffffffffffffff + SRR0 0000000000000000 SRR1 0000000000000000 PVR 00000000004e1202 VRSAVE 0000000000000000 +SPRG0 0000000000000000 SPRG1 0000000000000000 SPRG2 0000000000000000 SPRG3 0000000000000000 +SPRG4 0000000000000000 SPRG5 0000000000000000 SPRG6 0000000000000000 SPRG7 0000000000000000 +HSRR0 0000000000000000 HSRR1 0000000000000000 + CFAR 0000000000000000 + LPCR 0000000000560413 + PTCR 0000000000000000 DAR 0000000000000000 DSISR 0000000000000000 +``` +Additional information: +Fedora xml: +``` +<domain type='kvm' id='24'> + <name>buildvm-ppc64le-fcos01.iad2.fedoraproject.org</name> + <uuid>ed30c95e-b7c0-4c25-a6ba-b739459f101b</uuid> + <memory unit='KiB'>33554432</memory> + <currentMemory unit='KiB'>33554432</currentMemory> + <vcpu placement='static'>16</vcpu> + <resource> + <partition>/machine</partition> + </resource> + <os> + <type arch='ppc64le' machine='pseries-rhel8.3.0'>hvm</type> + <boot dev='hd'/> + </os> + <features> + <nested-hv state='on'/> + </features> + <cpu mode='custom' match='exact' check='none'> + <model fallback='forbid'>POWER9</model> + </cpu> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/libexec/qemu-kvm</emulator> + <disk type='block' device='disk'> + <driver name='qemu' type='raw' cache='unsafe' io='threads'/> + <source dev='/dev/vg_guests/buildvm-ppc64le-fcos01.iad2.fedoraproject.org' index='2'/> + <backingStore/> + <target dev='vda' bus='virtio'/> + <alias name='virtio-disk0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='raw'/> + <source file='/tmp/fcos-ppc64le-builder.ign' index='1'/> + <backingStore/> + <target dev='vdb' bus='virtio'/> + <readonly/> + <serial>ignition</serial> + <alias name='virtio-disk1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </disk> + <controller type='usb' index='0' model='qemu-xhci' ports='15'> + <alias name='usb'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </controller> + <controller type='pci' index='0' model='pci-root'> + <model name='spapr-pci-host-bridge'/> + <target index='0'/> + <alias name='pci.0'/> + </controller> + <controller type='virtio-serial' index='0'> + <alias name='virtio-serial0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </controller> + <interface type='bridge'> + <mac address='52:54:00:c4:d2:aa'/> + <source bridge='br0'/> + <target dev='vnet23'/> + <model type='virtio'/> + <alias name='net0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> + </interface> + <serial type='pty'> + <source path='/dev/pts/11'/> + <target type='spapr-vio-serial' port='0'> + <model name='spapr-vty'/> + </target> + <alias name='serial0'/> + <address type='spapr-vio' reg='0x30000000'/> + </serial> + <console type='pty' tty='/dev/pts/11'> + <source path='/dev/pts/11'/> + <target type='serial' port='0'/> + <alias name='serial0'/> + <address type='spapr-vio' reg='0x30000000'/> + </console> + <channel type='unix'> + <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-24-buildvm-ppc64le-fcos/org.qemu.guest_agent.0'/> + <target type='virtio' name='org.qemu.guest_agent.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='keyboard' bus='usb'> + <alias name='input1'/> + <address type='usb' bus='0' port='2'/> + </input> + <graphics type='vnc' port='5910' autoport='yes' listen='127.0.0.1'> + <listen type='address' address='127.0.0.1'/> + </graphics> + <video> + <model type='vga' vram='16384' heads='1' primary='yes'/> + <alias name='video0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> + </video> + <watchdog model='i6300esb' action='reset'> + <alias name='watchdog0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> + </watchdog> + <memballoon model='virtio'> + <alias name='balloon0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> + </memballoon> + <rng model='virtio'> + <backend model='random'>/dev/random</backend> + <alias name='rng0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> + </rng> + <panic model='pseries'/> + </devices> + <seclabel type='dynamic' model='selinux' relabel='yes'> + <label>system_u:system_r:svirt_t:s0:c131,c913</label> + <imagelabel>system_u:object_r:svirt_image_t:s0:c131,c913</imagelabel> + </seclabel> + <seclabel type='dynamic' model='dac' relabel='yes'> + <label>+107:+107</label> + <imagelabel>+107:+107</imagelabel> + </seclabel> +</domain> +``` + +Failure seen in journal when running `virt-ls` + +``` +Feb 04 16:19:39 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: KVMPPC-UVMEM: No support for secure guests +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: vcpu 000000004bd9d345 (0): +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: pc = 0000000000000100 msr = 8000000000001000 trap = ffffffc9 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r 0 = 0000000000000000 r16 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r 1 = 0000000000000000 r17 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r 2 = 0000000000000000 r18 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r 3 = 000000003fe00000 r19 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r 4 = 0000000000000000 r20 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r 5 = 0000000000000000 r21 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r 6 = 0000000000000000 r22 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r 7 = 0000000000000000 r23 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r 8 = 0000000000000000 r24 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r 9 = 0000000000000000 r25 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r10 = 0000000000000000 r26 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r11 = 0000000000000000 r27 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r12 = 0000000000000000 r28 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r13 = 0000000000000000 r29 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r14 = 0000000000000000 r30 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r15 = 0000000000000000 r31 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: ctr = 0000000000000000 lr = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: srr0 = 0000000000000000 srr1 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: sprg0 = 0000000000000000 sprg1 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: sprg2 = 0000000000000000 sprg3 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: cr = 00000000 xer = 0000000000000000 dsisr = 00000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: dar = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: fault dar = 0000000000000000 dsisr = 0c68f000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: SLB (0 entries): +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: lpcr = 0040000000560413 sdr1 = 0000000000000000 last_inst = ffffffff +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: trap=0xffffffc9 | pc=0x100 | msr=0x8000000000001000 +``` +Running via qemu: +``` +qemu-system-ppc64 -m 2048 -machine pseries,accel=kvm,kvm-type=HV -cpu host -nographic -snapshot -drive if=virtio,file=fedora-coreos-35.20220131.dev.0-qemu.ppc64le.qcow2 + +KVM: unknown exit, hardware reason ffffffffffffffc9 +NIP 0000000000000100 LR 0000000000000000 CTR 0000000000000000 XER 0000000000000000 CPU#0 +MSR 8000000000001000 HID0 0000000000000000 HF 6c000004 iidx 3 didx 3 +TB 00000000 00000000 DECR 0 +GPR00 0000000000000000 0000000000000000 0000000000000000 000000007fe00000 +GPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +CR 00000000 [ - - - - - - - - ] RES ffffffffffffffff + SRR0 0000000000000000 SRR1 0000000000000000 PVR 00000000004e1202 VRSAVE 0000000000000000 +SPRG0 0000000000000000 SPRG1 0000000000000000 SPRG2 0000000000000000 SPRG3 0000000000000000 +SPRG4 0000000000000000 SPRG5 0000000000000000 SPRG6 0000000000000000 SPRG7 0000000000000000 +HSRR0 0000000000000000 HSRR1 0000000000000000 + CFAR 0000000000000000 + LPCR 0000000000560413 + PTCR 0000000000000000 DAR 0000000000000000 DSISR 0000000000000000 +``` +libguestfs-test-tool also fails to launch guest + +``` +2022-02-04 18:10:02.355+0000: starting up libvirt version: 7.6.0, package: 5.fc35 (Fedora Project, 2021-12-16-17:58:25, ), qemu version: 6.1.0qemu-6.1.0-10.fc35, kernel: 5.15.17-200.fc35.ppc64le, hostname: buildvm-ppc64le-fcos01.iad2.fedoraproject.org +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +HOME=/var/lib/libvirt/qemu/domain-1-guestfs-9ee177vxogzf \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-1-guestfs-9ee177vxogzf/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-1-guestfs-9ee177vxogzf/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-1-guestfs-9ee177vxogzf/.config \ +TMPDIR=/var/tmp \ +/usr/bin/qemu-system-ppc64 \ +-name guest=guestfs-9ee177vxogzfyj3v,debug-threads=on \ +-S \ +-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-1-guestfs-9ee177vxogzf/master-key.aes"}' \ +-machine pseries-6.1,accel=kvm,usb=off,dump-guest-core=off,memory-backend=ppc_spapr.ram \ +-cpu POWER9 \ +-m 1280 \ +-object '{"qom-type":"memory-backend-ram","id":"ppc_spapr.ram","size":1342177280}' \ +-overcommit mem-lock=off \ +-smp 1,sockets=1,cores=1,threads=1 \ +-uuid 08cd47d3-91e1-4322-aa53-6665a9bc13c8 \ +-display none \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=22,server=on,wait=off \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc,driftfix=slew \ +-no-reboot \ +-boot strict=on \ +-kernel /var/tmp/.guestfs-0/appliance.d/kernel \ +-initrd /var/tmp/.guestfs-0/appliance.d/initrd \ +-append 'panic=1 console=hvc0 console=ttyS0 edd=off udevtimeout=6000 udev.event-timeout=6000 no_timer_check printk.time=1 cgroup_disable=memory usbcore.nousb cryptomgr.notests tsc=reliable 8250.nr_uarts=1 root=UUID=0c185770-d5fc-4a67-acc9-3ea85178bda2 selinux=0 guestfs_verbose=1 TERM=screen' \ +-device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x1 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x2 \ +-blockdev '{"driver":"file","filename":"/tmp/libguestfskYy342/scratch1.img","node-name":"libvirt-2-storage","cache":{"direct":false,"no-flush":true},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-2-format","read-only":false,"cache":{"direct":false,"no-flush":true},"driver":"raw","file":"libvirt-2-storage"}' \ +-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=libvirt-2-format,id=scsi0-0-0-0,bootindex=1,write-cache=on \ +-blockdev '{"driver":"file","filename":"/var/tmp/.guestfs-0/appliance.d/root","node-name":"libvirt-3-storage","cache":{"direct":false,"no-flush":true},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-3-format","read-only":true,"cache":{"direct":false,"no-flush":true},"driver":"raw","file":"libvirt-3-storage"}' \ +-blockdev '{"driver":"file","filename":"/tmp/libguestfskYy342/overlay2.qcow2","node-name":"libvirt-1-storage","cache":{"direct":false,"no-flush":true},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"cache":{"direct":false,"no-flush":true},"driver":"qcow2","file":"libvirt-1-storage","backing":"libvirt-3-format"}' \ +-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=1,lun=0,device_id=drive-scsi0-0-1-0,drive=libvirt-1-format,id=scsi0-0-1-0,write-cache=on \ +-chardev socket,id=charserial0,path=/tmp/libguestfsFFWbf9/console.sock \ +-device spapr-vty,chardev=charserial0,id=serial0,reg=0x30000000 \ +-chardev socket,id=charchannel0,path=/tmp/libguestfsFFWbf9/guestfsd.sock \ +-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.libguestfs.channel.0 \ +-audiodev id=audio1,driver=none \ +-object '{"qom-type":"rng-random","id":"objrng0","filename":"/dev/urandom"}' \ +-device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x3 \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +KVM: unknown exit, hardware reason ffffffffffffffc9 +NIP 0000000000000100 LR 0000000000000000 CTR 0000000000000000 XER 0000000000000000 CPU#0 +MSR 8000000000001000 HID0 0000000000000000 HF 6c000004 iidx 3 didx 3 +TB 00000000 00000000 DECR 0 +GPR00 0000000000000000 0000000000000000 0000000000000000 000000003fe00000 +GPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +CR 00000000 [ - - - - - - - - ] RES ffffffffffffffff + SRR0 0000000000000000 SRR1 0000000000000000 PVR 00000000004e1202 VRSAVE 0000000000000000 +SPRG0 0000000000000000 SPRG1 0000000000000000 SPRG2 0000000000000000 SPRG3 0000000000000000 +SPRG4 0000000000000000 SPRG5 0000000000000000 SPRG6 0000000000000000 SPRG7 0000000000000000 +HSRR0 0000000000000000 HSRR1 0000000000000000 + CFAR 0000000000000000 + LPCR 0000000000560413 + PTCR 0000000000000000 DAR 0000000000000000 DSISR 0000000000000000 +2022-02-04T18:19:47.323915Z qemu-system-ppc64: terminating on signal 15 from pid 1645 (<unknown process>) +2022-02-04 18:19:47.524+0000: shutting down, reason=destroyed +``` diff --git a/results/classifier/108/other/862 b/results/classifier/108/other/862 new file mode 100644 index 00000000..866620ff --- /dev/null +++ b/results/classifier/108/other/862 @@ -0,0 +1,64 @@ +performance: 0.726 +PID: 0.722 +permissions: 0.712 +semantic: 0.672 +graphic: 0.661 +other: 0.661 +boot: 0.649 +files: 0.643 +device: 0.632 +KVM: 0.621 +debug: 0.585 +vnc: 0.576 +network: 0.562 +socket: 0.536 + +Using qemu+kvm is slower than using qemu in rv6(xv6 rust porting) +Description of problem: +Using qemu+kvm is slower than using qemu in rv6(xv6 rust porting) +Steps to reproduce: +``` +git clone https://github.com/kaist-cp/rv6 +cd rv6 +make clean +TARGET=arm GIC_VERSION=3 KVM=yes make qemu +``` +Additional information: +We are currently working on the [rv6 project](https://github.com/kaist-cp/rv6) which is porting MIT's educational operating system [xv6](https://github.com/mit-pdos/xv6-public) to Rust.<br> Our code is located [here](https://github.com/kaist-cp/rv6/tree/main/kernel-rs). +We use qemu and [qemu's virt platform](https://qemu.readthedocs.io/en/latest/system/arm/virt.html) to execute rv6, and it works well with using qemu. +Executing command on arm machine is this: +``` +RUST_MODE=release TARGET=arm KVM=yes GIC_VERSION=3 +qemu-system-aarch64 -machine virt -kernel kernel/kernel -m 128M -smp 80 -nographic -drive file=fs.img,if=none,format=raw,id=x0,copy-on-read=off -device virtio-blk-device,drive=x0,bus=virtio-mmio-bus.0 -cpu cortex-a53 -machine gic-version=3 -net none +``` +To make some speed boost experiment with KVM, we made rv6 support the arm architecture on arm machine. The arm architecture's driver code locates in [here](https://github.com/kaist-cp/rv6/tree/main/kernel-rs/src/arch/arm). +The problem is, when we use qemu with kvm, the performance is significantly reduced. +Executing command on arm machine with KVM is this: +``` +qemu-system-aarch64 -machine virt -kernel kernel/kernel -m 128M -smp 80 -nographic -drive file=fs.img,if=none,format=raw,id=x0,copy-on-read=off -device virtio-blk-device,drive=x0,bus=virtio-mmio-bus.0 -cpu host -enable-kvm -machine gic-version=3 -net none +``` +We repeated +1. Write 500 bytes syscall 10,000 times and the result was: kvm disable: 4,500,000 us, kvm enable: 29,000,000 us. (> 5 times) +2. Open/Close syscall 10,000 times result: kvm disable: 12,000,000 us, kvm enable: 29,000,000 us. (> 5 times) +3. Getppid syscall 10,000 times result: kvm disable: 735,000 us, kvm enable: 825,000 us. (almost same) +4. Simple calculation(a = a * 1664525 + 1013904223) 100 million times result: kvm disable: 2,800,000 us, kvm enable: 65,000,000 us. (> 20 times) + +And the elapsed time was estimated by [uptime_as_micro](https://github.com/kaist-cp/rv6/blob/90b84b60931327ae8635875b788b10280e47b99c/kernel-rs/src/arch/arm/timer.rs#L17) syscall in rv6. +These results were so hard to understand. <br>So first we tried to find the bottleneck on rv6's booting process, because finding bottleneck during processing user program was so difficult. +We found that the first noticeable bottleneck on rv6 booting process was [here](https://github.com/kaist-cp/rv6/blob/main/kernel-rs/src/kalloc.rs#L107-L108): +``` +run.as_mut().init(); +self.runs().push_front(run.as_ref()); +``` +As far as we know, this part is just kind of "list initialization and push element" part. So we thought that by some reason, the KVM is not actually working and it makes worse result. And also this part is even before turn on some interrupts, so we thought [arm's GIC](https://developer.arm.com/documentation/dai0492/b/) or interrupt related thing is not related with problem. + +So, how can I get better performance when using kvm with qemu? + +To solve this problem, we tried these already: +1. change qemu(4.2, 6.2), virt version, change [some command for qemu-kvm](https://linux.die.net/man/1/qemu-kvm) like cpu, drive cache, copy-on-read something, kernel_irqchip.., cpu core.. etc +2. find some kvm hypercall to use - but not exists on arm64 +3. Run [lmbench](http://lmbench.sourceforge.net/) by ubuntu on qemu with kvm to check KVM itself is okay. - We found KVM with ubuntu is super faster than only using qemu. +4. Check [16550a UART print code](https://github.com/kaist-cp/rv6/blob/main/kernel-rs/src/arch/arm/uart.rs) is really slow on enabling KVM which makes incorrect result on benchmark - Without bottleneck code, we found the progress time of rv6 booting were almost same with KVM enabled or not. +5. Check other people who suffer same situation like us - but [this superuser page](https://superuser.com/questions/1317948/qemu-enable-kvm-slower-than-pure-emulation-for-x86-64) not works. Our clocksource is arch_sys_counter. + +Thank you for your help. diff --git a/results/classifier/108/other/863 b/results/classifier/108/other/863 new file mode 100644 index 00000000..b94d5925 --- /dev/null +++ b/results/classifier/108/other/863 @@ -0,0 +1,69 @@ +graphic: 0.773 +other: 0.744 +permissions: 0.687 +semantic: 0.686 +PID: 0.674 +performance: 0.615 +device: 0.573 +debug: 0.523 +vnc: 0.481 +boot: 0.413 +socket: 0.389 +files: 0.368 +network: 0.320 +KVM: 0.238 + +contrib/plugins/howvec.c for ARM64 under constrained +Description of problem: +Consider the static InsnClassExecCount aarch64_insn_classes array in contrib/plugins/howvec.c There are 5 entries which will never be discovered, and so count as 0; see the dump below. + +I did not figure out which of prior rows in the table was over-eagerly getting instructions intended for the subsequent counted-as-0 row. + +``` + udef aka UDEF 65536 + sve aka SVE 268435456 + res aka Reserved 268369920 + pcrel aka PCrel addr 134217728 + asit aka Add/Sub (imm,tags) 67108864 + asi aka Add/Sub (imm) 67108864 + logi aka Logical (imm) 67108864 + movwi aka Move Wide (imm) 67108864 + bitf aka Bitfield 67108864 + extr aka Extract 67108864 + dpri aka Data Proc Imm 0 + cndb aka Cond Branch (imm) 33554432 + excp aka Exception Gen 16777216 + nop aka NOP 1 + hint aka Hints 4095 + barr aka Barriers 4096 + psta aka PSTATE 32768 + sins aka System Insn 1048576 + sreg aka System Reg 2097152 + breg aka Branch (reg) 33554432 + bimm aka Branch (imm) 134217728 + cmpb aka Cmp & Branch 67108864 + tstb aka Tst & Branch 67108864 + branch aka Branches 181362688 + advlsm aka AdvSimd ldstmult 262144 + advlsmp aka AdvSimd ldstmult++ 4194304 + advlss aka AdvSimd ldst 524288 + advlssp aka AdvSimd ldst++ 16777216 + ldstx aka ldst excl 67108864 + prfm aka Prefetch 16777216 + ldlit aka Load Reg (lit) 251658240 + ldstnap aka ldst noalloc pair 67108864 + ldstp aka ldst pair 469762048 + ldstr aka ldst reg 0 + atomic aka Atomic ldst 0 + ldstro aka ldst reg (reg off) 0 + ldstpa aka ldst reg (pac) 0 + ldsti aka ldst reg (imm) 134217728 + ldst aka Loads & Stores 313786368 + dprr aka Data Proc Reg 402653184 + fpsimd aka Scalar FP 402653183 + unclas aka Unclassified 536870912 +``` +Steps to reproduce: +1. Write a simple wrapper program; iterate and search through all 2**32 insns, dump the array +2. +3. diff --git a/results/classifier/108/other/864 b/results/classifier/108/other/864 new file mode 100644 index 00000000..333fb4c1 --- /dev/null +++ b/results/classifier/108/other/864 @@ -0,0 +1,30 @@ +performance: 0.910 +device: 0.840 +graphic: 0.777 +semantic: 0.754 +network: 0.459 +debug: 0.448 +permissions: 0.361 +vnc: 0.346 +other: 0.275 +PID: 0.273 +socket: 0.257 +boot: 0.218 +files: 0.193 +KVM: 0.056 + +HVF virtual counter diverges from CLOCK_VIRTUAL when the host sleeps +Description of problem: +HVF's virtual counter diverges from `CLOCK_VIRTUAL` when the host sleeps and causes the inconsistency between Linux's system counter and everything else. + +HVF's virtual counter apparently relies on something similar to `mach_absolute_time`, which stops when the host sleeps and resumes after it wakes up. However, `CLOCK_VIRTUAL` is implemented with `mach_continuous_time`, which continues even while the host sleeps. Linux uses the virtual counter as the source of the system counter and sees inconsistencies between the system counter and the other devices. +Steps to reproduce: +1. Launch Fedora. +2. Compare the time shown at the top of the guest display and one at the top of the host display. The difference should be less than 2 minutes. +3. Let the host sleep for 3 minutes. +4. Compare the times again. The difference is now greater than 2 minutes. +Additional information: +Here are solutions I've came up with so far. There are trade-offs but any of them should be better than the current situation. I'm happy to implement one if the maintainers have decided which one is the best or figure out a superior alternative. +- Implement `cpus_get_virtual_clock` of `AccelOpsClass` with `mach_absolute_time`. It would make HVF inconsistent with the other accelerators. Linux also expects the virtual clock is "continuous" and it leaves the divergence from the real time. +- Request XNU `HOST_NOTIFY_CALENDAR_CHANGE` to update the virtual clock with the continuous time. The interface is undocumented. +- Use `IORegisterForSystemPower` to update the virtual clock with the continuous time. It is undocumented that the interface handles every cases where `mach_absolute_time` and `mach_continuous_time`, but it actually does if I read XNU's source code correctly. diff --git a/results/classifier/108/other/864490 b/results/classifier/108/other/864490 new file mode 100644 index 00000000..64c10b51 --- /dev/null +++ b/results/classifier/108/other/864490 @@ -0,0 +1,34 @@ +device: 0.802 +other: 0.786 +graphic: 0.755 +performance: 0.708 +semantic: 0.614 +permissions: 0.593 +PID: 0.568 +socket: 0.557 +debug: 0.554 +files: 0.544 +boot: 0.531 +vnc: 0.510 +network: 0.472 +KVM: 0.277 + +Windows 2008 x64 (SBS Server) freezes randomly when using more than 1 CPU core + +This issue has been giving headache to us since a long time. +Difficult to reproduce as it happens randomly. +We had this issue when we ran Windows 2008 x64 or Windows SBS Server guests in either XEN 3.3 or Proxmox environments. +When only one CPU core is assigned to the guest, everything is fine. If 2 or more cores are assigned, the guest stops responding after several hours - and in the host machine one of the cores is using 100%. The only thing that helps is resetting the guest. + +I am ready to provide logs/crashdumps if needed, because we want to help resolve this issue. I saw some posts on the web of people having the same problems - for some of the workaround was to fix some BIOS settings, but we did not have success with those (e.g. disabling C1E Support and Intel C-State ) + +Server is running on Intel® Core™ i7-920 Quad-Core, 24 Gig RAM. + +Hi, + +Is this bug tracker active or I posted to the wrong place? + +thx + +Since nobody replied here within the last years: I think you should rather report problems with XEN / Proxmox to the XEN or Proxmox bugtracker instead. + diff --git a/results/classifier/108/other/865 b/results/classifier/108/other/865 new file mode 100644 index 00000000..af47ce64 --- /dev/null +++ b/results/classifier/108/other/865 @@ -0,0 +1,60 @@ +graphic: 0.915 +semantic: 0.901 +other: 0.900 +permissions: 0.893 +debug: 0.870 +performance: 0.865 +device: 0.846 +PID: 0.810 +vnc: 0.807 +KVM: 0.679 +socket: 0.679 +boot: 0.669 +network: 0.634 +files: 0.569 + +virtio-vga gtk,gl=on Black Screen or GLXGears picture +Description of problem: +Blank screen for tab with name `virtio-vga` on GTK interface, however, if I run `glxgears` before running the machine, I see the following image: + + +Steps to reproduce: +1.Run the invocation command provided above + +# +Additional information: +The host when the problem is occurring is a Dell Precision 5110 laptop that have Hybrid Graphics. I am running X11 with nvidia as the main driver, I am not using nouveau, I am using the nvidia drivers installed by the debian package, here the corresponding information for the nvida card: + +``` +nvidia-smi +``` +``` +Thu Feb 10 23:32:21 2022 ++-----------------------------------------------------------------------------+ +| NVIDIA-SMI 460.91.03 Driver Version: 460.91.03 CUDA Version: 11.2 | +|-------------------------------+----------------------+----------------------+ +| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | +| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | +| | | MIG M. | +|===============================+======================+======================| +| 0 Quadro M1000M On | 00000000:01:00.0 Off | N/A | +| N/A 44C P8 N/A / N/A | 846MiB / 2004MiB | 6% Default | +| | | N/A | ++-------------------------------+----------------------+----------------------+ + ++-----------------------------------------------------------------------------+ +| Processes: | +| GPU GI CI PID Type Process name GPU Memory | +| ID ID Usage | +|=============================================================================| +| 0 N/A N/A 6926 G /usr/lib/xorg/Xorg 528MiB | +| 0 N/A N/A 7223 G ...b/firefox-esr/firefox-esr 238MiB | +| 0 N/A N/A 7363 G ...b/firefox-esr/firefox-esr 0MiB | +| 0 N/A N/A 276992 G ...b/firefox-esr/firefox-esr 0MiB | +| 0 N/A N/A 282023 G ...b/firefox-esr/firefox-esr 0MiB | +| 0 N/A N/A 282630 G ...b/firefox-esr/firefox-esr 0MiB | +| 0 N/A N/A 322305 G qemu-system-x86_64 70MiB | ++-----------------------------------------------------------------------------+ +``` + +## diff --git a/results/classifier/108/other/865518 b/results/classifier/108/other/865518 new file mode 100644 index 00000000..9e9ad090 --- /dev/null +++ b/results/classifier/108/other/865518 @@ -0,0 +1,102 @@ +graphic: 0.742 +other: 0.693 +permissions: 0.690 +debug: 0.672 +semantic: 0.671 +performance: 0.664 +device: 0.650 +files: 0.635 +PID: 0.593 +KVM: 0.589 +socket: 0.575 +network: 0.572 +boot: 0.566 +vnc: 0.549 + +qemu segfaults when writing to very large qcow2 disk + +Create a ridiculously large qcow2 disk: + +qemu-img create -f qcow2 test1.img $((2**63-513)) + +Attach it to a guest and try to use parted to partition it. This is easy with virt-rescue: you just do: + +virt-rescue test1.img +><rescue> parted /dev/vda mklabel gpt +<-- bang! qemu segfaults here + +The stack trace is: + +Program received signal SIGSEGV, Segmentation fault. +0x0000000000434cac in get_cluster_table (bs=0x3193030, offset= + 9223372036854764544, new_l2_table=0x591e3c8, new_l2_offset=0x591e3c0, + new_l2_index=0x591e408) at block/qcow2-cluster.c:506 +506 l2_offset = s->l1_table[l1_index]; +(gdb) bt +#0 0x0000000000434cac in get_cluster_table (bs=0x3193030, offset= + 9223372036854764544, new_l2_table=0x591e3c8, new_l2_offset=0x591e3c0, + new_l2_index=0x591e408) at block/qcow2-cluster.c:506 +#1 0x000000000043535b in qcow2_alloc_cluster_offset (bs=0x3193030, offset= + 9223372036854764544, n_start=106, n_end=126, num=0x591e4e8, m=0x591e470) + at block/qcow2-cluster.c:719 +#2 0x000000000043b8d4 in qcow2_co_writev (bs=0x3193030, sector_num= + 18014398509481962, remaining_sectors=20, qiov=0x4a81ee0) + at block/qcow2.c:554 +#3 0x0000000000428691 in bdrv_co_rw (opaque=0x38bad10) at block.c:2781 +#4 0x000000000046e03a in coroutine_trampoline (i0=59487248, i1=0) + at coroutine-ucontext.c:125 +#5 0x00000034dc6471b0 in ?? () from /lib64/libc.so.6 +#6 0x00007fff76cbb430 in ?? () +#7 0x0000000000000000 in ?? () + +This is qemu from git (8f440cda08c6df574 from 2011-09-29) + +Still happening in upstream qemu from git: + +Program terminated with signal 11, Segmentation fault. +#0 0x00007f4f86c721a0 in get_cluster_table (bs=bs@entry=0x7f4f886e7880, + offset=offset@entry=1152921504606834688, + new_l2_table=new_l2_table@entry=0x7f4f8ad9a0b0, + new_l2_index=new_l2_index@entry=0x7f4f8ad9a0ac) + at block/qcow2-cluster.c:525 +525 l2_offset = s->l1_table[l1_index] & L1E_OFFSET_MASK; +Missing separate debuginfos, use: debuginfo-install SDL-1.2.15-3.fc18.x86_64 bluez-libs-4.101-6.fc18.x86_64 brlapi-0.5.6-12.fc18.x86_64 celt051-0.5.1.3-5.fc18.x86_64 ceph-devel-0.56.3-1.fc18.x86_64 ceph-libs-0.56.3-1.fc18.x86_64 cryptopp-5.6.1-8.fc18.x86_64 cyrus-sasl-lib-2.1.25-2.fc18.x86_64 leveldb-1.7.0-4.fc18.x86_64 libfdt-1.3.0-5.fc18.x86_64 libseccomp-1.0.1-0.fc18.x86_64 libselinux-2.1.12-7.3.fc18.x86_64 libusbx-1.0.14-1.fc18.x86_64 snappy-1.0.5-2.fc18.x86_64 spice-server-0.12.2-3.fc18.x86_64 usbredir-0.6-1.fc18.x86_64 xen-libs-4.2.1-9.fc18.x86_64 +(gdb) bt +#0 0x00007f4f86c721a0 in get_cluster_table (bs=bs@entry=0x7f4f886e7880, + offset=offset@entry=1152921504606834688, new_l2_table=new_l2_table@entry= + 0x7f4f8ad9a0b0, new_l2_index=new_l2_index@entry=0x7f4f8ad9a0ac) + at block/qcow2-cluster.c:525 +#1 0x00007f4f86c72fa3 in handle_copied (m=<optimized out>, + bytes=<synthetic pointer>, host_offset=<synthetic pointer>, guest_offset= + 1152921504606834688, bs=0x7f4f886e7880) at block/qcow2-cluster.c:873 +#2 qcow2_alloc_cluster_offset (bs=bs@entry=0x7f4f886e7880, + offset=<optimized out>, offset@entry=1152921504606834688, + n_start=n_start@entry=104, n_end=<optimized out>, num=num@entry= + 0x7f4f8ad9a14c, host_offset=host_offset@entry=0x7f4f8ad9a150, m=m@entry= + 0x7f4f8ad9a158) at block/qcow2-cluster.c:1217 +#3 0x00007f4f86c773b3 in qcow2_co_writev (bs=0x7f4f886e7880, sector_num= + 2251799813685224, remaining_sectors=24, qiov=0x7f4f88d88f98) + at block/qcow2.c:819 +#4 0x00007f4f86c638d5 in bdrv_co_do_writev (bs=0x7f4f886e7880, sector_num= + 2251799813685224, nb_sectors=24, qiov=0x7f4f88d88f98, flags=flags@entry= + (unknown: 0)) at block.c:2625 +#5 0x00007f4f86c63a38 in bdrv_co_do_rw (opaque=0x7f4f88e16160) at block.c:4139 +#6 0x00007f4f86c9a19a in coroutine_trampoline (i0=<optimized out>, + i1=<optimized out>) at coroutine-ucontext.c:118 +#7 0x00007f4f7fd776c0 in ?? () from /lib64/libc.so.6 +#8 0x00007fff125e6620 in ?? () +#9 0x0000000000000000 in ?? () + + +Simple reproducer using only qemu tools: + +$ qemu-img create -f qcow2 huge.qcow2 $((1024*1024))T +Formatting 'huge.qcow2', fmt=qcow2 size=1152921504606846976 encryption=off cluster_size=65536 lazy_refcounts=off +$ qemu-io /tmp/huge.qcow2 -c "write $((1024*1024*1024*1024*1024*1024 - 1024)) 512" +Segmentation fault + + +Fix has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=2cf7cfa1cde6672b8a35b +... so I think it should be OK to close this ticket now. + diff --git a/results/classifier/108/other/866 b/results/classifier/108/other/866 new file mode 100644 index 00000000..2109f5d8 --- /dev/null +++ b/results/classifier/108/other/866 @@ -0,0 +1,68 @@ +debug: 0.903 +graphic: 0.880 +permissions: 0.831 +semantic: 0.819 +network: 0.819 +vnc: 0.777 +device: 0.772 +performance: 0.768 +PID: 0.752 +files: 0.749 +socket: 0.738 +KVM: 0.722 +boot: 0.700 +other: 0.513 + +linux-user: substantial memory leak when threads are created and destroyed +Description of problem: +Substantial memory leak when the following simple program is executed on `qemu-arm`, +```c +// compile with `arm-none-linux-gnueabihf-gcc test_qemu.c -o test_qemu.out -pthread` + +#include <assert.h> +#include <pthread.h> + +#define MAGIC_RETURN ((void *)42) + +void *thread_main(void *arg) +{ + return MAGIC_RETURN; +} + +int main(int argc, char *argv[]) +{ + size_t i; + for (i = 0;; i++) + { + pthread_t thread; + assert(pthread_create(&thread, NULL, thread_main, NULL) == 0); + void *ret; + assert(pthread_join(thread, &ret) == 0); + assert(ret == MAGIC_RETURN); + } + + return 0; +} +``` +Steps to reproduce: +1. +``` +export TOOLCHAIN_PREFIX=arm-none-linux-gnueabihf +export ARMSDK=/${TOOLCHAIN_PREFIX} +export SYSROOT=${ARMSDK}/${TOOLCHAIN_PREFIX}/libc +export CC=${ARMSDK}/bin/${TOOLCHAIN_PREFIX}-gcc +``` +2. Download the arm toolchain: `curl --output ${TOOLCHAIN_PREFIX}.tar.xz -L 'https://developer.arm.com/-/media/Files/downloads/gnu-a/10.2-2020.11/binrel/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf.tar.xz?revision=d0b90559-3960-4e4b-9297-7ddbc3e52783&la=en&hash=985078B758BC782BC338DB947347107FBCF8EF6B'` +3. `mkdir -p ${ARMSDK} && tar xf ${TOOLCHAIN_PREFIX}.tar.xz -C ${ARMSDK} --strip-components=1` +4. `$CC test_qemu.c -o test_qemu.out -pthread` +5. `qemu-arm -L $SYSROOT ./test_qemu.out` +6. Observe memory usage keeps ramping up and crashes the process once out of memory. +Additional information: +Valgrind annotation logs [annot.log](/uploads/f8d05d8f216d5a589e8da0758a345de6/annot.log) generated by a local build on master@0a301624c2f4ced3331ffd5bce85b4274fe132af from +```bash +valgrind --xtree-memory=full --xtree-memory-file=xtmemory.kcg bin/debug/native/qemu-arm -L $SYSROOT /mnt/f/test_qemu3.out +# Send CTRL-C before the process crashes due to oom +callgrind_annotate --auto=yes --inclusive=yes --sort=curB:100,curBk:100,totB:100,totBk:100,totFdB:100,totFdBk:100 xtmemory.kcg > annot.log +``` + +# diff --git a/results/classifier/108/other/867 b/results/classifier/108/other/867 new file mode 100644 index 00000000..2468b641 --- /dev/null +++ b/results/classifier/108/other/867 @@ -0,0 +1,28 @@ +graphic: 0.879 +device: 0.811 +semantic: 0.535 +network: 0.496 +socket: 0.494 +performance: 0.384 +vnc: 0.316 +debug: 0.297 +KVM: 0.268 +files: 0.268 +PID: 0.263 +permissions: 0.233 +other: 0.200 +boot: 0.118 + +qemu-system-x86_64: warning: usb-redir connection broken during migration +Description of problem: +Create Snapshot, Restore snapshot, crash +Steps to reproduce: +1. Create Snapshot +2. Restore Snapshot +3. Crash +Additional information: + + +No redirecting: + + diff --git a/results/classifier/108/other/869 b/results/classifier/108/other/869 new file mode 100644 index 00000000..30afa757 --- /dev/null +++ b/results/classifier/108/other/869 @@ -0,0 +1,36 @@ +graphic: 0.827 +device: 0.792 +files: 0.650 +semantic: 0.623 +performance: 0.583 +network: 0.427 +boot: 0.415 +PID: 0.401 +debug: 0.391 +other: 0.373 +socket: 0.353 +permissions: 0.340 +vnc: 0.249 +KVM: 0.008 + +Qemu-system-avr working example +Description of problem: +I'm trying to get an Arduino board emulated with QEMU. Unfortunately, I can't get it to work. +I tried the commands, given in [https://qemu.readthedocs.io/en/latest/system/target-avr.html](https://qemu.readthedocs.io/en/latest/system/target-avr.html) and also downloaded and used the example elf file. + + +I then tried some more basic commands and used`qemu-system-avr -machine uno`. This should +run without any problems or? I also tried `2009` and `mega2560`. + +I also searched on the internet about working examples as well as further usage information, but I couldn't really find much. +Therefore, I hope someone can help me out or point me to additional material. +Steps to reproduce: +1. run `qemu-system-avr -machine uno` +2. wait around 5-10 seconds +3. on the terminal the following message appears with the qemu window crashing +``` +$ qemu-system-avr -machine uno + qemu-system-avr: execution left flash memory +``` +Additional information: +I'm fairly new to this, so please excuse me if I forgot something to post or made a mistake while posting. |