Am 30.03.23 um 10:22 schrieb Igor Mammedov: > On Tue, 28 Mar 2023 14:58:21 +0200 > Fiona Ebner <f.eb...@proxmox.com> wrote: > >> Am 10.06.22 um 09:57 schrieb Michael S. Tsirkin: >>> From: Igor Mammedov <imamm...@redhat.com> >>> >>> replaces ad-hoc build_isa_devices_aml() with generic AcpiDevAmlIf >>> way to build bridge AML including all devices that are attached to >>> its ISA bus. >>> >>> Later when PCI is converted to AcpiDevAmlIf, build_piix4_isa_bridge() >>> will also be dropped since PCI parts itself will take care of >>> building device prologue/epilogue AML for each enumerated PCI >>> device. >>> >>> Expected AML change is contextual, where ISA devices are moved >>> from separately declared _SB.PCI0.ISA scope , directly under >>> Device(ISA) node. >>> >>> Signed-off-by: Igor Mammedov <imamm...@redhat.com> >>> Acked-by: Gerd Hoffmann <kra...@redhat.com> >>> Message-Id: <20220608135340.3304695-20-imamm...@redhat.com> >>> Reviewed-by: Michael S. Tsirkin <m...@redhat.com> >>> Signed-off-by: Michael S. Tsirkin <m...@redhat.com> >> >> Hi, >> while trying to reproduce another issue, I ended up with a Windows 10 >> guest that would boot with QEMU 7.0, but get stuck after the Windows >> logo/spinning circles with QEMU 7.1 (also with 8.0.0-rc1). Machine type >> is pc-i440fx-6.2[0]. Bisecting led to this commit. >> >> It only happens the first time the VM is booted, killing the process and >> re-trying always worked afterwards. So it's not a big deal and might >> just be some ACPI-related Windows quirk. But I thought I should ask here >> to be sure. >> >> For bisecting, I restored the disk state after each attempt. While >> getting stuck sometimes took 3-4 attempts, I tested about 10 times until >> I declared a commit good, and re-tested the commit before this one 15 >> times, so I'm pretty sure this is the one where the issue started appearing. >> >> So, anything that could potentially be wrong with the commit or is this >> most likely just some Windows quirk/bug we can't do much about? >> >> If you need more information, please let me know! > > Please describe in more detail your setup/steps where it reproduces > (incl. Windows version/build, used QEMU CLI) so I could try to reproduce it > locally. > > (in past there were issues with German version that some where > experience but not reproducible on my side, that resolved with > upgrading to newer QEMU (if I recall correctly issue was opened > on QEMU's gitlab tracker)) >
Windows 10 Education Version 1809 Build 17763.1 It's not the German ISO, I used default settings (except location Austria and German keymap) and I don't think I did anything other than shutdown after the install was over. The command line is below. I did use our patched QEMU builds when I got into the situation, but I don't think they touch anything ACPI-related and bisecting was done without our patches on top. I tried to reproduce the situation again from scratch today, but wasn't able to. I do still have the problematic disk (snapshot) where the issue occurs as an LVM-Thin volume. If you'd like to have access to that, please send me a direct mail and we can discuss the details there. Best Regards, Fiona >> >> Best Regards, >> Fiona >> >> [0] command line: >>> ./qemu-system-x86_64 \ >>> -accel 'kvm' \ >>> -name 'stuckafterrollbackonboot,debug-threads=on' \ >>> -no-shutdown \ >>> -chardev >>> 'socket,id=qmp,path=/var/run/qemu-server/161.qmp,server=on,wait=off' \ >>> -mon 'chardev=qmp,mode=control' \ >>> -chardev 'socket,id=qmp-event,path=/var/run/qmeventd.sock,reconnect=5' \ >>> -mon 'chardev=qmp-event,mode=control' \ >>> -pidfile /var/run/qemu-server/161.pid \ >>> -smbios 'type=1,uuid=f2b77ed0-73c1-4372-9490-b2c1b59431af' \ >>> -smp '4,sockets=1,cores=4,maxcpus=4' \ >>> -nodefaults \ >>> -boot >>> 'menu=on,strict=on,reboot-timeout=1000,splash=/usr/share/qemu-server/bootsplash.jpg' >>> \ >>> -vnc 'unix:/var/run/qemu-server/161.vnc,password=on' \ >>> -no-hpet \ >>> -cpu >>> 'kvm64,enforce,hv_ipi,hv_relaxed,hv_reset,hv_runtime,hv_spinlocks=0x1fff,hv_stimer,hv_synic,hv_time,hv_vapic,hv_vpindex,+kvm_pv_eoi,+kvm_pv_unhalt,+lahf_lm,+sep' >>> \ >>> -m 6144 \ >>> -device 'pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e' \ >>> -device 'pci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f' \ >>> -device 'pci-bridge,id=pci.3,chassis_nr=3,bus=pci.0,addr=0x5' \ >>> -device 'vmgenid,guid=faa21a64-5921-45fe-9ff3-1f132b9ed029' \ >>> -device 'piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2' \ >>> -device 'usb-tablet,id=tablet,bus=uhci.0,port=1' \ >>> -device 'VGA,id=vga,bus=pci.0,addr=0x2,edid=off' \ >>> -device >>> 'virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3,free-page-reporting=on' \ >>> -iscsi 'initiator-name=iqn.1993-08.org.debian:01:7d9a912f961' \ >>> -device 'ahci,id=ahci0,multifunction=on,bus=pci.0,addr=0x7' \ >>> -drive >>> 'file=/dev/pve/vm-161-disk-0,if=none,id=drive-sata0,format=raw,cache=none,aio=io_uring,detect-zeroes=on' >>> \ >>> -device 'ide-hd,bus=ahci0.0,drive=drive-sata0,id=sata0,bootindex=100' \ >>> -netdev >>> 'type=tap,id=net0,ifname=tap161i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown' >>> \ >>> -device >>> 'e1000,mac=42:BF:8B:AE:68:05,netdev=net0,bus=pci.0,addr=0x12,id=net0,bootindex=102' >>> \ >>> -rtc 'driftfix=slew,base=localtime' \ >>> -machine 'type=pc-i440fx-6.2' \ >>> -global 'kvm-pit.lost_tick_policy=discard' >>