qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PULL 19/54] acpi: pc: isa bridge: use AcpiDevAmlIf interface to bui


From: Igor Mammedov
Subject: Re: [PULL 19/54] acpi: pc: isa bridge: use AcpiDevAmlIf interface to build ISA device descriptors
Date: Wed, 12 Apr 2023 14:18:22 +0200

On Thu, 30 Mar 2023 13:58:22 +0200
Fiona Ebner <f.ebner@proxmox.com> wrote:

> Am 30.03.23 um 10:22 schrieb Igor Mammedov:
> > On Tue, 28 Mar 2023 14:58:21 +0200
> > Fiona Ebner <f.ebner@proxmox.com> wrote:
> >   
> >> Am 10.06.22 um 09:57 schrieb Michael S. Tsirkin:  
> >>> From: Igor Mammedov <imammedo@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 <imammedo@redhat.com>
> >>> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
> >>> Message-Id: <20220608135340.3304695-20-imammedo@redhat.com>
> >>> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
> >>> Signed-off-by: Michael S. Tsirkin <mst@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.

I couldn't reproduce the issue on my host either.
If you still have access to 'broken' disk image, you can try to enable
kernel debug mode in guest and try to attach with debugger to it to see
where it is stuck.

quick instructions how to do it:
 https://gitlab.com/qemu-project/qemu/-/issues/774#note_1270248862
or read more extensive MS docs on topic.

> 
> 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'    
> >>  
> 
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]