Hello, > A big endian guest doing XIVE ?!? I'm pretty sure we didn't do much testing, > if > any, on such a setup... What distro is used in the VM ? A live Void Linux ISO ; https://repo.voidlinux-ppc.org/live/current/void-live-ppc64-20190901.iso > This indicates that QEMU failed to configure the source targeting > for the HW interrupt 0x1309, which is an MSI interrupt used by > a PCI device plugged in the default PHB. Especially, -EBUSY means > > -EBUSY: No CPU available to serve interrupt > Okay. > This warning means that we have vCPU without a configured event queue. > > Since kvmppc_xive_select_target() is trying all vCPUs before bailing out > with -EBUSY, you might be seeing several WARNINGs (1 per vCPU) in dmesg, > correct ? > > Anyway, this looks wrong since QEMU is supposed to have already configured > the event queues at this point... Not sure what's happening here... > Indeed. VM core count + 1 such messages in dmesg. > Yeah, QEMU command line, QEMU version, guest kernel version can help. Also, > what kind of workload is running inside the guest ? Is this easy to reproduce > ?
/usr/bin/qemu-system-ppc64 -name guest=voidlinux-ppc64,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-13-voidlinux-ppc64/master-key.aes -machine pseries-4.1,accel=kvm,usb=off,dump-guest-core=off -m 8192 -overcommit mem-lock=off -smp 8,sockets=8,cores=1,threads=1 -uuid 5dd7af48-f00d-43c1-86ed-df5e0f7b4f1c -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=41,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.0,addr=0x2 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x3 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive file=/var/lib/libvirt/images/voidlinux-ppc64.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/home/jdoe/Downloads/void-live-ppc64-20190901.iso,format=raw,if=none,id=drive-scsi0-0-0-0,readonly=on -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=2 -netdev tap,fd=43,id=hostnet0,vhost=on,vhostfd=44 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:ae:d7:62,bus=pci.0,addr=0x1 -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,id=serial0,reg=0x30000000 -chardev socket,id=charchannel0,fd=45,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -device usb-kbd,id=input1,bus=usb.0,port=2 -vnc 127.0.0.1:2 -device VGA,id=video0,vgamem_mb=16,bus=pci.0,addr=0x8 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -object rng-random,id=objrng0,filename=/dev/urandom -device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x7 -loadvm guix-gentoo -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on I am using virt-manager, which is why the command line is so long. And ; $ qemu-system-ppc64 --version QEMU emulator version 4.1.1 (qemu-4.1.1-1.fc31) Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers Workload at snapshot time, the VM was idle, I was compiling software using a Gentoo ppc64 big endian chroot inside the Void Linux ppc64 big endian headless live system. And yes it is easy to reproduce, download that Void Linux ppc64 big endian ISO, using virt-manager, create a ppc64 vm with a disk, set the VM to 8192MB of RAM and 8 cores (less RAM and cores might work, untested) and it should reproduce the issue. It seems that a 1 core, 512MB of RAM VM suffers from no issue with snapshotting. Thanks!
signature.asc
Description: OpenPGP digital signature