* Windows fails to boot after rebase to QEMU master
@ 2021-05-21 9:17 Siddharth Chandrasekaran
2021-05-24 10:13 ` Michael S. Tsirkin
0 siblings, 1 reply; 14+ messages in thread
From: Siddharth Chandrasekaran @ 2021-05-21 9:17 UTC (permalink / raw)
To: Michael S. Tsirkin, Marcel Apfelbaum, Paolo Bonzini,
Richard Henderson, Eduardo Habkost, Cameron Esfahani,
Roman Bolshakov, Marcelo Tosatti
Cc: qemu-devel, kvm
After a rebase to QEMU master, I am having trouble booting windows VMs.
Git bisect indicates commit f5cc5a5c1686 ("i386: split cpu accelerators
from cpu.c, using AccelCPUClass") to have introduced the issue. I spent
some time looking at into it yesterday without much luck.
Steps to reproduce:
$ ./configure --enable-kvm --disable-xen --target-list=x86_64-softmmu --enable-debug
$ make -j `nproc`
$ ./build/x86_64-softmmu/qemu-system-x86_64 \
-cpu host,hv_synic,hv_vpindex,hv_time,hv_runtime,hv_stimer,hv_crash \
-enable-kvm \
-name test,debug-threads=on \
-smp 1,threads=1,cores=1,sockets=1 \
-m 4G \
-net nic -net user \
-boot d,menu=on \
-usbdevice tablet \
-vnc :3 \
-machine q35,smm=on \
-drive if=pflash,format=raw,readonly=on,unit=0,file="../OVMF_CODE.secboot.fd" \
-drive if=pflash,format=raw,unit=1,file="../OVMF_VARS.secboot.fd" \
-global ICH9-LPC.disable_s3=1 \
-global driver=cfi.pflash01,property=secure,value=on \
-cdrom "../Windows_Server_2016_14393.ISO" \
-drive file="../win_server_2016.qcow2",format=qcow2,if=none,id=rootfs_drive \
-device ahci,id=ahci \
-device ide-hd,drive=rootfs_drive,bus=ahci.0
If the issue is not obvious, I'd like some pointers on how to go about
fixing this issue.
~ Sid.
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: Windows fails to boot after rebase to QEMU master 2021-05-21 9:17 Windows fails to boot after rebase to QEMU master Siddharth Chandrasekaran @ 2021-05-24 10:13 ` Michael S. Tsirkin 2021-05-26 19:30 ` Dr. David Alan Gilbert 0 siblings, 1 reply; 14+ messages in thread From: Michael S. Tsirkin @ 2021-05-24 10:13 UTC (permalink / raw) To: Siddharth Chandrasekaran Cc: Marcel Apfelbaum, Paolo Bonzini, Richard Henderson, Eduardo Habkost, Cameron Esfahani, Roman Bolshakov, Marcelo Tosatti, qemu-devel, kvm On Fri, May 21, 2021 at 11:17:19AM +0200, Siddharth Chandrasekaran wrote: > After a rebase to QEMU master, I am having trouble booting windows VMs. > Git bisect indicates commit f5cc5a5c1686 ("i386: split cpu accelerators > from cpu.c, using AccelCPUClass") to have introduced the issue. I spent > some time looking at into it yesterday without much luck. > > Steps to reproduce: > > $ ./configure --enable-kvm --disable-xen --target-list=x86_64-softmmu --enable-debug > $ make -j `nproc` > $ ./build/x86_64-softmmu/qemu-system-x86_64 \ > -cpu host,hv_synic,hv_vpindex,hv_time,hv_runtime,hv_stimer,hv_crash \ > -enable-kvm \ > -name test,debug-threads=on \ > -smp 1,threads=1,cores=1,sockets=1 \ > -m 4G \ > -net nic -net user \ > -boot d,menu=on \ > -usbdevice tablet \ > -vnc :3 \ > -machine q35,smm=on \ > -drive if=pflash,format=raw,readonly=on,unit=0,file="../OVMF_CODE.secboot.fd" \ > -drive if=pflash,format=raw,unit=1,file="../OVMF_VARS.secboot.fd" \ > -global ICH9-LPC.disable_s3=1 \ > -global driver=cfi.pflash01,property=secure,value=on \ > -cdrom "../Windows_Server_2016_14393.ISO" \ > -drive file="../win_server_2016.qcow2",format=qcow2,if=none,id=rootfs_drive \ > -device ahci,id=ahci \ > -device ide-hd,drive=rootfs_drive,bus=ahci.0 > > If the issue is not obvious, I'd like some pointers on how to go about > fixing this issue. > > ~ Sid. > At a guess this commit inadvertently changed something in the CPU ID. I'd start by using a linux guest to dump cpuid before and after the change. > > > Amazon Development Center Germany GmbH > Krausenstr. 38 > 10117 Berlin > Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss > Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B > Sitz: Berlin > Ust-ID: DE 289 237 879 > > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Windows fails to boot after rebase to QEMU master 2021-05-24 10:13 ` Michael S. Tsirkin @ 2021-05-26 19:30 ` Dr. David Alan Gilbert 2021-05-27 7:57 ` Claudio Fontana 0 siblings, 1 reply; 14+ messages in thread From: Dr. David Alan Gilbert @ 2021-05-26 19:30 UTC (permalink / raw) To: Michael S. Tsirkin, cfontana Cc: Siddharth Chandrasekaran, Eduardo Habkost, kvm, Marcelo Tosatti, Richard Henderson, qemu-devel, Cameron Esfahani, Roman Bolshakov, Paolo Bonzini * Michael S. Tsirkin (mst@redhat.com) wrote: > On Fri, May 21, 2021 at 11:17:19AM +0200, Siddharth Chandrasekaran wrote: > > After a rebase to QEMU master, I am having trouble booting windows VMs. > > Git bisect indicates commit f5cc5a5c1686 ("i386: split cpu accelerators > > from cpu.c, using AccelCPUClass") to have introduced the issue. I spent > > some time looking at into it yesterday without much luck. > > > > Steps to reproduce: > > > > $ ./configure --enable-kvm --disable-xen --target-list=x86_64-softmmu --enable-debug > > $ make -j `nproc` > > $ ./build/x86_64-softmmu/qemu-system-x86_64 \ > > -cpu host,hv_synic,hv_vpindex,hv_time,hv_runtime,hv_stimer,hv_crash \ > > -enable-kvm \ > > -name test,debug-threads=on \ > > -smp 1,threads=1,cores=1,sockets=1 \ > > -m 4G \ > > -net nic -net user \ > > -boot d,menu=on \ > > -usbdevice tablet \ > > -vnc :3 \ > > -machine q35,smm=on \ > > -drive if=pflash,format=raw,readonly=on,unit=0,file="../OVMF_CODE.secboot.fd" \ > > -drive if=pflash,format=raw,unit=1,file="../OVMF_VARS.secboot.fd" \ > > -global ICH9-LPC.disable_s3=1 \ > > -global driver=cfi.pflash01,property=secure,value=on \ > > -cdrom "../Windows_Server_2016_14393.ISO" \ > > -drive file="../win_server_2016.qcow2",format=qcow2,if=none,id=rootfs_drive \ > > -device ahci,id=ahci \ > > -device ide-hd,drive=rootfs_drive,bus=ahci.0 > > > > If the issue is not obvious, I'd like some pointers on how to go about > > fixing this issue. > > > > ~ Sid. > > > > At a guess this commit inadvertently changed something in the CPU ID. > I'd start by using a linux guest to dump cpuid before and after the > change. I've not had a chance to do that yet, however I did just end up with a bisect of a linux guest failure bisecting to the same patch: [dgilbert@dgilbert-t580 qemu]$ git bisect bad f5cc5a5c168674f84bf061cdb307c2d25fba5448 is the first bad commit commit f5cc5a5c168674f84bf061cdb307c2d25fba5448 Author: Claudio Fontana <cfontana@suse.de> Date: Mon Mar 22 14:27:40 2021 +0100 i386: split cpu accelerators from cpu.c, using AccelCPUClass i386 is the first user of AccelCPUClass, allowing to split cpu.c into: cpu.c cpuid and common x86 cpu functionality host-cpu.c host x86 cpu functions and "host" cpu type kvm/kvm-cpu.c KVM x86 AccelCPUClass hvf/hvf-cpu.c HVF x86 AccelCPUClass tcg/tcg-cpu.c TCG x86 AccelCPUClass The guest crash is: [ 85.008985][ T1524] BUG: unable to handle page fault for address: ffffffff810d9c42 [ 85.012868][ T1524] #PF: supervisor write access in kernel mode [ 85.012962][ T1524] #PF: error_code(0x0003) - permissions violation [ 85.013043][ T1524] PGD 2224067 P4D 2224067 PUD 2225063 PMD 10001e1 [ 85.013180][ T1524] Oops: 0003 [#1] SMP NOPTI [ 85.013295][ T1524] CPU: 2 PID: 1524 Comm: blogbench Not tainted 5.11.0-rc7 #100 [ 85.013395][ T1524] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 85.013546][ T1524] RIP: 0010:kvm_kick_cpu+0x22/0x30 [ 85.013630][ T1524] Code: 0f 1f 84 00 00 00 00 00 55 48 63 ff 48 c7 c0 78 11 01 00 48 8b 14 fd c0 36 11 82 48 89 e5 53 31 db 0f b7 0c 02 b8 05 00 00 00 <0f> 01 d9 5b 5d c3 0f 1f 84 00 00 00 00 00 55 48 89 e5 53 48 89 fb [ 85.013852][ T1524] RSP: 0018:ffffc90000747c08 EFLAGS: 00010046 [ 85.013951][ T1524] RAX: 0000000000000005 RBX: 0000000000000000 RCX: 0000000000000000 [ 85.014058][ T1524] RDX: ffff88807c600000 RSI: 0000000000000100 RDI: 0000000000000000 [ 85.014153][ T1524] RBP: ffffc90000747c10 R08: ffff88807c72a800 R09: ffff88807ffd6000 [ 85.014248][ T1524] R10: 0000000000000001 R11: 0000000000000046 R12: ffff88807c72a800 [ 85.014343][ T1524] R13: 0000000000000000 R14: ffff888005409940 R15: ffff88807c72a818 [ 85.014437][ T1524] FS: 00007fa2f750a700(0000) GS:ffff88807c700000(0000) knlGS:0000000000000000 [ 85.014559][ T1524] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 85.014644][ T1524] CR2: ffffffff810d9c42 CR3: 0000000009016003 CR4: 0000000000370ea0 [ 85.014741][ T1524] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 85.014842][ T1524] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 85.014945][ T1524] Call Trace: [ 85.014998][ T1524] __pv_queued_spin_unlock_slowpath+0xa0/0xd0 [ 85.015103][ T1524] __raw_callee_save___pv_queued_spin_unlock_slowpath+0x15/0x24 [ 85.015206][ T1524] .slowpath+0x9/0x15 [ 85.015261][ T1524] do_raw_spin_unlock+0x48/0xc0 [ 85.015333][ T1524] _raw_spin_unlock_irq+0x1d/0x30 [ 85.015404][ T1524] finish_task_switch+0xcc/0x2c0 [ 85.015478][ T1524] __schedule+0x283/0x9a0 [ 85.015534][ T1524] schedule+0x50/0xc0 [ 85.015588][ T1524] request_wait_answer+0x126/0x240 [ 85.015667][ T1524] ? finish_wait+0x90/0x90 [ 85.015740][ T1524] fuse_simple_request+0x17c/0x2e0 the backtrace moves about a bit, but it always ends up as a page fault in kvm_kick_cpu. My qemu commandline being: ./x86_64-softmmu/qemu-system-x86_64 -M pc,memory-backend=mem,accel=kvm -cpu host -m 2G,maxmem=16G,slots=16 -smp 4 -object memory-backend-memfd,id=mem,size=2G,share=on -chardev socket,id=char0,path=/tmp/vhostqemu -device vhost-user-fs-pci,queue-size=1024,chardev=char0,tag=myfs -kernel /home/dgilbert/virtio-fs/kernel-builds/monolithic-dax-20210209a -initrd /home/dgilbert/virtio-fs/test-initramfs.img -chardev stdio,mux=on,id=mon -mon chardev=mon,mode=readline -device virtio-serial-pci,disable-modern=on -device virtconsole,chardev=mon -object rng-random,id=objrng0,filename=/dev/urandom -device virtio-rng-pci,rng=objrng0,id=rng0,disable-legacy=on -vga none -append "console=hvc0 debug loglevel=9 systemd.journald.forward_to_console" -display none -overcommit mem-lock=off -netdev user,id=usernet -device virtio-net-pci,netdev=usernet -name debug-threads=on > > > > > > > Amazon Development Center Germany GmbH > > Krausenstr. 38 > > 10117 Berlin > > Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss > > Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B > > Sitz: Berlin > > Ust-ID: DE 289 237 879 > > > > > > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Windows fails to boot after rebase to QEMU master 2021-05-26 19:30 ` Dr. David Alan Gilbert @ 2021-05-27 7:57 ` Claudio Fontana 2021-05-27 8:31 ` Dr. David Alan Gilbert 0 siblings, 1 reply; 14+ messages in thread From: Claudio Fontana @ 2021-05-27 7:57 UTC (permalink / raw) To: Dr. David Alan Gilbert, Michael S. Tsirkin Cc: Siddharth Chandrasekaran, Eduardo Habkost, kvm, Marcelo Tosatti, Richard Henderson, qemu-devel, Cameron Esfahani, Roman Bolshakov, Paolo Bonzini On 5/26/21 9:30 PM, Dr. David Alan Gilbert wrote: > * Michael S. Tsirkin (mst@redhat.com) wrote: >> On Fri, May 21, 2021 at 11:17:19AM +0200, Siddharth Chandrasekaran wrote: >>> After a rebase to QEMU master, I am having trouble booting windows VMs. >>> Git bisect indicates commit f5cc5a5c1686 ("i386: split cpu accelerators >>> from cpu.c, using AccelCPUClass") to have introduced the issue. I spent >>> some time looking at into it yesterday without much luck. >>> >>> Steps to reproduce: >>> >>> $ ./configure --enable-kvm --disable-xen --target-list=x86_64-softmmu --enable-debug >>> $ make -j `nproc` >>> $ ./build/x86_64-softmmu/qemu-system-x86_64 \ >>> -cpu host,hv_synic,hv_vpindex,hv_time,hv_runtime,hv_stimer,hv_crash \ >>> -enable-kvm \ >>> -name test,debug-threads=on \ >>> -smp 1,threads=1,cores=1,sockets=1 \ >>> -m 4G \ >>> -net nic -net user \ >>> -boot d,menu=on \ >>> -usbdevice tablet \ >>> -vnc :3 \ >>> -machine q35,smm=on \ >>> -drive if=pflash,format=raw,readonly=on,unit=0,file="../OVMF_CODE.secboot.fd" \ >>> -drive if=pflash,format=raw,unit=1,file="../OVMF_VARS.secboot.fd" \ >>> -global ICH9-LPC.disable_s3=1 \ >>> -global driver=cfi.pflash01,property=secure,value=on \ >>> -cdrom "../Windows_Server_2016_14393.ISO" \ >>> -drive file="../win_server_2016.qcow2",format=qcow2,if=none,id=rootfs_drive \ >>> -device ahci,id=ahci \ >>> -device ide-hd,drive=rootfs_drive,bus=ahci.0 >>> >>> If the issue is not obvious, I'd like some pointers on how to go about >>> fixing this issue. >>> >>> ~ Sid. >>> >> >> At a guess this commit inadvertently changed something in the CPU ID. >> I'd start by using a linux guest to dump cpuid before and after the >> change. > > I've not had a chance to do that yet, however I did just end up with a > bisect of a linux guest failure bisecting to the same patch: > > [dgilbert@dgilbert-t580 qemu]$ git bisect bad > f5cc5a5c168674f84bf061cdb307c2d25fba5448 is the first bad commit > commit f5cc5a5c168674f84bf061cdb307c2d25fba5448 > Author: Claudio Fontana <cfontana@suse.de> > Date: Mon Mar 22 14:27:40 2021 +0100 > > i386: split cpu accelerators from cpu.c, using AccelCPUClass > > i386 is the first user of AccelCPUClass, allowing to split > cpu.c into: > > cpu.c cpuid and common x86 cpu functionality > host-cpu.c host x86 cpu functions and "host" cpu type > kvm/kvm-cpu.c KVM x86 AccelCPUClass > hvf/hvf-cpu.c HVF x86 AccelCPUClass > tcg/tcg-cpu.c TCG x86 AccelCPUClass > > Paolo, it seems to me that something went wrong in the merge of this commit. The last version of the series I sent had this comment in the commit message, as part of a very long series of rebases after review. [claudio]: Rebased on commit b8184135 ("target/i386: allow modifying TCG phys-addr-bits") While I do not see this comment in the commit posted here. So I suspect that an older version of the series was included? The series is also available as: https://github.com/hw-claudio/qemu.git "i386_cleanup_9" Thanks, Claudio > The guest crash is: > [ 85.008985][ T1524] BUG: unable to handle page fault for address: ffffffff810d9c42 > [ 85.012868][ T1524] #PF: supervisor write access in kernel mode > [ 85.012962][ T1524] #PF: error_code(0x0003) - permissions violation > [ 85.013043][ T1524] PGD 2224067 P4D 2224067 PUD 2225063 PMD 10001e1 > [ 85.013180][ T1524] Oops: 0003 [#1] SMP NOPTI > [ 85.013295][ T1524] CPU: 2 PID: 1524 Comm: blogbench Not tainted 5.11.0-rc7 #100 > [ 85.013395][ T1524] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 > [ 85.013546][ T1524] RIP: 0010:kvm_kick_cpu+0x22/0x30 > [ 85.013630][ T1524] Code: 0f 1f 84 00 00 00 00 00 55 48 63 ff 48 c7 c0 78 11 01 00 48 8b 14 fd c0 36 11 82 48 89 e5 53 31 db 0f b7 0c 02 b8 05 00 00 00 <0f> 01 d9 5b 5d c3 0f 1f 84 00 00 00 00 00 55 48 89 e5 53 48 89 fb > [ 85.013852][ T1524] RSP: 0018:ffffc90000747c08 EFLAGS: 00010046 > [ 85.013951][ T1524] RAX: 0000000000000005 RBX: 0000000000000000 RCX: 0000000000000000 > [ 85.014058][ T1524] RDX: ffff88807c600000 RSI: 0000000000000100 RDI: 0000000000000000 > [ 85.014153][ T1524] RBP: ffffc90000747c10 R08: ffff88807c72a800 R09: ffff88807ffd6000 > [ 85.014248][ T1524] R10: 0000000000000001 R11: 0000000000000046 R12: ffff88807c72a800 > [ 85.014343][ T1524] R13: 0000000000000000 R14: ffff888005409940 R15: ffff88807c72a818 > [ 85.014437][ T1524] FS: 00007fa2f750a700(0000) GS:ffff88807c700000(0000) knlGS:0000000000000000 > [ 85.014559][ T1524] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 85.014644][ T1524] CR2: ffffffff810d9c42 CR3: 0000000009016003 CR4: 0000000000370ea0 > [ 85.014741][ T1524] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 85.014842][ T1524] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > [ 85.014945][ T1524] Call Trace: > [ 85.014998][ T1524] __pv_queued_spin_unlock_slowpath+0xa0/0xd0 > [ 85.015103][ T1524] __raw_callee_save___pv_queued_spin_unlock_slowpath+0x15/0x24 > [ 85.015206][ T1524] .slowpath+0x9/0x15 > [ 85.015261][ T1524] do_raw_spin_unlock+0x48/0xc0 > [ 85.015333][ T1524] _raw_spin_unlock_irq+0x1d/0x30 > [ 85.015404][ T1524] finish_task_switch+0xcc/0x2c0 > [ 85.015478][ T1524] __schedule+0x283/0x9a0 > [ 85.015534][ T1524] schedule+0x50/0xc0 > [ 85.015588][ T1524] request_wait_answer+0x126/0x240 > [ 85.015667][ T1524] ? finish_wait+0x90/0x90 > [ 85.015740][ T1524] fuse_simple_request+0x17c/0x2e0 > > the backtrace moves about a bit, but it always ends up as > a page fault in kvm_kick_cpu. > > My qemu commandline being: > ./x86_64-softmmu/qemu-system-x86_64 -M pc,memory-backend=mem,accel=kvm -cpu host -m 2G,maxmem=16G,slots=16 -smp 4 -object memory-backend-memfd,id=mem,size=2G,share=on -chardev socket,id=char0,path=/tmp/vhostqemu -device vhost-user-fs-pci,queue-size=1024,chardev=char0,tag=myfs -kernel /home/dgilbert/virtio-fs/kernel-builds/monolithic-dax-20210209a -initrd /home/dgilbert/virtio-fs/test-initramfs.img -chardev stdio,mux=on,id=mon -mon chardev=mon,mode=readline -device virtio-serial-pci,disable-modern=on -device virtconsole,chardev=mon -object rng-random,id=objrng0,filename=/dev/urandom -device virtio-rng-pci,rng=objrng0,id=rng0,disable-legacy=on -vga none -append "console=hvc0 debug loglevel=9 systemd.journald.forward_to_console" -display none -overcommit mem-lock=off -netdev user,id=usernet -device virtio-net-pci,netdev=usernet -name debug-threads=on > > >> >>> >>> >>> Amazon Development Center Germany GmbH >>> Krausenstr. 38 >>> 10117 Berlin >>> Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss >>> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B >>> Sitz: Berlin >>> Ust-ID: DE 289 237 879 >>> >>> >> >> ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Windows fails to boot after rebase to QEMU master 2021-05-27 7:57 ` Claudio Fontana @ 2021-05-27 8:31 ` Dr. David Alan Gilbert 2021-05-27 9:01 ` Philippe Mathieu-Daudé 0 siblings, 1 reply; 14+ messages in thread From: Dr. David Alan Gilbert @ 2021-05-27 8:31 UTC (permalink / raw) To: Claudio Fontana Cc: Michael S. Tsirkin, Siddharth Chandrasekaran, Eduardo Habkost, kvm, Marcelo Tosatti, Richard Henderson, qemu-devel, Cameron Esfahani, Roman Bolshakov, Paolo Bonzini * Claudio Fontana (cfontana@suse.de) wrote: > On 5/26/21 9:30 PM, Dr. David Alan Gilbert wrote: > > * Michael S. Tsirkin (mst@redhat.com) wrote: > >> On Fri, May 21, 2021 at 11:17:19AM +0200, Siddharth Chandrasekaran wrote: > >>> After a rebase to QEMU master, I am having trouble booting windows VMs. > >>> Git bisect indicates commit f5cc5a5c1686 ("i386: split cpu accelerators > >>> from cpu.c, using AccelCPUClass") to have introduced the issue. I spent > >>> some time looking at into it yesterday without much luck. > >>> > >>> Steps to reproduce: > >>> > >>> $ ./configure --enable-kvm --disable-xen --target-list=x86_64-softmmu --enable-debug > >>> $ make -j `nproc` > >>> $ ./build/x86_64-softmmu/qemu-system-x86_64 \ > >>> -cpu host,hv_synic,hv_vpindex,hv_time,hv_runtime,hv_stimer,hv_crash \ > >>> -enable-kvm \ > >>> -name test,debug-threads=on \ > >>> -smp 1,threads=1,cores=1,sockets=1 \ > >>> -m 4G \ > >>> -net nic -net user \ > >>> -boot d,menu=on \ > >>> -usbdevice tablet \ > >>> -vnc :3 \ > >>> -machine q35,smm=on \ > >>> -drive if=pflash,format=raw,readonly=on,unit=0,file="../OVMF_CODE.secboot.fd" \ > >>> -drive if=pflash,format=raw,unit=1,file="../OVMF_VARS.secboot.fd" \ > >>> -global ICH9-LPC.disable_s3=1 \ > >>> -global driver=cfi.pflash01,property=secure,value=on \ > >>> -cdrom "../Windows_Server_2016_14393.ISO" \ > >>> -drive file="../win_server_2016.qcow2",format=qcow2,if=none,id=rootfs_drive \ > >>> -device ahci,id=ahci \ > >>> -device ide-hd,drive=rootfs_drive,bus=ahci.0 > >>> > >>> If the issue is not obvious, I'd like some pointers on how to go about > >>> fixing this issue. > >>> > >>> ~ Sid. > >>> > >> > >> At a guess this commit inadvertently changed something in the CPU ID. > >> I'd start by using a linux guest to dump cpuid before and after the > >> change. > > > > I've not had a chance to do that yet, however I did just end up with a > > bisect of a linux guest failure bisecting to the same patch: > > > > [dgilbert@dgilbert-t580 qemu]$ git bisect bad > > f5cc5a5c168674f84bf061cdb307c2d25fba5448 is the first bad commit > > commit f5cc5a5c168674f84bf061cdb307c2d25fba5448 > > Author: Claudio Fontana <cfontana@suse.de> > > Date: Mon Mar 22 14:27:40 2021 +0100 > > > > i386: split cpu accelerators from cpu.c, using AccelCPUClass > > > > i386 is the first user of AccelCPUClass, allowing to split > > cpu.c into: > > > > cpu.c cpuid and common x86 cpu functionality > > host-cpu.c host x86 cpu functions and "host" cpu type > > kvm/kvm-cpu.c KVM x86 AccelCPUClass > > hvf/hvf-cpu.c HVF x86 AccelCPUClass > > tcg/tcg-cpu.c TCG x86 AccelCPUClass > > > > > > Paolo, it seems to me that something went wrong in the merge of this commit. > > The last version of the series I sent had this comment in the commit message, > as part of a very long series of rebases after review. > > [claudio]: Rebased on commit b8184135 ("target/i386: allow modifying TCG phys-addr-bits") > > > While I do not see this comment in the commit posted here. So I suspect that an older version of the series was included? That comment is there in the one merged: [claudio]: Rebased on commit b8184135 ("target/i386: allow modifying TCG phys-addr-bits") and I don't see any difference in this commit or the 2 previous ones in the upstream compared with your i386_cleanup_9 branch. Dave > The series is also available as: > > https://github.com/hw-claudio/qemu.git "i386_cleanup_9" > > Thanks, > > Claudio > > > > > > The guest crash is: > > [ 85.008985][ T1524] BUG: unable to handle page fault for address: ffffffff810d9c42 > > [ 85.012868][ T1524] #PF: supervisor write access in kernel mode > > [ 85.012962][ T1524] #PF: error_code(0x0003) - permissions violation > > [ 85.013043][ T1524] PGD 2224067 P4D 2224067 PUD 2225063 PMD 10001e1 > > [ 85.013180][ T1524] Oops: 0003 [#1] SMP NOPTI > > [ 85.013295][ T1524] CPU: 2 PID: 1524 Comm: blogbench Not tainted 5.11.0-rc7 #100 > > [ 85.013395][ T1524] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 > > [ 85.013546][ T1524] RIP: 0010:kvm_kick_cpu+0x22/0x30 > > [ 85.013630][ T1524] Code: 0f 1f 84 00 00 00 00 00 55 48 63 ff 48 c7 c0 78 11 01 00 48 8b 14 fd c0 36 11 82 48 89 e5 53 31 db 0f b7 0c 02 b8 05 00 00 00 <0f> 01 d9 5b 5d c3 0f 1f 84 00 00 00 00 00 55 48 89 e5 53 48 89 fb > > [ 85.013852][ T1524] RSP: 0018:ffffc90000747c08 EFLAGS: 00010046 > > [ 85.013951][ T1524] RAX: 0000000000000005 RBX: 0000000000000000 RCX: 0000000000000000 > > [ 85.014058][ T1524] RDX: ffff88807c600000 RSI: 0000000000000100 RDI: 0000000000000000 > > [ 85.014153][ T1524] RBP: ffffc90000747c10 R08: ffff88807c72a800 R09: ffff88807ffd6000 > > [ 85.014248][ T1524] R10: 0000000000000001 R11: 0000000000000046 R12: ffff88807c72a800 > > [ 85.014343][ T1524] R13: 0000000000000000 R14: ffff888005409940 R15: ffff88807c72a818 > > [ 85.014437][ T1524] FS: 00007fa2f750a700(0000) GS:ffff88807c700000(0000) knlGS:0000000000000000 > > [ 85.014559][ T1524] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > [ 85.014644][ T1524] CR2: ffffffff810d9c42 CR3: 0000000009016003 CR4: 0000000000370ea0 > > [ 85.014741][ T1524] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > > [ 85.014842][ T1524] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > > [ 85.014945][ T1524] Call Trace: > > [ 85.014998][ T1524] __pv_queued_spin_unlock_slowpath+0xa0/0xd0 > > [ 85.015103][ T1524] __raw_callee_save___pv_queued_spin_unlock_slowpath+0x15/0x24 > > [ 85.015206][ T1524] .slowpath+0x9/0x15 > > [ 85.015261][ T1524] do_raw_spin_unlock+0x48/0xc0 > > [ 85.015333][ T1524] _raw_spin_unlock_irq+0x1d/0x30 > > [ 85.015404][ T1524] finish_task_switch+0xcc/0x2c0 > > [ 85.015478][ T1524] __schedule+0x283/0x9a0 > > [ 85.015534][ T1524] schedule+0x50/0xc0 > > [ 85.015588][ T1524] request_wait_answer+0x126/0x240 > > [ 85.015667][ T1524] ? finish_wait+0x90/0x90 > > [ 85.015740][ T1524] fuse_simple_request+0x17c/0x2e0 > > > > the backtrace moves about a bit, but it always ends up as > > a page fault in kvm_kick_cpu. > > > > My qemu commandline being: > > ./x86_64-softmmu/qemu-system-x86_64 -M pc,memory-backend=mem,accel=kvm -cpu host -m 2G,maxmem=16G,slots=16 -smp 4 -object memory-backend-memfd,id=mem,size=2G,share=on -chardev socket,id=char0,path=/tmp/vhostqemu -device vhost-user-fs-pci,queue-size=1024,chardev=char0,tag=myfs -kernel /home/dgilbert/virtio-fs/kernel-builds/monolithic-dax-20210209a -initrd /home/dgilbert/virtio-fs/test-initramfs.img -chardev stdio,mux=on,id=mon -mon chardev=mon,mode=readline -device virtio-serial-pci,disable-modern=on -device virtconsole,chardev=mon -object rng-random,id=objrng0,filename=/dev/urandom -device virtio-rng-pci,rng=objrng0,id=rng0,disable-legacy=on -vga none -append "console=hvc0 debug loglevel=9 systemd.journald.forward_to_console" -display none -overcommit mem-lock=off -netdev user,id=usernet -device virtio-net-pci,netdev=usernet -name debug-threads=on > > > > > >> > >>> > >>> > >>> Amazon Development Center Germany GmbH > >>> Krausenstr. 38 > >>> 10117 Berlin > >>> Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss > >>> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B > >>> Sitz: Berlin > >>> Ust-ID: DE 289 237 879 > >>> > >>> > >> > >> > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Windows fails to boot after rebase to QEMU master 2021-05-27 8:31 ` Dr. David Alan Gilbert @ 2021-05-27 9:01 ` Philippe Mathieu-Daudé 2021-05-27 9:15 ` Dr. David Alan Gilbert 0 siblings, 1 reply; 14+ messages in thread From: Philippe Mathieu-Daudé @ 2021-05-27 9:01 UTC (permalink / raw) To: Dr. David Alan Gilbert, Siddharth Chandrasekaran Cc: Eduardo Habkost, kvm, Michael S. Tsirkin, Marcelo Tosatti, Richard Henderson, qemu-devel, Cameron Esfahani, Roman Bolshakov, Paolo Bonzini, Claudio Fontana On 5/27/21 10:31 AM, Dr. David Alan Gilbert wrote: > * Claudio Fontana (cfontana@suse.de) wrote: >> On 5/26/21 9:30 PM, Dr. David Alan Gilbert wrote: >>> * Michael S. Tsirkin (mst@redhat.com) wrote: >>>> On Fri, May 21, 2021 at 11:17:19AM +0200, Siddharth Chandrasekaran wrote: >>>>> After a rebase to QEMU master, I am having trouble booting windows VMs. >>>>> Git bisect indicates commit f5cc5a5c1686 ("i386: split cpu accelerators >>>>> from cpu.c, using AccelCPUClass") to have introduced the issue. I spent >>>>> some time looking at into it yesterday without much luck. >>>>> >>>>> Steps to reproduce: >>>>> >>>>> $ ./configure --enable-kvm --disable-xen --target-list=x86_64-softmmu --enable-debug >>>>> $ make -j `nproc` >>>>> $ ./build/x86_64-softmmu/qemu-system-x86_64 \ >>>>> -cpu host,hv_synic,hv_vpindex,hv_time,hv_runtime,hv_stimer,hv_crash \ >>>>> -enable-kvm \ >>>>> -name test,debug-threads=on \ >>>>> -smp 1,threads=1,cores=1,sockets=1 \ >>>>> -m 4G \ >>>>> -net nic -net user \ >>>>> -boot d,menu=on \ >>>>> -usbdevice tablet \ >>>>> -vnc :3 \ >>>>> -machine q35,smm=on \ >>>>> -drive if=pflash,format=raw,readonly=on,unit=0,file="../OVMF_CODE.secboot.fd" \ >>>>> -drive if=pflash,format=raw,unit=1,file="../OVMF_VARS.secboot.fd" \ >>>>> -global ICH9-LPC.disable_s3=1 \ >>>>> -global driver=cfi.pflash01,property=secure,value=on \ >>>>> -cdrom "../Windows_Server_2016_14393.ISO" \ >>>>> -drive file="../win_server_2016.qcow2",format=qcow2,if=none,id=rootfs_drive \ >>>>> -device ahci,id=ahci \ >>>>> -device ide-hd,drive=rootfs_drive,bus=ahci.0 >>>>> >>>>> If the issue is not obvious, I'd like some pointers on how to go about >>>>> fixing this issue. >>>>> >>>>> ~ Sid. >>>>> >>>> >>>> At a guess this commit inadvertently changed something in the CPU ID. >>>> I'd start by using a linux guest to dump cpuid before and after the >>>> change. >>> >>> I've not had a chance to do that yet, however I did just end up with a >>> bisect of a linux guest failure bisecting to the same patch: >>> >>> [dgilbert@dgilbert-t580 qemu]$ git bisect bad >>> f5cc5a5c168674f84bf061cdb307c2d25fba5448 is the first bad commit >>> commit f5cc5a5c168674f84bf061cdb307c2d25fba5448 >>> Author: Claudio Fontana <cfontana@suse.de> >>> Date: Mon Mar 22 14:27:40 2021 +0100 >>> >>> i386: split cpu accelerators from cpu.c, using AccelCPUClass >>> >>> i386 is the first user of AccelCPUClass, allowing to split >>> cpu.c into: >>> >>> cpu.c cpuid and common x86 cpu functionality >>> host-cpu.c host x86 cpu functions and "host" cpu type >>> kvm/kvm-cpu.c KVM x86 AccelCPUClass >>> hvf/hvf-cpu.c HVF x86 AccelCPUClass >>> tcg/tcg-cpu.c TCG x86 AccelCPUClass Well this is a big commit... I'm not custom to x86 target, and am having hard time following the cpu host/max change. Is it working when you use '-cpu max,...' instead of '-cpu host,'? ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Windows fails to boot after rebase to QEMU master 2021-05-27 9:01 ` Philippe Mathieu-Daudé @ 2021-05-27 9:15 ` Dr. David Alan Gilbert 2021-05-27 9:48 ` Claudio Fontana 0 siblings, 1 reply; 14+ messages in thread From: Dr. David Alan Gilbert @ 2021-05-27 9:15 UTC (permalink / raw) To: Philippe Mathieu-Daudé Cc: Siddharth Chandrasekaran, Eduardo Habkost, kvm, Michael S. Tsirkin, Marcelo Tosatti, Richard Henderson, qemu-devel, Cameron Esfahani, Roman Bolshakov, Paolo Bonzini, Claudio Fontana * Philippe Mathieu-Daudé (philmd@redhat.com) wrote: > On 5/27/21 10:31 AM, Dr. David Alan Gilbert wrote: > > * Claudio Fontana (cfontana@suse.de) wrote: > >> On 5/26/21 9:30 PM, Dr. David Alan Gilbert wrote: > >>> * Michael S. Tsirkin (mst@redhat.com) wrote: > >>>> On Fri, May 21, 2021 at 11:17:19AM +0200, Siddharth Chandrasekaran wrote: > >>>>> After a rebase to QEMU master, I am having trouble booting windows VMs. > >>>>> Git bisect indicates commit f5cc5a5c1686 ("i386: split cpu accelerators > >>>>> from cpu.c, using AccelCPUClass") to have introduced the issue. I spent > >>>>> some time looking at into it yesterday without much luck. > >>>>> > >>>>> Steps to reproduce: > >>>>> > >>>>> $ ./configure --enable-kvm --disable-xen --target-list=x86_64-softmmu --enable-debug > >>>>> $ make -j `nproc` > >>>>> $ ./build/x86_64-softmmu/qemu-system-x86_64 \ > >>>>> -cpu host,hv_synic,hv_vpindex,hv_time,hv_runtime,hv_stimer,hv_crash \ > >>>>> -enable-kvm \ > >>>>> -name test,debug-threads=on \ > >>>>> -smp 1,threads=1,cores=1,sockets=1 \ > >>>>> -m 4G \ > >>>>> -net nic -net user \ > >>>>> -boot d,menu=on \ > >>>>> -usbdevice tablet \ > >>>>> -vnc :3 \ > >>>>> -machine q35,smm=on \ > >>>>> -drive if=pflash,format=raw,readonly=on,unit=0,file="../OVMF_CODE.secboot.fd" \ > >>>>> -drive if=pflash,format=raw,unit=1,file="../OVMF_VARS.secboot.fd" \ > >>>>> -global ICH9-LPC.disable_s3=1 \ > >>>>> -global driver=cfi.pflash01,property=secure,value=on \ > >>>>> -cdrom "../Windows_Server_2016_14393.ISO" \ > >>>>> -drive file="../win_server_2016.qcow2",format=qcow2,if=none,id=rootfs_drive \ > >>>>> -device ahci,id=ahci \ > >>>>> -device ide-hd,drive=rootfs_drive,bus=ahci.0 > >>>>> > >>>>> If the issue is not obvious, I'd like some pointers on how to go about > >>>>> fixing this issue. > >>>>> > >>>>> ~ Sid. > >>>>> > >>>> > >>>> At a guess this commit inadvertently changed something in the CPU ID. > >>>> I'd start by using a linux guest to dump cpuid before and after the > >>>> change. > >>> > >>> I've not had a chance to do that yet, however I did just end up with a > >>> bisect of a linux guest failure bisecting to the same patch: > >>> > >>> [dgilbert@dgilbert-t580 qemu]$ git bisect bad > >>> f5cc5a5c168674f84bf061cdb307c2d25fba5448 is the first bad commit > >>> commit f5cc5a5c168674f84bf061cdb307c2d25fba5448 > >>> Author: Claudio Fontana <cfontana@suse.de> > >>> Date: Mon Mar 22 14:27:40 2021 +0100 > >>> > >>> i386: split cpu accelerators from cpu.c, using AccelCPUClass > >>> > >>> i386 is the first user of AccelCPUClass, allowing to split > >>> cpu.c into: > >>> > >>> cpu.c cpuid and common x86 cpu functionality > >>> host-cpu.c host x86 cpu functions and "host" cpu type > >>> kvm/kvm-cpu.c KVM x86 AccelCPUClass > >>> hvf/hvf-cpu.c HVF x86 AccelCPUClass > >>> tcg/tcg-cpu.c TCG x86 AccelCPUClass > > Well this is a big commit... I'm not custom to x86 target, and am > having hard time following the cpu host/max change. > > Is it working when you use '-cpu max,...' instead of '-cpu host,'? No; and in fact the cpuid's are almost entirely different with and without this patch! (both with -cpu host). It looks like with this patch we're getting the cpuid for the TCG cpuid rather than the host: Prior to this patch: :/# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 142 model name : Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz stepping : 10 microcode : 0xe0 cpu MHz : 2111.998 cache size : 16384 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 22 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant _tsc arch_perfmon rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_tim er aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 xsaves arat umip md_clear arch_ca pabilities vmx flags : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest shadow_vmcs pml bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa srbds bogomips : 4223.99 clflush size : 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: With this patch: processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 6 model name : QEMU TCG CPU version 2.5+ stepping : 3 cpu MHz : 2111.998 cache size : 512 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm nopl cpu id tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_ lm abm 3dnowprefetch invpcid_single ssbd ibrs ibpb stibp vmmcall fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 xsaves arat umip md_clear arch_capabilities bugs : fxsave_leak sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass taa bogomips : 4223.99 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: cpuid.f5cc5a5c16 CPU 0: 0x00000000 0x00: eax=0x0000000d ebx=0x68747541 ecx=0x444d4163 edx=0x69746e65 0x00000001 0x00: eax=0x00000663 ebx=0x00000800 ecx=0xfffab223 edx=0x0f8bfbff 0x00000002 0x00: eax=0x00000001 ebx=0x00000000 ecx=0x0000004d edx=0x002c307d 0x00000003 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 0x00000004 0x00: eax=0x00000121 ebx=0x01c0003f ecx=0x0000003f edx=0x00000001 0x00000004 0x01: eax=0x00000122 ebx=0x01c0003f ecx=0x0000003f edx=0x00000001 0x00000004 0x02: eax=0x00000143 ebx=0x03c0003f ecx=0x00000fff edx=0x00000001 0x00000004 0x03: eax=0x00000163 ebx=0x03c0003f ecx=0x00003fff edx=0x00000006 0x00000005 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000003 edx=0x00000000 0x00000006 0x00: eax=0x00000004 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 0x00000007 0x00: eax=0x00000000 ebx=0x009c4fbb ecx=0x00000004 edx=0xac000400 0x00000008 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 0x00000009 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 0x0000000a 0x00: eax=0x07300402 ebx=0x00000000 ecx=0x00000000 edx=0x00008603 0x0000000b 0x00: eax=0x00000000 ebx=0x00000001 ecx=0x00000100 edx=0x00000000 0x0000000b 0x01: eax=0x00000000 ebx=0x00000001 ecx=0x00000201 edx=0x00000000 0x0000000c 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 0x0000000d 0x00: eax=0x0000001f ebx=0x00000440 ecx=0x00000440 edx=0x00000000 0x0000000d 0x01: eax=0x0000000f ebx=0x000003c0 ecx=0x00000000 edx=0x00000000 0x0000000d 0x02: eax=0x00000100 ebx=0x00000240 ecx=0x00000000 edx=0x00000000 0x0000000d 0x03: eax=0x00000040 ebx=0x000003c0 ecx=0x00000000 edx=0x00000000 0x0000000d 0x04: eax=0x00000040 ebx=0x00000400 ecx=0x00000000 edx=0x00000000 0x40000000 0x00: eax=0x40000001 ebx=0x4b4d564b ecx=0x564b4d56 edx=0x0000004d 0x40000001 0x00: eax=0x01007afb ebx=0x00000000 ecx=0x00000000 edx=0x00000000 0x80000000 0x00: eax=0x80000008 ebx=0x68747541 ecx=0x444d4163 edx=0x69746e65 0x80000001 0x00: eax=0x00000663 ebx=0x00000000 ecx=0x00000121 edx=0x2d93fbff 0x80000002 0x00: eax=0x554d4551 ebx=0x47435420 ecx=0x55504320 edx=0x72657620 0x80000003 0x00: eax=0x6e6f6973 ebx=0x352e3220 ecx=0x0000002b edx=0x00000000 0x80000004 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 0x80000005 0x00: eax=0x01ff01ff ebx=0x01ff01ff ecx=0x40020140 edx=0x40020140 0x80000006 0x00: eax=0x00000000 ebx=0x42004200 ecx=0x02008140 edx=0x00808140 0x80000007 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 0x80000008 0x00: eax=0x00003028 ebx=0x0100d000 ecx=0x00000000 edx=0x00000000 0x80860000 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 0xc0000000 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 cpuid.0ac2b19743 CPU 0: 0x00000000 0x00: eax=0x00000016 ebx=0x756e6547 ecx=0x6c65746e edx=0x49656e69 0x00000001 0x00: eax=0x000806ea ebx=0x00000800 ecx=0xfffab223 edx=0x0f8bfbff 0x00000002 0x00: eax=0x00000001 ebx=0x00000000 ecx=0x0000004d edx=0x002c307d 0x00000003 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 0x00000004 0x00: eax=0x00000121 ebx=0x01c0003f ecx=0x0000003f edx=0x00000001 0x00000004 0x01: eax=0x00000122 ebx=0x01c0003f ecx=0x0000003f edx=0x00000001 0x00000004 0x02: eax=0x00000143 ebx=0x03c0003f ecx=0x00000fff edx=0x00000001 0x00000004 0x03: eax=0x00000163 ebx=0x03c0003f ecx=0x00003fff edx=0x00000006 0x00000005 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000003 edx=0x00000000 0x00000006 0x00: eax=0x00000004 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 0x00000007 0x00: eax=0x00000000 ebx=0x009c4fbb ecx=0x00000004 edx=0xac000400 0x00000008 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 0x00000009 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 0x0000000a 0x00: eax=0x07300402 ebx=0x00000000 ecx=0x00000000 edx=0x00008603 0x0000000b 0x00: eax=0x00000000 ebx=0x00000001 ecx=0x00000100 edx=0x00000000 0x0000000b 0x01: eax=0x00000000 ebx=0x00000001 ecx=0x00000201 edx=0x00000000 0x0000000c 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 0x0000000d 0x00: eax=0x0000001f ebx=0x00000440 ecx=0x00000440 edx=0x00000000 0x0000000d 0x01: eax=0x0000000f ebx=0x000003c0 ecx=0x00000000 edx=0x00000000 0x0000000d 0x02: eax=0x00000100 ebx=0x00000240 ecx=0x00000000 edx=0x00000000 0x0000000d 0x03: eax=0x00000040 ebx=0x000003c0 ecx=0x00000000 edx=0x00000000 0x0000000d 0x04: eax=0x00000040 ebx=0x00000400 ecx=0x00000000 edx=0x00000000 0x0000000e 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 0x0000000f 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 0x00000010 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 0x00000011 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 0x00000012 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 0x00000013 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 0x00000014 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 0x00000015 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 0x00000016 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 0x40000000 0x00: eax=0x40000001 ebx=0x4b4d564b ecx=0x564b4d56 edx=0x0000004d 0x40000001 0x00: eax=0x01007afb ebx=0x00000000 ecx=0x00000000 edx=0x00000000 0x80000000 0x00: eax=0x80000008 ebx=0x756e6547 ecx=0x6c65746e edx=0x49656e69 0x80000001 0x00: eax=0x000806ea ebx=0x00000000 ecx=0x00000121 edx=0x2c100800 0x80000002 0x00: eax=0x65746e49 ebx=0x2952286c ecx=0x726f4320 edx=0x4d542865 0x80000003 0x00: eax=0x37692029 ebx=0x3536382d ecx=0x43205530 edx=0x40205550 0x80000004 0x00: eax=0x392e3120 ebx=0x7a484730 ecx=0x00000000 edx=0x00000000 0x80000005 0x00: eax=0x01ff01ff ebx=0x01ff01ff ecx=0x40020140 edx=0x40020140 0x80000006 0x00: eax=0x00000000 ebx=0x42004200 ecx=0x02008140 edx=0x00808140 0x80000007 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 0x80000008 0x00: eax=0x00003027 ebx=0x0100d000 ecx=0x00000000 edx=0x00000000 0x80860000 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 0xc0000000 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Windows fails to boot after rebase to QEMU master 2021-05-27 9:15 ` Dr. David Alan Gilbert @ 2021-05-27 9:48 ` Claudio Fontana 2021-05-27 10:53 ` Claudio Fontana 0 siblings, 1 reply; 14+ messages in thread From: Claudio Fontana @ 2021-05-27 9:48 UTC (permalink / raw) To: Dr. David Alan Gilbert, Philippe Mathieu-Daudé Cc: Siddharth Chandrasekaran, Eduardo Habkost, kvm, Michael S. Tsirkin, Marcelo Tosatti, Richard Henderson, qemu-devel, Cameron Esfahani, Roman Bolshakov, Paolo Bonzini On 5/27/21 11:15 AM, Dr. David Alan Gilbert wrote: > * Philippe Mathieu-Daudé (philmd@redhat.com) wrote: >> On 5/27/21 10:31 AM, Dr. David Alan Gilbert wrote: >>> * Claudio Fontana (cfontana@suse.de) wrote: >>>> On 5/26/21 9:30 PM, Dr. David Alan Gilbert wrote: >>>>> * Michael S. Tsirkin (mst@redhat.com) wrote: >>>>>> On Fri, May 21, 2021 at 11:17:19AM +0200, Siddharth Chandrasekaran wrote: >>>>>>> After a rebase to QEMU master, I am having trouble booting windows VMs. >>>>>>> Git bisect indicates commit f5cc5a5c1686 ("i386: split cpu accelerators >>>>>>> from cpu.c, using AccelCPUClass") to have introduced the issue. I spent >>>>>>> some time looking at into it yesterday without much luck. >>>>>>> >>>>>>> Steps to reproduce: >>>>>>> >>>>>>> $ ./configure --enable-kvm --disable-xen --target-list=x86_64-softmmu --enable-debug >>>>>>> $ make -j `nproc` >>>>>>> $ ./build/x86_64-softmmu/qemu-system-x86_64 \ >>>>>>> -cpu host,hv_synic,hv_vpindex,hv_time,hv_runtime,hv_stimer,hv_crash \ >>>>>>> -enable-kvm \ >>>>>>> -name test,debug-threads=on \ >>>>>>> -smp 1,threads=1,cores=1,sockets=1 \ >>>>>>> -m 4G \ >>>>>>> -net nic -net user \ >>>>>>> -boot d,menu=on \ >>>>>>> -usbdevice tablet \ >>>>>>> -vnc :3 \ >>>>>>> -machine q35,smm=on \ >>>>>>> -drive if=pflash,format=raw,readonly=on,unit=0,file="../OVMF_CODE.secboot.fd" \ >>>>>>> -drive if=pflash,format=raw,unit=1,file="../OVMF_VARS.secboot.fd" \ >>>>>>> -global ICH9-LPC.disable_s3=1 \ >>>>>>> -global driver=cfi.pflash01,property=secure,value=on \ >>>>>>> -cdrom "../Windows_Server_2016_14393.ISO" \ >>>>>>> -drive file="../win_server_2016.qcow2",format=qcow2,if=none,id=rootfs_drive \ >>>>>>> -device ahci,id=ahci \ >>>>>>> -device ide-hd,drive=rootfs_drive,bus=ahci.0 >>>>>>> >>>>>>> If the issue is not obvious, I'd like some pointers on how to go about >>>>>>> fixing this issue. >>>>>>> >>>>>>> ~ Sid. >>>>>>> >>>>>> >>>>>> At a guess this commit inadvertently changed something in the CPU ID. >>>>>> I'd start by using a linux guest to dump cpuid before and after the >>>>>> change. >>>>> >>>>> I've not had a chance to do that yet, however I did just end up with a >>>>> bisect of a linux guest failure bisecting to the same patch: >>>>> >>>>> [dgilbert@dgilbert-t580 qemu]$ git bisect bad >>>>> f5cc5a5c168674f84bf061cdb307c2d25fba5448 is the first bad commit >>>>> commit f5cc5a5c168674f84bf061cdb307c2d25fba5448 >>>>> Author: Claudio Fontana <cfontana@suse.de> >>>>> Date: Mon Mar 22 14:27:40 2021 +0100 >>>>> >>>>> i386: split cpu accelerators from cpu.c, using AccelCPUClass >>>>> >>>>> i386 is the first user of AccelCPUClass, allowing to split >>>>> cpu.c into: >>>>> >>>>> cpu.c cpuid and common x86 cpu functionality >>>>> host-cpu.c host x86 cpu functions and "host" cpu type >>>>> kvm/kvm-cpu.c KVM x86 AccelCPUClass >>>>> hvf/hvf-cpu.c HVF x86 AccelCPUClass >>>>> tcg/tcg-cpu.c TCG x86 AccelCPUClass >> >> Well this is a big commit... I'm not custom to x86 target, and am >> having hard time following the cpu host/max change. >> >> Is it working when you use '-cpu max,...' instead of '-cpu host,'? > > No; and in fact the cpuid's are almost entirely different with and > without this patch! (both with -cpu host). It looks like with this > patch we're getting the cpuid for the TCG cpuid rather than the host: > > Prior to this patch: > :/# cat /proc/cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 142 > model name : Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz > stepping : 10 > microcode : 0xe0 > cpu MHz : 2111.998 > cache size : 16384 KB > physical id : 0 > siblings : 1 > core id : 0 > cpu cores : 1 > apicid : 0 > initial apicid : 0 > fpu : yes > fpu_exception : yes > cpuid level : 22 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant > _tsc arch_perfmon rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_tim > er aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid > ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 xsaves arat umip md_clear arch_ca > pabilities > vmx flags : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest shadow_vmcs pml > bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa srbds > bogomips : 4223.99 > clflush size : 64 > cache_alignment : 64 > address sizes : 39 bits physical, 48 bits virtual > power management: > > With this patch: > processor : 0 > vendor_id : AuthenticAMD > cpu family : 6 > model : 6 > model name : QEMU TCG CPU version 2.5+ > stepping : 3 > cpu MHz : 2111.998 > cache size : 512 KB > physical id : 0 > siblings : 1 > core id : 0 > cpu cores : 1 > apicid : 0 > initial apicid : 0 > fpu : yes > fpu_exception : yes > cpuid level : 13 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm nopl cpu > id tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_ > lm abm 3dnowprefetch invpcid_single ssbd ibrs ibpb stibp vmmcall fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt > xsaveopt xsavec xgetbv1 xsaves arat umip md_clear arch_capabilities > bugs : fxsave_leak sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass taa > bogomips : 4223.99 > TLB size : 1024 4K pages > clflush size : 64 > cache_alignment : 64 > address sizes : 40 bits physical, 48 bits virtual > power management: > > cpuid.f5cc5a5c16 > > CPU 0: > 0x00000000 0x00: eax=0x0000000d ebx=0x68747541 ecx=0x444d4163 edx=0x69746e65 > 0x00000001 0x00: eax=0x00000663 ebx=0x00000800 ecx=0xfffab223 edx=0x0f8bfbff > 0x00000002 0x00: eax=0x00000001 ebx=0x00000000 ecx=0x0000004d edx=0x002c307d > 0x00000003 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > 0x00000004 0x00: eax=0x00000121 ebx=0x01c0003f ecx=0x0000003f edx=0x00000001 > 0x00000004 0x01: eax=0x00000122 ebx=0x01c0003f ecx=0x0000003f edx=0x00000001 > 0x00000004 0x02: eax=0x00000143 ebx=0x03c0003f ecx=0x00000fff edx=0x00000001 > 0x00000004 0x03: eax=0x00000163 ebx=0x03c0003f ecx=0x00003fff edx=0x00000006 > 0x00000005 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000003 edx=0x00000000 > 0x00000006 0x00: eax=0x00000004 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > 0x00000007 0x00: eax=0x00000000 ebx=0x009c4fbb ecx=0x00000004 edx=0xac000400 > 0x00000008 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > 0x00000009 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > 0x0000000a 0x00: eax=0x07300402 ebx=0x00000000 ecx=0x00000000 edx=0x00008603 > 0x0000000b 0x00: eax=0x00000000 ebx=0x00000001 ecx=0x00000100 edx=0x00000000 > 0x0000000b 0x01: eax=0x00000000 ebx=0x00000001 ecx=0x00000201 edx=0x00000000 > 0x0000000c 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > 0x0000000d 0x00: eax=0x0000001f ebx=0x00000440 ecx=0x00000440 edx=0x00000000 > 0x0000000d 0x01: eax=0x0000000f ebx=0x000003c0 ecx=0x00000000 edx=0x00000000 > 0x0000000d 0x02: eax=0x00000100 ebx=0x00000240 ecx=0x00000000 edx=0x00000000 > 0x0000000d 0x03: eax=0x00000040 ebx=0x000003c0 ecx=0x00000000 edx=0x00000000 > 0x0000000d 0x04: eax=0x00000040 ebx=0x00000400 ecx=0x00000000 edx=0x00000000 > 0x40000000 0x00: eax=0x40000001 ebx=0x4b4d564b ecx=0x564b4d56 edx=0x0000004d > 0x40000001 0x00: eax=0x01007afb ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > 0x80000000 0x00: eax=0x80000008 ebx=0x68747541 ecx=0x444d4163 edx=0x69746e65 > 0x80000001 0x00: eax=0x00000663 ebx=0x00000000 ecx=0x00000121 edx=0x2d93fbff > 0x80000002 0x00: eax=0x554d4551 ebx=0x47435420 ecx=0x55504320 edx=0x72657620 > 0x80000003 0x00: eax=0x6e6f6973 ebx=0x352e3220 ecx=0x0000002b edx=0x00000000 > 0x80000004 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > 0x80000005 0x00: eax=0x01ff01ff ebx=0x01ff01ff ecx=0x40020140 edx=0x40020140 > 0x80000006 0x00: eax=0x00000000 ebx=0x42004200 ecx=0x02008140 edx=0x00808140 > 0x80000007 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > 0x80000008 0x00: eax=0x00003028 ebx=0x0100d000 ecx=0x00000000 edx=0x00000000 > 0x80860000 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > 0xc0000000 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > > > cpuid.0ac2b19743 > > CPU 0: > 0x00000000 0x00: eax=0x00000016 ebx=0x756e6547 ecx=0x6c65746e edx=0x49656e69 > 0x00000001 0x00: eax=0x000806ea ebx=0x00000800 ecx=0xfffab223 edx=0x0f8bfbff > 0x00000002 0x00: eax=0x00000001 ebx=0x00000000 ecx=0x0000004d edx=0x002c307d > 0x00000003 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > 0x00000004 0x00: eax=0x00000121 ebx=0x01c0003f ecx=0x0000003f edx=0x00000001 > 0x00000004 0x01: eax=0x00000122 ebx=0x01c0003f ecx=0x0000003f edx=0x00000001 > 0x00000004 0x02: eax=0x00000143 ebx=0x03c0003f ecx=0x00000fff edx=0x00000001 > 0x00000004 0x03: eax=0x00000163 ebx=0x03c0003f ecx=0x00003fff edx=0x00000006 > 0x00000005 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000003 edx=0x00000000 > 0x00000006 0x00: eax=0x00000004 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > 0x00000007 0x00: eax=0x00000000 ebx=0x009c4fbb ecx=0x00000004 edx=0xac000400 > 0x00000008 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > 0x00000009 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > 0x0000000a 0x00: eax=0x07300402 ebx=0x00000000 ecx=0x00000000 edx=0x00008603 > 0x0000000b 0x00: eax=0x00000000 ebx=0x00000001 ecx=0x00000100 edx=0x00000000 > 0x0000000b 0x01: eax=0x00000000 ebx=0x00000001 ecx=0x00000201 edx=0x00000000 > 0x0000000c 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > 0x0000000d 0x00: eax=0x0000001f ebx=0x00000440 ecx=0x00000440 edx=0x00000000 > 0x0000000d 0x01: eax=0x0000000f ebx=0x000003c0 ecx=0x00000000 edx=0x00000000 > 0x0000000d 0x02: eax=0x00000100 ebx=0x00000240 ecx=0x00000000 edx=0x00000000 > 0x0000000d 0x03: eax=0x00000040 ebx=0x000003c0 ecx=0x00000000 edx=0x00000000 > 0x0000000d 0x04: eax=0x00000040 ebx=0x00000400 ecx=0x00000000 edx=0x00000000 > 0x0000000e 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > 0x0000000f 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > 0x00000010 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > 0x00000011 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > 0x00000012 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > 0x00000013 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > 0x00000014 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > 0x00000015 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > 0x00000016 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > 0x40000000 0x00: eax=0x40000001 ebx=0x4b4d564b ecx=0x564b4d56 edx=0x0000004d > 0x40000001 0x00: eax=0x01007afb ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > 0x80000000 0x00: eax=0x80000008 ebx=0x756e6547 ecx=0x6c65746e edx=0x49656e69 > 0x80000001 0x00: eax=0x000806ea ebx=0x00000000 ecx=0x00000121 edx=0x2c100800 > 0x80000002 0x00: eax=0x65746e49 ebx=0x2952286c ecx=0x726f4320 edx=0x4d542865 > 0x80000003 0x00: eax=0x37692029 ebx=0x3536382d ecx=0x43205530 edx=0x40205550 > 0x80000004 0x00: eax=0x392e3120 ebx=0x7a484730 ecx=0x00000000 edx=0x00000000 > 0x80000005 0x00: eax=0x01ff01ff ebx=0x01ff01ff ecx=0x40020140 edx=0x40020140 > 0x80000006 0x00: eax=0x00000000 ebx=0x42004200 ecx=0x02008140 edx=0x00808140 > 0x80000007 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > 0x80000008 0x00: eax=0x00003027 ebx=0x0100d000 ecx=0x00000000 edx=0x00000000 > 0x80860000 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > 0xc0000000 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > I started looking at it. Claudio ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Windows fails to boot after rebase to QEMU master 2021-05-27 9:48 ` Claudio Fontana @ 2021-05-27 10:53 ` Claudio Fontana 2021-05-27 11:36 ` Claudio Fontana 0 siblings, 1 reply; 14+ messages in thread From: Claudio Fontana @ 2021-05-27 10:53 UTC (permalink / raw) To: Dr. David Alan Gilbert, Philippe Mathieu-Daudé Cc: Siddharth Chandrasekaran, Eduardo Habkost, kvm, Michael S. Tsirkin, Marcelo Tosatti, Richard Henderson, qemu-devel, Cameron Esfahani, Roman Bolshakov, Paolo Bonzini On 5/27/21 11:48 AM, Claudio Fontana wrote: > On 5/27/21 11:15 AM, Dr. David Alan Gilbert wrote: >> * Philippe Mathieu-Daudé (philmd@redhat.com) wrote: >>> On 5/27/21 10:31 AM, Dr. David Alan Gilbert wrote: >>>> * Claudio Fontana (cfontana@suse.de) wrote: >>>>> On 5/26/21 9:30 PM, Dr. David Alan Gilbert wrote: >>>>>> * Michael S. Tsirkin (mst@redhat.com) wrote: >>>>>>> On Fri, May 21, 2021 at 11:17:19AM +0200, Siddharth Chandrasekaran wrote: >>>>>>>> After a rebase to QEMU master, I am having trouble booting windows VMs. >>>>>>>> Git bisect indicates commit f5cc5a5c1686 ("i386: split cpu accelerators >>>>>>>> from cpu.c, using AccelCPUClass") to have introduced the issue. I spent >>>>>>>> some time looking at into it yesterday without much luck. >>>>>>>> >>>>>>>> Steps to reproduce: >>>>>>>> >>>>>>>> $ ./configure --enable-kvm --disable-xen --target-list=x86_64-softmmu --enable-debug >>>>>>>> $ make -j `nproc` >>>>>>>> $ ./build/x86_64-softmmu/qemu-system-x86_64 \ >>>>>>>> -cpu host,hv_synic,hv_vpindex,hv_time,hv_runtime,hv_stimer,hv_crash \ >>>>>>>> -enable-kvm \ >>>>>>>> -name test,debug-threads=on \ >>>>>>>> -smp 1,threads=1,cores=1,sockets=1 \ >>>>>>>> -m 4G \ >>>>>>>> -net nic -net user \ >>>>>>>> -boot d,menu=on \ >>>>>>>> -usbdevice tablet \ >>>>>>>> -vnc :3 \ >>>>>>>> -machine q35,smm=on \ >>>>>>>> -drive if=pflash,format=raw,readonly=on,unit=0,file="../OVMF_CODE.secboot.fd" \ >>>>>>>> -drive if=pflash,format=raw,unit=1,file="../OVMF_VARS.secboot.fd" \ >>>>>>>> -global ICH9-LPC.disable_s3=1 \ >>>>>>>> -global driver=cfi.pflash01,property=secure,value=on \ >>>>>>>> -cdrom "../Windows_Server_2016_14393.ISO" \ >>>>>>>> -drive file="../win_server_2016.qcow2",format=qcow2,if=none,id=rootfs_drive \ >>>>>>>> -device ahci,id=ahci \ >>>>>>>> -device ide-hd,drive=rootfs_drive,bus=ahci.0 >>>>>>>> >>>>>>>> If the issue is not obvious, I'd like some pointers on how to go about >>>>>>>> fixing this issue. >>>>>>>> >>>>>>>> ~ Sid. >>>>>>>> >>>>>>> >>>>>>> At a guess this commit inadvertently changed something in the CPU ID. >>>>>>> I'd start by using a linux guest to dump cpuid before and after the >>>>>>> change. >>>>>> >>>>>> I've not had a chance to do that yet, however I did just end up with a >>>>>> bisect of a linux guest failure bisecting to the same patch: >>>>>> >>>>>> [dgilbert@dgilbert-t580 qemu]$ git bisect bad >>>>>> f5cc5a5c168674f84bf061cdb307c2d25fba5448 is the first bad commit >>>>>> commit f5cc5a5c168674f84bf061cdb307c2d25fba5448 >>>>>> Author: Claudio Fontana <cfontana@suse.de> >>>>>> Date: Mon Mar 22 14:27:40 2021 +0100 >>>>>> >>>>>> i386: split cpu accelerators from cpu.c, using AccelCPUClass >>>>>> >>>>>> i386 is the first user of AccelCPUClass, allowing to split >>>>>> cpu.c into: >>>>>> >>>>>> cpu.c cpuid and common x86 cpu functionality >>>>>> host-cpu.c host x86 cpu functions and "host" cpu type >>>>>> kvm/kvm-cpu.c KVM x86 AccelCPUClass >>>>>> hvf/hvf-cpu.c HVF x86 AccelCPUClass >>>>>> tcg/tcg-cpu.c TCG x86 AccelCPUClass >>> >>> Well this is a big commit... I'm not custom to x86 target, and am >>> having hard time following the cpu host/max change. >>> >>> Is it working when you use '-cpu max,...' instead of '-cpu host,'? >> >> No; and in fact the cpuid's are almost entirely different with and >> without this patch! (both with -cpu host). It looks like with this >> patch we're getting the cpuid for the TCG cpuid rather than the host: >> >> Prior to this patch: >> :/# cat /proc/cpuinfo >> processor : 0 >> vendor_id : GenuineIntel >> cpu family : 6 >> model : 142 >> model name : Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz >> stepping : 10 >> microcode : 0xe0 >> cpu MHz : 2111.998 >> cache size : 16384 KB >> physical id : 0 >> siblings : 1 >> core id : 0 >> cpu cores : 1 >> apicid : 0 >> initial apicid : 0 >> fpu : yes >> fpu_exception : yes >> cpuid level : 22 >> wp : yes >> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant >> _tsc arch_perfmon rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_tim >> er aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid >> ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 xsaves arat umip md_clear arch_ca >> pabilities >> vmx flags : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest shadow_vmcs pml >> bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa srbds >> bogomips : 4223.99 >> clflush size : 64 >> cache_alignment : 64 >> address sizes : 39 bits physical, 48 bits virtual >> power management: >> >> With this patch: >> processor : 0 >> vendor_id : AuthenticAMD >> cpu family : 6 >> model : 6 >> model name : QEMU TCG CPU version 2.5+ >> stepping : 3 >> cpu MHz : 2111.998 >> cache size : 512 KB >> physical id : 0 >> siblings : 1 >> core id : 0 >> cpu cores : 1 >> apicid : 0 >> initial apicid : 0 >> fpu : yes >> fpu_exception : yes >> cpuid level : 13 >> wp : yes >> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm nopl cpu >> id tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_ >> lm abm 3dnowprefetch invpcid_single ssbd ibrs ibpb stibp vmmcall fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt >> xsaveopt xsavec xgetbv1 xsaves arat umip md_clear arch_capabilities >> bugs : fxsave_leak sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass taa >> bogomips : 4223.99 >> TLB size : 1024 4K pages >> clflush size : 64 >> cache_alignment : 64 >> address sizes : 40 bits physical, 48 bits virtual >> power management: >> >> cpuid.f5cc5a5c16 >> >> CPU 0: >> 0x00000000 0x00: eax=0x0000000d ebx=0x68747541 ecx=0x444d4163 edx=0x69746e65 >> 0x00000001 0x00: eax=0x00000663 ebx=0x00000800 ecx=0xfffab223 edx=0x0f8bfbff >> 0x00000002 0x00: eax=0x00000001 ebx=0x00000000 ecx=0x0000004d edx=0x002c307d >> 0x00000003 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >> 0x00000004 0x00: eax=0x00000121 ebx=0x01c0003f ecx=0x0000003f edx=0x00000001 >> 0x00000004 0x01: eax=0x00000122 ebx=0x01c0003f ecx=0x0000003f edx=0x00000001 >> 0x00000004 0x02: eax=0x00000143 ebx=0x03c0003f ecx=0x00000fff edx=0x00000001 >> 0x00000004 0x03: eax=0x00000163 ebx=0x03c0003f ecx=0x00003fff edx=0x00000006 >> 0x00000005 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000003 edx=0x00000000 >> 0x00000006 0x00: eax=0x00000004 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >> 0x00000007 0x00: eax=0x00000000 ebx=0x009c4fbb ecx=0x00000004 edx=0xac000400 >> 0x00000008 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >> 0x00000009 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >> 0x0000000a 0x00: eax=0x07300402 ebx=0x00000000 ecx=0x00000000 edx=0x00008603 >> 0x0000000b 0x00: eax=0x00000000 ebx=0x00000001 ecx=0x00000100 edx=0x00000000 >> 0x0000000b 0x01: eax=0x00000000 ebx=0x00000001 ecx=0x00000201 edx=0x00000000 >> 0x0000000c 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >> 0x0000000d 0x00: eax=0x0000001f ebx=0x00000440 ecx=0x00000440 edx=0x00000000 >> 0x0000000d 0x01: eax=0x0000000f ebx=0x000003c0 ecx=0x00000000 edx=0x00000000 >> 0x0000000d 0x02: eax=0x00000100 ebx=0x00000240 ecx=0x00000000 edx=0x00000000 >> 0x0000000d 0x03: eax=0x00000040 ebx=0x000003c0 ecx=0x00000000 edx=0x00000000 >> 0x0000000d 0x04: eax=0x00000040 ebx=0x00000400 ecx=0x00000000 edx=0x00000000 >> 0x40000000 0x00: eax=0x40000001 ebx=0x4b4d564b ecx=0x564b4d56 edx=0x0000004d >> 0x40000001 0x00: eax=0x01007afb ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >> 0x80000000 0x00: eax=0x80000008 ebx=0x68747541 ecx=0x444d4163 edx=0x69746e65 >> 0x80000001 0x00: eax=0x00000663 ebx=0x00000000 ecx=0x00000121 edx=0x2d93fbff >> 0x80000002 0x00: eax=0x554d4551 ebx=0x47435420 ecx=0x55504320 edx=0x72657620 >> 0x80000003 0x00: eax=0x6e6f6973 ebx=0x352e3220 ecx=0x0000002b edx=0x00000000 >> 0x80000004 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >> 0x80000005 0x00: eax=0x01ff01ff ebx=0x01ff01ff ecx=0x40020140 edx=0x40020140 >> 0x80000006 0x00: eax=0x00000000 ebx=0x42004200 ecx=0x02008140 edx=0x00808140 >> 0x80000007 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >> 0x80000008 0x00: eax=0x00003028 ebx=0x0100d000 ecx=0x00000000 edx=0x00000000 >> 0x80860000 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >> 0xc0000000 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >> >> >> cpuid.0ac2b19743 >> >> CPU 0: >> 0x00000000 0x00: eax=0x00000016 ebx=0x756e6547 ecx=0x6c65746e edx=0x49656e69 >> 0x00000001 0x00: eax=0x000806ea ebx=0x00000800 ecx=0xfffab223 edx=0x0f8bfbff >> 0x00000002 0x00: eax=0x00000001 ebx=0x00000000 ecx=0x0000004d edx=0x002c307d >> 0x00000003 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >> 0x00000004 0x00: eax=0x00000121 ebx=0x01c0003f ecx=0x0000003f edx=0x00000001 >> 0x00000004 0x01: eax=0x00000122 ebx=0x01c0003f ecx=0x0000003f edx=0x00000001 >> 0x00000004 0x02: eax=0x00000143 ebx=0x03c0003f ecx=0x00000fff edx=0x00000001 >> 0x00000004 0x03: eax=0x00000163 ebx=0x03c0003f ecx=0x00003fff edx=0x00000006 >> 0x00000005 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000003 edx=0x00000000 >> 0x00000006 0x00: eax=0x00000004 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >> 0x00000007 0x00: eax=0x00000000 ebx=0x009c4fbb ecx=0x00000004 edx=0xac000400 >> 0x00000008 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >> 0x00000009 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >> 0x0000000a 0x00: eax=0x07300402 ebx=0x00000000 ecx=0x00000000 edx=0x00008603 >> 0x0000000b 0x00: eax=0x00000000 ebx=0x00000001 ecx=0x00000100 edx=0x00000000 >> 0x0000000b 0x01: eax=0x00000000 ebx=0x00000001 ecx=0x00000201 edx=0x00000000 >> 0x0000000c 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >> 0x0000000d 0x00: eax=0x0000001f ebx=0x00000440 ecx=0x00000440 edx=0x00000000 >> 0x0000000d 0x01: eax=0x0000000f ebx=0x000003c0 ecx=0x00000000 edx=0x00000000 >> 0x0000000d 0x02: eax=0x00000100 ebx=0x00000240 ecx=0x00000000 edx=0x00000000 >> 0x0000000d 0x03: eax=0x00000040 ebx=0x000003c0 ecx=0x00000000 edx=0x00000000 >> 0x0000000d 0x04: eax=0x00000040 ebx=0x00000400 ecx=0x00000000 edx=0x00000000 >> 0x0000000e 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >> 0x0000000f 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >> 0x00000010 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >> 0x00000011 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >> 0x00000012 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >> 0x00000013 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >> 0x00000014 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >> 0x00000015 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >> 0x00000016 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >> 0x40000000 0x00: eax=0x40000001 ebx=0x4b4d564b ecx=0x564b4d56 edx=0x0000004d >> 0x40000001 0x00: eax=0x01007afb ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >> 0x80000000 0x00: eax=0x80000008 ebx=0x756e6547 ecx=0x6c65746e edx=0x49656e69 >> 0x80000001 0x00: eax=0x000806ea ebx=0x00000000 ecx=0x00000121 edx=0x2c100800 >> 0x80000002 0x00: eax=0x65746e49 ebx=0x2952286c ecx=0x726f4320 edx=0x4d542865 >> 0x80000003 0x00: eax=0x37692029 ebx=0x3536382d ecx=0x43205530 edx=0x40205550 >> 0x80000004 0x00: eax=0x392e3120 ebx=0x7a484730 ecx=0x00000000 edx=0x00000000 >> 0x80000005 0x00: eax=0x01ff01ff ebx=0x01ff01ff ecx=0x40020140 edx=0x40020140 >> 0x80000006 0x00: eax=0x00000000 ebx=0x42004200 ecx=0x02008140 edx=0x00808140 >> 0x80000007 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >> 0x80000008 0x00: eax=0x00003027 ebx=0x0100d000 ecx=0x00000000 edx=0x00000000 >> 0x80860000 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >> 0xc0000000 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >> > > I started looking at it. > > Claudio > I wonder how I missed this, the initialization functions for max_x86_cpu_initfn and kvm_cpu_max_instance_init end up being called in the wrong order. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Windows fails to boot after rebase to QEMU master 2021-05-27 10:53 ` Claudio Fontana @ 2021-05-27 11:36 ` Claudio Fontana 2021-05-27 11:51 ` Siddharth Chandrasekaran ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Claudio Fontana @ 2021-05-27 11:36 UTC (permalink / raw) To: Dr. David Alan Gilbert, Philippe Mathieu-Daudé Cc: Siddharth Chandrasekaran, Eduardo Habkost, kvm, Michael S. Tsirkin, Marcelo Tosatti, Richard Henderson, qemu-devel, Cameron Esfahani, Roman Bolshakov, Paolo Bonzini On 5/27/21 12:53 PM, Claudio Fontana wrote: > On 5/27/21 11:48 AM, Claudio Fontana wrote: >> On 5/27/21 11:15 AM, Dr. David Alan Gilbert wrote: >>> * Philippe Mathieu-Daudé (philmd@redhat.com) wrote: >>>> On 5/27/21 10:31 AM, Dr. David Alan Gilbert wrote: >>>>> * Claudio Fontana (cfontana@suse.de) wrote: >>>>>> On 5/26/21 9:30 PM, Dr. David Alan Gilbert wrote: >>>>>>> * Michael S. Tsirkin (mst@redhat.com) wrote: >>>>>>>> On Fri, May 21, 2021 at 11:17:19AM +0200, Siddharth Chandrasekaran wrote: >>>>>>>>> After a rebase to QEMU master, I am having trouble booting windows VMs. >>>>>>>>> Git bisect indicates commit f5cc5a5c1686 ("i386: split cpu accelerators >>>>>>>>> from cpu.c, using AccelCPUClass") to have introduced the issue. I spent >>>>>>>>> some time looking at into it yesterday without much luck. >>>>>>>>> >>>>>>>>> Steps to reproduce: >>>>>>>>> >>>>>>>>> $ ./configure --enable-kvm --disable-xen --target-list=x86_64-softmmu --enable-debug >>>>>>>>> $ make -j `nproc` >>>>>>>>> $ ./build/x86_64-softmmu/qemu-system-x86_64 \ >>>>>>>>> -cpu host,hv_synic,hv_vpindex,hv_time,hv_runtime,hv_stimer,hv_crash \ >>>>>>>>> -enable-kvm \ >>>>>>>>> -name test,debug-threads=on \ >>>>>>>>> -smp 1,threads=1,cores=1,sockets=1 \ >>>>>>>>> -m 4G \ >>>>>>>>> -net nic -net user \ >>>>>>>>> -boot d,menu=on \ >>>>>>>>> -usbdevice tablet \ >>>>>>>>> -vnc :3 \ >>>>>>>>> -machine q35,smm=on \ >>>>>>>>> -drive if=pflash,format=raw,readonly=on,unit=0,file="../OVMF_CODE.secboot.fd" \ >>>>>>>>> -drive if=pflash,format=raw,unit=1,file="../OVMF_VARS.secboot.fd" \ >>>>>>>>> -global ICH9-LPC.disable_s3=1 \ >>>>>>>>> -global driver=cfi.pflash01,property=secure,value=on \ >>>>>>>>> -cdrom "../Windows_Server_2016_14393.ISO" \ >>>>>>>>> -drive file="../win_server_2016.qcow2",format=qcow2,if=none,id=rootfs_drive \ >>>>>>>>> -device ahci,id=ahci \ >>>>>>>>> -device ide-hd,drive=rootfs_drive,bus=ahci.0 >>>>>>>>> >>>>>>>>> If the issue is not obvious, I'd like some pointers on how to go about >>>>>>>>> fixing this issue. >>>>>>>>> >>>>>>>>> ~ Sid. >>>>>>>>> >>>>>>>> >>>>>>>> At a guess this commit inadvertently changed something in the CPU ID. >>>>>>>> I'd start by using a linux guest to dump cpuid before and after the >>>>>>>> change. >>>>>>> >>>>>>> I've not had a chance to do that yet, however I did just end up with a >>>>>>> bisect of a linux guest failure bisecting to the same patch: >>>>>>> >>>>>>> [dgilbert@dgilbert-t580 qemu]$ git bisect bad >>>>>>> f5cc5a5c168674f84bf061cdb307c2d25fba5448 is the first bad commit >>>>>>> commit f5cc5a5c168674f84bf061cdb307c2d25fba5448 >>>>>>> Author: Claudio Fontana <cfontana@suse.de> >>>>>>> Date: Mon Mar 22 14:27:40 2021 +0100 >>>>>>> >>>>>>> i386: split cpu accelerators from cpu.c, using AccelCPUClass >>>>>>> >>>>>>> i386 is the first user of AccelCPUClass, allowing to split >>>>>>> cpu.c into: >>>>>>> >>>>>>> cpu.c cpuid and common x86 cpu functionality >>>>>>> host-cpu.c host x86 cpu functions and "host" cpu type >>>>>>> kvm/kvm-cpu.c KVM x86 AccelCPUClass >>>>>>> hvf/hvf-cpu.c HVF x86 AccelCPUClass >>>>>>> tcg/tcg-cpu.c TCG x86 AccelCPUClass >>>> >>>> Well this is a big commit... I'm not custom to x86 target, and am >>>> having hard time following the cpu host/max change. >>>> >>>> Is it working when you use '-cpu max,...' instead of '-cpu host,'? >>> >>> No; and in fact the cpuid's are almost entirely different with and >>> without this patch! (both with -cpu host). It looks like with this >>> patch we're getting the cpuid for the TCG cpuid rather than the host: >>> >>> Prior to this patch: >>> :/# cat /proc/cpuinfo >>> processor : 0 >>> vendor_id : GenuineIntel >>> cpu family : 6 >>> model : 142 >>> model name : Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz >>> stepping : 10 >>> microcode : 0xe0 >>> cpu MHz : 2111.998 >>> cache size : 16384 KB >>> physical id : 0 >>> siblings : 1 >>> core id : 0 >>> cpu cores : 1 >>> apicid : 0 >>> initial apicid : 0 >>> fpu : yes >>> fpu_exception : yes >>> cpuid level : 22 >>> wp : yes >>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant >>> _tsc arch_perfmon rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_tim >>> er aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid >>> ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 xsaves arat umip md_clear arch_ca >>> pabilities >>> vmx flags : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest shadow_vmcs pml >>> bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa srbds >>> bogomips : 4223.99 >>> clflush size : 64 >>> cache_alignment : 64 >>> address sizes : 39 bits physical, 48 bits virtual >>> power management: >>> >>> With this patch: >>> processor : 0 >>> vendor_id : AuthenticAMD >>> cpu family : 6 >>> model : 6 >>> model name : QEMU TCG CPU version 2.5+ >>> stepping : 3 >>> cpu MHz : 2111.998 >>> cache size : 512 KB >>> physical id : 0 >>> siblings : 1 >>> core id : 0 >>> cpu cores : 1 >>> apicid : 0 >>> initial apicid : 0 >>> fpu : yes >>> fpu_exception : yes >>> cpuid level : 13 >>> wp : yes >>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm nopl cpu >>> id tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_ >>> lm abm 3dnowprefetch invpcid_single ssbd ibrs ibpb stibp vmmcall fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt >>> xsaveopt xsavec xgetbv1 xsaves arat umip md_clear arch_capabilities >>> bugs : fxsave_leak sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass taa >>> bogomips : 4223.99 >>> TLB size : 1024 4K pages >>> clflush size : 64 >>> cache_alignment : 64 >>> address sizes : 40 bits physical, 48 bits virtual >>> power management: >>> >>> cpuid.f5cc5a5c16 >>> >>> CPU 0: >>> 0x00000000 0x00: eax=0x0000000d ebx=0x68747541 ecx=0x444d4163 edx=0x69746e65 >>> 0x00000001 0x00: eax=0x00000663 ebx=0x00000800 ecx=0xfffab223 edx=0x0f8bfbff >>> 0x00000002 0x00: eax=0x00000001 ebx=0x00000000 ecx=0x0000004d edx=0x002c307d >>> 0x00000003 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>> 0x00000004 0x00: eax=0x00000121 ebx=0x01c0003f ecx=0x0000003f edx=0x00000001 >>> 0x00000004 0x01: eax=0x00000122 ebx=0x01c0003f ecx=0x0000003f edx=0x00000001 >>> 0x00000004 0x02: eax=0x00000143 ebx=0x03c0003f ecx=0x00000fff edx=0x00000001 >>> 0x00000004 0x03: eax=0x00000163 ebx=0x03c0003f ecx=0x00003fff edx=0x00000006 >>> 0x00000005 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000003 edx=0x00000000 >>> 0x00000006 0x00: eax=0x00000004 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>> 0x00000007 0x00: eax=0x00000000 ebx=0x009c4fbb ecx=0x00000004 edx=0xac000400 >>> 0x00000008 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>> 0x00000009 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>> 0x0000000a 0x00: eax=0x07300402 ebx=0x00000000 ecx=0x00000000 edx=0x00008603 >>> 0x0000000b 0x00: eax=0x00000000 ebx=0x00000001 ecx=0x00000100 edx=0x00000000 >>> 0x0000000b 0x01: eax=0x00000000 ebx=0x00000001 ecx=0x00000201 edx=0x00000000 >>> 0x0000000c 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>> 0x0000000d 0x00: eax=0x0000001f ebx=0x00000440 ecx=0x00000440 edx=0x00000000 >>> 0x0000000d 0x01: eax=0x0000000f ebx=0x000003c0 ecx=0x00000000 edx=0x00000000 >>> 0x0000000d 0x02: eax=0x00000100 ebx=0x00000240 ecx=0x00000000 edx=0x00000000 >>> 0x0000000d 0x03: eax=0x00000040 ebx=0x000003c0 ecx=0x00000000 edx=0x00000000 >>> 0x0000000d 0x04: eax=0x00000040 ebx=0x00000400 ecx=0x00000000 edx=0x00000000 >>> 0x40000000 0x00: eax=0x40000001 ebx=0x4b4d564b ecx=0x564b4d56 edx=0x0000004d >>> 0x40000001 0x00: eax=0x01007afb ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>> 0x80000000 0x00: eax=0x80000008 ebx=0x68747541 ecx=0x444d4163 edx=0x69746e65 >>> 0x80000001 0x00: eax=0x00000663 ebx=0x00000000 ecx=0x00000121 edx=0x2d93fbff >>> 0x80000002 0x00: eax=0x554d4551 ebx=0x47435420 ecx=0x55504320 edx=0x72657620 >>> 0x80000003 0x00: eax=0x6e6f6973 ebx=0x352e3220 ecx=0x0000002b edx=0x00000000 >>> 0x80000004 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>> 0x80000005 0x00: eax=0x01ff01ff ebx=0x01ff01ff ecx=0x40020140 edx=0x40020140 >>> 0x80000006 0x00: eax=0x00000000 ebx=0x42004200 ecx=0x02008140 edx=0x00808140 >>> 0x80000007 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>> 0x80000008 0x00: eax=0x00003028 ebx=0x0100d000 ecx=0x00000000 edx=0x00000000 >>> 0x80860000 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>> 0xc0000000 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>> >>> >>> cpuid.0ac2b19743 >>> >>> CPU 0: >>> 0x00000000 0x00: eax=0x00000016 ebx=0x756e6547 ecx=0x6c65746e edx=0x49656e69 >>> 0x00000001 0x00: eax=0x000806ea ebx=0x00000800 ecx=0xfffab223 edx=0x0f8bfbff >>> 0x00000002 0x00: eax=0x00000001 ebx=0x00000000 ecx=0x0000004d edx=0x002c307d >>> 0x00000003 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>> 0x00000004 0x00: eax=0x00000121 ebx=0x01c0003f ecx=0x0000003f edx=0x00000001 >>> 0x00000004 0x01: eax=0x00000122 ebx=0x01c0003f ecx=0x0000003f edx=0x00000001 >>> 0x00000004 0x02: eax=0x00000143 ebx=0x03c0003f ecx=0x00000fff edx=0x00000001 >>> 0x00000004 0x03: eax=0x00000163 ebx=0x03c0003f ecx=0x00003fff edx=0x00000006 >>> 0x00000005 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000003 edx=0x00000000 >>> 0x00000006 0x00: eax=0x00000004 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>> 0x00000007 0x00: eax=0x00000000 ebx=0x009c4fbb ecx=0x00000004 edx=0xac000400 >>> 0x00000008 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>> 0x00000009 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>> 0x0000000a 0x00: eax=0x07300402 ebx=0x00000000 ecx=0x00000000 edx=0x00008603 >>> 0x0000000b 0x00: eax=0x00000000 ebx=0x00000001 ecx=0x00000100 edx=0x00000000 >>> 0x0000000b 0x01: eax=0x00000000 ebx=0x00000001 ecx=0x00000201 edx=0x00000000 >>> 0x0000000c 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>> 0x0000000d 0x00: eax=0x0000001f ebx=0x00000440 ecx=0x00000440 edx=0x00000000 >>> 0x0000000d 0x01: eax=0x0000000f ebx=0x000003c0 ecx=0x00000000 edx=0x00000000 >>> 0x0000000d 0x02: eax=0x00000100 ebx=0x00000240 ecx=0x00000000 edx=0x00000000 >>> 0x0000000d 0x03: eax=0x00000040 ebx=0x000003c0 ecx=0x00000000 edx=0x00000000 >>> 0x0000000d 0x04: eax=0x00000040 ebx=0x00000400 ecx=0x00000000 edx=0x00000000 >>> 0x0000000e 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>> 0x0000000f 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>> 0x00000010 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>> 0x00000011 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>> 0x00000012 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>> 0x00000013 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>> 0x00000014 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>> 0x00000015 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>> 0x00000016 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>> 0x40000000 0x00: eax=0x40000001 ebx=0x4b4d564b ecx=0x564b4d56 edx=0x0000004d >>> 0x40000001 0x00: eax=0x01007afb ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>> 0x80000000 0x00: eax=0x80000008 ebx=0x756e6547 ecx=0x6c65746e edx=0x49656e69 >>> 0x80000001 0x00: eax=0x000806ea ebx=0x00000000 ecx=0x00000121 edx=0x2c100800 >>> 0x80000002 0x00: eax=0x65746e49 ebx=0x2952286c ecx=0x726f4320 edx=0x4d542865 >>> 0x80000003 0x00: eax=0x37692029 ebx=0x3536382d ecx=0x43205530 edx=0x40205550 >>> 0x80000004 0x00: eax=0x392e3120 ebx=0x7a484730 ecx=0x00000000 edx=0x00000000 >>> 0x80000005 0x00: eax=0x01ff01ff ebx=0x01ff01ff ecx=0x40020140 edx=0x40020140 >>> 0x80000006 0x00: eax=0x00000000 ebx=0x42004200 ecx=0x02008140 edx=0x00808140 >>> 0x80000007 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>> 0x80000008 0x00: eax=0x00003027 ebx=0x0100d000 ecx=0x00000000 edx=0x00000000 >>> 0x80860000 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>> 0xc0000000 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>> >> >> I started looking at it. >> >> Claudio >> > > I wonder how I missed this, the initialization functions for max_x86_cpu_initfn and kvm_cpu_max_instance_init end up being called in the wrong order. > Just to check whether this is actually the issue we are talking about, Sid et al, could you try this? diff --git a/target/i386/cpu.c b/target/i386/cpu.c index c496bfa1c2..810c46281b 100644 --- a/target/i386/cpu.c +++ b/target/i386/cpu.c @@ -4252,6 +4252,7 @@ static void max_x86_cpu_initfn(Object *obj) object_property_set_str(OBJECT(cpu), "model-id", "QEMU TCG CPU version " QEMU_HW_VERSION, &error_abort); + accel_cpu_instance_init(CPU(cpu)); } static const TypeInfo max_x86_cpu_type_info = { ------------------------------------------------------------------------------------------ Does this band-aid happen to cover-up the issue? I need to think about the proper fix though, any suggestions Paolo, Eduardo? The pickle here is that we'd need to call the accelerator specific initialization of the x86 accel-cpu only after the x86 cpu subclass initfn, otherwise the accel-specific cpu initialization code has no chance to see the subclass (max) trying to set ->max_features. C. ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: Windows fails to boot after rebase to QEMU master 2021-05-27 11:36 ` Claudio Fontana @ 2021-05-27 11:51 ` Siddharth Chandrasekaran 2021-05-27 13:21 ` Claudio Fontana 2021-05-27 13:24 ` Dr. David Alan Gilbert 2 siblings, 0 replies; 14+ messages in thread From: Siddharth Chandrasekaran @ 2021-05-27 11:51 UTC (permalink / raw) To: Claudio Fontana Cc: Dr. David Alan Gilbert, Philippe Mathieu-Daudé, Eduardo Habkost, kvm, Michael S. Tsirkin, Marcelo Tosatti, Richard Henderson, qemu-devel, Cameron Esfahani, Roman Bolshakov, Paolo Bonzini On Thu, May 27, 2021 at 01:36:37PM +0200, Claudio Fontana wrote: > Just to check whether this is actually the issue we are talking about, > Sid et al, could you try this? > > > diff --git a/target/i386/cpu.c b/target/i386/cpu.c > index c496bfa1c2..810c46281b 100644 > --- a/target/i386/cpu.c > +++ b/target/i386/cpu.c > @@ -4252,6 +4252,7 @@ static void max_x86_cpu_initfn(Object *obj) > object_property_set_str(OBJECT(cpu), "model-id", > "QEMU TCG CPU version " QEMU_HW_VERSION, > &error_abort); > + accel_cpu_instance_init(CPU(cpu)); > } > > static const TypeInfo max_x86_cpu_type_info = { > ------------------------------------------------------------------------------------------ > > Does this band-aid happen to cover-up the issue? Yes it does fix the issue for me. Thanks. ~ Sid. > I need to think about the proper fix though, any suggestions Paolo, > Eduardo? > > The pickle here is that we'd need to call the accelerator specific > initialization of the x86 accel-cpu only after the x86 cpu subclass > initfn, otherwise the accel-specific cpu initialization code has no > chance to see the subclass (max) trying to set ->max_features. > > C. Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Windows fails to boot after rebase to QEMU master 2021-05-27 11:36 ` Claudio Fontana 2021-05-27 11:51 ` Siddharth Chandrasekaran @ 2021-05-27 13:21 ` Claudio Fontana 2021-05-27 13:24 ` Dr. David Alan Gilbert 2 siblings, 0 replies; 14+ messages in thread From: Claudio Fontana @ 2021-05-27 13:21 UTC (permalink / raw) To: Philippe Mathieu-Daudé, Eduardo Habkost, Paolo Bonzini Cc: Dr. David Alan Gilbert, Siddharth Chandrasekaran, kvm, Michael S. Tsirkin, Marcelo Tosatti, Richard Henderson, qemu-devel, Cameron Esfahani, Roman Bolshakov, Alex Bennee, Liang Yan On 5/27/21 1:36 PM, Claudio Fontana wrote: > On 5/27/21 12:53 PM, Claudio Fontana wrote: >> On 5/27/21 11:48 AM, Claudio Fontana wrote: >>> On 5/27/21 11:15 AM, Dr. David Alan Gilbert wrote: >>>> * Philippe Mathieu-Daudé (philmd@redhat.com) wrote: >>>>> On 5/27/21 10:31 AM, Dr. David Alan Gilbert wrote: >>>>>> * Claudio Fontana (cfontana@suse.de) wrote: >>>>>>> On 5/26/21 9:30 PM, Dr. David Alan Gilbert wrote: >>>>>>>> * Michael S. Tsirkin (mst@redhat.com) wrote: >>>>>>>>> On Fri, May 21, 2021 at 11:17:19AM +0200, Siddharth Chandrasekaran wrote: >>>>>>>>>> After a rebase to QEMU master, I am having trouble booting windows VMs. >>>>>>>>>> Git bisect indicates commit f5cc5a5c1686 ("i386: split cpu accelerators >>>>>>>>>> from cpu.c, using AccelCPUClass") to have introduced the issue. I spent >>>>>>>>>> some time looking at into it yesterday without much luck. >>>>>>>>>> >>>>>>>>>> Steps to reproduce: >>>>>>>>>> >>>>>>>>>> $ ./configure --enable-kvm --disable-xen --target-list=x86_64-softmmu --enable-debug >>>>>>>>>> $ make -j `nproc` >>>>>>>>>> $ ./build/x86_64-softmmu/qemu-system-x86_64 \ >>>>>>>>>> -cpu host,hv_synic,hv_vpindex,hv_time,hv_runtime,hv_stimer,hv_crash \ >>>>>>>>>> -enable-kvm \ >>>>>>>>>> -name test,debug-threads=on \ >>>>>>>>>> -smp 1,threads=1,cores=1,sockets=1 \ >>>>>>>>>> -m 4G \ >>>>>>>>>> -net nic -net user \ >>>>>>>>>> -boot d,menu=on \ >>>>>>>>>> -usbdevice tablet \ >>>>>>>>>> -vnc :3 \ >>>>>>>>>> -machine q35,smm=on \ >>>>>>>>>> -drive if=pflash,format=raw,readonly=on,unit=0,file="../OVMF_CODE.secboot.fd" \ >>>>>>>>>> -drive if=pflash,format=raw,unit=1,file="../OVMF_VARS.secboot.fd" \ >>>>>>>>>> -global ICH9-LPC.disable_s3=1 \ >>>>>>>>>> -global driver=cfi.pflash01,property=secure,value=on \ >>>>>>>>>> -cdrom "../Windows_Server_2016_14393.ISO" \ >>>>>>>>>> -drive file="../win_server_2016.qcow2",format=qcow2,if=none,id=rootfs_drive \ >>>>>>>>>> -device ahci,id=ahci \ >>>>>>>>>> -device ide-hd,drive=rootfs_drive,bus=ahci.0 >>>>>>>>>> >>>>>>>>>> If the issue is not obvious, I'd like some pointers on how to go about >>>>>>>>>> fixing this issue. >>>>>>>>>> >>>>>>>>>> ~ Sid. >>>>>>>>>> >>>>>>>>> >>>>>>>>> At a guess this commit inadvertently changed something in the CPU ID. >>>>>>>>> I'd start by using a linux guest to dump cpuid before and after the >>>>>>>>> change. >>>>>>>> >>>>>>>> I've not had a chance to do that yet, however I did just end up with a >>>>>>>> bisect of a linux guest failure bisecting to the same patch: >>>>>>>> >>>>>>>> [dgilbert@dgilbert-t580 qemu]$ git bisect bad >>>>>>>> f5cc5a5c168674f84bf061cdb307c2d25fba5448 is the first bad commit >>>>>>>> commit f5cc5a5c168674f84bf061cdb307c2d25fba5448 >>>>>>>> Author: Claudio Fontana <cfontana@suse.de> >>>>>>>> Date: Mon Mar 22 14:27:40 2021 +0100 >>>>>>>> >>>>>>>> i386: split cpu accelerators from cpu.c, using AccelCPUClass >>>>>>>> >>>>>>>> i386 is the first user of AccelCPUClass, allowing to split >>>>>>>> cpu.c into: >>>>>>>> >>>>>>>> cpu.c cpuid and common x86 cpu functionality >>>>>>>> host-cpu.c host x86 cpu functions and "host" cpu type >>>>>>>> kvm/kvm-cpu.c KVM x86 AccelCPUClass >>>>>>>> hvf/hvf-cpu.c HVF x86 AccelCPUClass >>>>>>>> tcg/tcg-cpu.c TCG x86 AccelCPUClass >>>>> >>>>> Well this is a big commit... I'm not custom to x86 target, and am >>>>> having hard time following the cpu host/max change. >>>>> >>>>> Is it working when you use '-cpu max,...' instead of '-cpu host,'? >>>> >>>> No; and in fact the cpuid's are almost entirely different with and >>>> without this patch! (both with -cpu host). It looks like with this >>>> patch we're getting the cpuid for the TCG cpuid rather than the host: >>>> >>>> Prior to this patch: >>>> :/# cat /proc/cpuinfo >>>> processor : 0 >>>> vendor_id : GenuineIntel >>>> cpu family : 6 >>>> model : 142 >>>> model name : Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz >>>> stepping : 10 >>>> microcode : 0xe0 >>>> cpu MHz : 2111.998 >>>> cache size : 16384 KB >>>> physical id : 0 >>>> siblings : 1 >>>> core id : 0 >>>> cpu cores : 1 >>>> apicid : 0 >>>> initial apicid : 0 >>>> fpu : yes >>>> fpu_exception : yes >>>> cpuid level : 22 >>>> wp : yes >>>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant >>>> _tsc arch_perfmon rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_tim >>>> er aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid >>>> ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 xsaves arat umip md_clear arch_ca >>>> pabilities >>>> vmx flags : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest shadow_vmcs pml >>>> bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa srbds >>>> bogomips : 4223.99 >>>> clflush size : 64 >>>> cache_alignment : 64 >>>> address sizes : 39 bits physical, 48 bits virtual >>>> power management: >>>> >>>> With this patch: >>>> processor : 0 >>>> vendor_id : AuthenticAMD >>>> cpu family : 6 >>>> model : 6 >>>> model name : QEMU TCG CPU version 2.5+ >>>> stepping : 3 >>>> cpu MHz : 2111.998 >>>> cache size : 512 KB >>>> physical id : 0 >>>> siblings : 1 >>>> core id : 0 >>>> cpu cores : 1 >>>> apicid : 0 >>>> initial apicid : 0 >>>> fpu : yes >>>> fpu_exception : yes >>>> cpuid level : 13 >>>> wp : yes >>>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm nopl cpu >>>> id tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_ >>>> lm abm 3dnowprefetch invpcid_single ssbd ibrs ibpb stibp vmmcall fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt >>>> xsaveopt xsavec xgetbv1 xsaves arat umip md_clear arch_capabilities >>>> bugs : fxsave_leak sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass taa >>>> bogomips : 4223.99 >>>> TLB size : 1024 4K pages >>>> clflush size : 64 >>>> cache_alignment : 64 >>>> address sizes : 40 bits physical, 48 bits virtual >>>> power management: >>>> >>>> cpuid.f5cc5a5c16 >>>> >>>> CPU 0: >>>> 0x00000000 0x00: eax=0x0000000d ebx=0x68747541 ecx=0x444d4163 edx=0x69746e65 >>>> 0x00000001 0x00: eax=0x00000663 ebx=0x00000800 ecx=0xfffab223 edx=0x0f8bfbff >>>> 0x00000002 0x00: eax=0x00000001 ebx=0x00000000 ecx=0x0000004d edx=0x002c307d >>>> 0x00000003 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>> 0x00000004 0x00: eax=0x00000121 ebx=0x01c0003f ecx=0x0000003f edx=0x00000001 >>>> 0x00000004 0x01: eax=0x00000122 ebx=0x01c0003f ecx=0x0000003f edx=0x00000001 >>>> 0x00000004 0x02: eax=0x00000143 ebx=0x03c0003f ecx=0x00000fff edx=0x00000001 >>>> 0x00000004 0x03: eax=0x00000163 ebx=0x03c0003f ecx=0x00003fff edx=0x00000006 >>>> 0x00000005 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000003 edx=0x00000000 >>>> 0x00000006 0x00: eax=0x00000004 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>> 0x00000007 0x00: eax=0x00000000 ebx=0x009c4fbb ecx=0x00000004 edx=0xac000400 >>>> 0x00000008 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>> 0x00000009 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>> 0x0000000a 0x00: eax=0x07300402 ebx=0x00000000 ecx=0x00000000 edx=0x00008603 >>>> 0x0000000b 0x00: eax=0x00000000 ebx=0x00000001 ecx=0x00000100 edx=0x00000000 >>>> 0x0000000b 0x01: eax=0x00000000 ebx=0x00000001 ecx=0x00000201 edx=0x00000000 >>>> 0x0000000c 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>> 0x0000000d 0x00: eax=0x0000001f ebx=0x00000440 ecx=0x00000440 edx=0x00000000 >>>> 0x0000000d 0x01: eax=0x0000000f ebx=0x000003c0 ecx=0x00000000 edx=0x00000000 >>>> 0x0000000d 0x02: eax=0x00000100 ebx=0x00000240 ecx=0x00000000 edx=0x00000000 >>>> 0x0000000d 0x03: eax=0x00000040 ebx=0x000003c0 ecx=0x00000000 edx=0x00000000 >>>> 0x0000000d 0x04: eax=0x00000040 ebx=0x00000400 ecx=0x00000000 edx=0x00000000 >>>> 0x40000000 0x00: eax=0x40000001 ebx=0x4b4d564b ecx=0x564b4d56 edx=0x0000004d >>>> 0x40000001 0x00: eax=0x01007afb ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>> 0x80000000 0x00: eax=0x80000008 ebx=0x68747541 ecx=0x444d4163 edx=0x69746e65 >>>> 0x80000001 0x00: eax=0x00000663 ebx=0x00000000 ecx=0x00000121 edx=0x2d93fbff >>>> 0x80000002 0x00: eax=0x554d4551 ebx=0x47435420 ecx=0x55504320 edx=0x72657620 >>>> 0x80000003 0x00: eax=0x6e6f6973 ebx=0x352e3220 ecx=0x0000002b edx=0x00000000 >>>> 0x80000004 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>> 0x80000005 0x00: eax=0x01ff01ff ebx=0x01ff01ff ecx=0x40020140 edx=0x40020140 >>>> 0x80000006 0x00: eax=0x00000000 ebx=0x42004200 ecx=0x02008140 edx=0x00808140 >>>> 0x80000007 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>> 0x80000008 0x00: eax=0x00003028 ebx=0x0100d000 ecx=0x00000000 edx=0x00000000 >>>> 0x80860000 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>> 0xc0000000 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>> >>>> >>>> cpuid.0ac2b19743 >>>> >>>> CPU 0: >>>> 0x00000000 0x00: eax=0x00000016 ebx=0x756e6547 ecx=0x6c65746e edx=0x49656e69 >>>> 0x00000001 0x00: eax=0x000806ea ebx=0x00000800 ecx=0xfffab223 edx=0x0f8bfbff >>>> 0x00000002 0x00: eax=0x00000001 ebx=0x00000000 ecx=0x0000004d edx=0x002c307d >>>> 0x00000003 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>> 0x00000004 0x00: eax=0x00000121 ebx=0x01c0003f ecx=0x0000003f edx=0x00000001 >>>> 0x00000004 0x01: eax=0x00000122 ebx=0x01c0003f ecx=0x0000003f edx=0x00000001 >>>> 0x00000004 0x02: eax=0x00000143 ebx=0x03c0003f ecx=0x00000fff edx=0x00000001 >>>> 0x00000004 0x03: eax=0x00000163 ebx=0x03c0003f ecx=0x00003fff edx=0x00000006 >>>> 0x00000005 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000003 edx=0x00000000 >>>> 0x00000006 0x00: eax=0x00000004 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>> 0x00000007 0x00: eax=0x00000000 ebx=0x009c4fbb ecx=0x00000004 edx=0xac000400 >>>> 0x00000008 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>> 0x00000009 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>> 0x0000000a 0x00: eax=0x07300402 ebx=0x00000000 ecx=0x00000000 edx=0x00008603 >>>> 0x0000000b 0x00: eax=0x00000000 ebx=0x00000001 ecx=0x00000100 edx=0x00000000 >>>> 0x0000000b 0x01: eax=0x00000000 ebx=0x00000001 ecx=0x00000201 edx=0x00000000 >>>> 0x0000000c 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>> 0x0000000d 0x00: eax=0x0000001f ebx=0x00000440 ecx=0x00000440 edx=0x00000000 >>>> 0x0000000d 0x01: eax=0x0000000f ebx=0x000003c0 ecx=0x00000000 edx=0x00000000 >>>> 0x0000000d 0x02: eax=0x00000100 ebx=0x00000240 ecx=0x00000000 edx=0x00000000 >>>> 0x0000000d 0x03: eax=0x00000040 ebx=0x000003c0 ecx=0x00000000 edx=0x00000000 >>>> 0x0000000d 0x04: eax=0x00000040 ebx=0x00000400 ecx=0x00000000 edx=0x00000000 >>>> 0x0000000e 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>> 0x0000000f 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>> 0x00000010 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>> 0x00000011 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>> 0x00000012 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>> 0x00000013 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>> 0x00000014 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>> 0x00000015 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>> 0x00000016 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>> 0x40000000 0x00: eax=0x40000001 ebx=0x4b4d564b ecx=0x564b4d56 edx=0x0000004d >>>> 0x40000001 0x00: eax=0x01007afb ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>> 0x80000000 0x00: eax=0x80000008 ebx=0x756e6547 ecx=0x6c65746e edx=0x49656e69 >>>> 0x80000001 0x00: eax=0x000806ea ebx=0x00000000 ecx=0x00000121 edx=0x2c100800 >>>> 0x80000002 0x00: eax=0x65746e49 ebx=0x2952286c ecx=0x726f4320 edx=0x4d542865 >>>> 0x80000003 0x00: eax=0x37692029 ebx=0x3536382d ecx=0x43205530 edx=0x40205550 >>>> 0x80000004 0x00: eax=0x392e3120 ebx=0x7a484730 ecx=0x00000000 edx=0x00000000 >>>> 0x80000005 0x00: eax=0x01ff01ff ebx=0x01ff01ff ecx=0x40020140 edx=0x40020140 >>>> 0x80000006 0x00: eax=0x00000000 ebx=0x42004200 ecx=0x02008140 edx=0x00808140 >>>> 0x80000007 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>> 0x80000008 0x00: eax=0x00003027 ebx=0x0100d000 ecx=0x00000000 edx=0x00000000 >>>> 0x80860000 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>> 0xc0000000 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>> >>> >>> I started looking at it. >>> >>> Claudio >>> >> >> I wonder how I missed this, the initialization functions for max_x86_cpu_initfn and kvm_cpu_max_instance_init end up being called in the wrong order. >> > > > Just to check whether this is actually the issue we are talking about, Sid et al, could you try this? > > > diff --git a/target/i386/cpu.c b/target/i386/cpu.c > index c496bfa1c2..810c46281b 100644 > --- a/target/i386/cpu.c > +++ b/target/i386/cpu.c > @@ -4252,6 +4252,7 @@ static void max_x86_cpu_initfn(Object *obj) > object_property_set_str(OBJECT(cpu), "model-id", > "QEMU TCG CPU version " QEMU_HW_VERSION, > &error_abort); > + accel_cpu_instance_init(CPU(cpu)); > } > > static const TypeInfo max_x86_cpu_type_info = { > ------------------------------------------------------------------------------------------ > > Does this band-aid happen to cover-up the issue? > > > I need to think about the proper fix though, any suggestions Paolo, Eduardo? > > The pickle here is that we'd need to call the accelerator specific initialization of the x86 accel-cpu only after the x86 cpu subclass initfn, > otherwise the accel-specific cpu initialization code has no chance to see the subclass (max) trying to set ->max_features. > > C. > thinking about this, maybe here we'd need something similar to what is present in ARM with "arm_cpu_post_init". The difficulty here is that the best place for accel_cpu_instance_init to be called is after the whole CPU class hierarchy is already initialized, in order to take into account "max", "host" etc, since the accel cpu initialization depends on whether max_features is on or not. Thoughts? Thanks, Claudio ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Windows fails to boot after rebase to QEMU master 2021-05-27 11:36 ` Claudio Fontana 2021-05-27 11:51 ` Siddharth Chandrasekaran 2021-05-27 13:21 ` Claudio Fontana @ 2021-05-27 13:24 ` Dr. David Alan Gilbert 2021-05-27 18:43 ` Claudio Fontana 2 siblings, 1 reply; 14+ messages in thread From: Dr. David Alan Gilbert @ 2021-05-27 13:24 UTC (permalink / raw) To: Claudio Fontana Cc: Philippe Mathieu-Daudé, Siddharth Chandrasekaran, Eduardo Habkost, kvm, Michael S. Tsirkin, Marcelo Tosatti, Richard Henderson, qemu-devel, Cameron Esfahani, Roman Bolshakov, Paolo Bonzini * Claudio Fontana (cfontana@suse.de) wrote: > On 5/27/21 12:53 PM, Claudio Fontana wrote: > > On 5/27/21 11:48 AM, Claudio Fontana wrote: > >> On 5/27/21 11:15 AM, Dr. David Alan Gilbert wrote: > >>> * Philippe Mathieu-Daudé (philmd@redhat.com) wrote: > >>>> On 5/27/21 10:31 AM, Dr. David Alan Gilbert wrote: > >>>>> * Claudio Fontana (cfontana@suse.de) wrote: > >>>>>> On 5/26/21 9:30 PM, Dr. David Alan Gilbert wrote: > >>>>>>> * Michael S. Tsirkin (mst@redhat.com) wrote: > >>>>>>>> On Fri, May 21, 2021 at 11:17:19AM +0200, Siddharth Chandrasekaran wrote: > >>>>>>>>> After a rebase to QEMU master, I am having trouble booting windows VMs. > >>>>>>>>> Git bisect indicates commit f5cc5a5c1686 ("i386: split cpu accelerators > >>>>>>>>> from cpu.c, using AccelCPUClass") to have introduced the issue. I spent > >>>>>>>>> some time looking at into it yesterday without much luck. > >>>>>>>>> > >>>>>>>>> Steps to reproduce: > >>>>>>>>> > >>>>>>>>> $ ./configure --enable-kvm --disable-xen --target-list=x86_64-softmmu --enable-debug > >>>>>>>>> $ make -j `nproc` > >>>>>>>>> $ ./build/x86_64-softmmu/qemu-system-x86_64 \ > >>>>>>>>> -cpu host,hv_synic,hv_vpindex,hv_time,hv_runtime,hv_stimer,hv_crash \ > >>>>>>>>> -enable-kvm \ > >>>>>>>>> -name test,debug-threads=on \ > >>>>>>>>> -smp 1,threads=1,cores=1,sockets=1 \ > >>>>>>>>> -m 4G \ > >>>>>>>>> -net nic -net user \ > >>>>>>>>> -boot d,menu=on \ > >>>>>>>>> -usbdevice tablet \ > >>>>>>>>> -vnc :3 \ > >>>>>>>>> -machine q35,smm=on \ > >>>>>>>>> -drive if=pflash,format=raw,readonly=on,unit=0,file="../OVMF_CODE.secboot.fd" \ > >>>>>>>>> -drive if=pflash,format=raw,unit=1,file="../OVMF_VARS.secboot.fd" \ > >>>>>>>>> -global ICH9-LPC.disable_s3=1 \ > >>>>>>>>> -global driver=cfi.pflash01,property=secure,value=on \ > >>>>>>>>> -cdrom "../Windows_Server_2016_14393.ISO" \ > >>>>>>>>> -drive file="../win_server_2016.qcow2",format=qcow2,if=none,id=rootfs_drive \ > >>>>>>>>> -device ahci,id=ahci \ > >>>>>>>>> -device ide-hd,drive=rootfs_drive,bus=ahci.0 > >>>>>>>>> > >>>>>>>>> If the issue is not obvious, I'd like some pointers on how to go about > >>>>>>>>> fixing this issue. > >>>>>>>>> > >>>>>>>>> ~ Sid. > >>>>>>>>> > >>>>>>>> > >>>>>>>> At a guess this commit inadvertently changed something in the CPU ID. > >>>>>>>> I'd start by using a linux guest to dump cpuid before and after the > >>>>>>>> change. > >>>>>>> > >>>>>>> I've not had a chance to do that yet, however I did just end up with a > >>>>>>> bisect of a linux guest failure bisecting to the same patch: > >>>>>>> > >>>>>>> [dgilbert@dgilbert-t580 qemu]$ git bisect bad > >>>>>>> f5cc5a5c168674f84bf061cdb307c2d25fba5448 is the first bad commit > >>>>>>> commit f5cc5a5c168674f84bf061cdb307c2d25fba5448 > >>>>>>> Author: Claudio Fontana <cfontana@suse.de> > >>>>>>> Date: Mon Mar 22 14:27:40 2021 +0100 > >>>>>>> > >>>>>>> i386: split cpu accelerators from cpu.c, using AccelCPUClass > >>>>>>> > >>>>>>> i386 is the first user of AccelCPUClass, allowing to split > >>>>>>> cpu.c into: > >>>>>>> > >>>>>>> cpu.c cpuid and common x86 cpu functionality > >>>>>>> host-cpu.c host x86 cpu functions and "host" cpu type > >>>>>>> kvm/kvm-cpu.c KVM x86 AccelCPUClass > >>>>>>> hvf/hvf-cpu.c HVF x86 AccelCPUClass > >>>>>>> tcg/tcg-cpu.c TCG x86 AccelCPUClass > >>>> > >>>> Well this is a big commit... I'm not custom to x86 target, and am > >>>> having hard time following the cpu host/max change. > >>>> > >>>> Is it working when you use '-cpu max,...' instead of '-cpu host,'? > >>> > >>> No; and in fact the cpuid's are almost entirely different with and > >>> without this patch! (both with -cpu host). It looks like with this > >>> patch we're getting the cpuid for the TCG cpuid rather than the host: > >>> > >>> Prior to this patch: > >>> :/# cat /proc/cpuinfo > >>> processor : 0 > >>> vendor_id : GenuineIntel > >>> cpu family : 6 > >>> model : 142 > >>> model name : Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz > >>> stepping : 10 > >>> microcode : 0xe0 > >>> cpu MHz : 2111.998 > >>> cache size : 16384 KB > >>> physical id : 0 > >>> siblings : 1 > >>> core id : 0 > >>> cpu cores : 1 > >>> apicid : 0 > >>> initial apicid : 0 > >>> fpu : yes > >>> fpu_exception : yes > >>> cpuid level : 22 > >>> wp : yes > >>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant > >>> _tsc arch_perfmon rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_tim > >>> er aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid > >>> ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 xsaves arat umip md_clear arch_ca > >>> pabilities > >>> vmx flags : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest shadow_vmcs pml > >>> bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa srbds > >>> bogomips : 4223.99 > >>> clflush size : 64 > >>> cache_alignment : 64 > >>> address sizes : 39 bits physical, 48 bits virtual > >>> power management: > >>> > >>> With this patch: > >>> processor : 0 > >>> vendor_id : AuthenticAMD > >>> cpu family : 6 > >>> model : 6 > >>> model name : QEMU TCG CPU version 2.5+ > >>> stepping : 3 > >>> cpu MHz : 2111.998 > >>> cache size : 512 KB > >>> physical id : 0 > >>> siblings : 1 > >>> core id : 0 > >>> cpu cores : 1 > >>> apicid : 0 > >>> initial apicid : 0 > >>> fpu : yes > >>> fpu_exception : yes > >>> cpuid level : 13 > >>> wp : yes > >>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm nopl cpu > >>> id tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_ > >>> lm abm 3dnowprefetch invpcid_single ssbd ibrs ibpb stibp vmmcall fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt > >>> xsaveopt xsavec xgetbv1 xsaves arat umip md_clear arch_capabilities > >>> bugs : fxsave_leak sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass taa > >>> bogomips : 4223.99 > >>> TLB size : 1024 4K pages > >>> clflush size : 64 > >>> cache_alignment : 64 > >>> address sizes : 40 bits physical, 48 bits virtual > >>> power management: > >>> > >>> cpuid.f5cc5a5c16 > >>> > >>> CPU 0: > >>> 0x00000000 0x00: eax=0x0000000d ebx=0x68747541 ecx=0x444d4163 edx=0x69746e65 > >>> 0x00000001 0x00: eax=0x00000663 ebx=0x00000800 ecx=0xfffab223 edx=0x0f8bfbff > >>> 0x00000002 0x00: eax=0x00000001 ebx=0x00000000 ecx=0x0000004d edx=0x002c307d > >>> 0x00000003 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > >>> 0x00000004 0x00: eax=0x00000121 ebx=0x01c0003f ecx=0x0000003f edx=0x00000001 > >>> 0x00000004 0x01: eax=0x00000122 ebx=0x01c0003f ecx=0x0000003f edx=0x00000001 > >>> 0x00000004 0x02: eax=0x00000143 ebx=0x03c0003f ecx=0x00000fff edx=0x00000001 > >>> 0x00000004 0x03: eax=0x00000163 ebx=0x03c0003f ecx=0x00003fff edx=0x00000006 > >>> 0x00000005 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000003 edx=0x00000000 > >>> 0x00000006 0x00: eax=0x00000004 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > >>> 0x00000007 0x00: eax=0x00000000 ebx=0x009c4fbb ecx=0x00000004 edx=0xac000400 > >>> 0x00000008 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > >>> 0x00000009 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > >>> 0x0000000a 0x00: eax=0x07300402 ebx=0x00000000 ecx=0x00000000 edx=0x00008603 > >>> 0x0000000b 0x00: eax=0x00000000 ebx=0x00000001 ecx=0x00000100 edx=0x00000000 > >>> 0x0000000b 0x01: eax=0x00000000 ebx=0x00000001 ecx=0x00000201 edx=0x00000000 > >>> 0x0000000c 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > >>> 0x0000000d 0x00: eax=0x0000001f ebx=0x00000440 ecx=0x00000440 edx=0x00000000 > >>> 0x0000000d 0x01: eax=0x0000000f ebx=0x000003c0 ecx=0x00000000 edx=0x00000000 > >>> 0x0000000d 0x02: eax=0x00000100 ebx=0x00000240 ecx=0x00000000 edx=0x00000000 > >>> 0x0000000d 0x03: eax=0x00000040 ebx=0x000003c0 ecx=0x00000000 edx=0x00000000 > >>> 0x0000000d 0x04: eax=0x00000040 ebx=0x00000400 ecx=0x00000000 edx=0x00000000 > >>> 0x40000000 0x00: eax=0x40000001 ebx=0x4b4d564b ecx=0x564b4d56 edx=0x0000004d > >>> 0x40000001 0x00: eax=0x01007afb ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > >>> 0x80000000 0x00: eax=0x80000008 ebx=0x68747541 ecx=0x444d4163 edx=0x69746e65 > >>> 0x80000001 0x00: eax=0x00000663 ebx=0x00000000 ecx=0x00000121 edx=0x2d93fbff > >>> 0x80000002 0x00: eax=0x554d4551 ebx=0x47435420 ecx=0x55504320 edx=0x72657620 > >>> 0x80000003 0x00: eax=0x6e6f6973 ebx=0x352e3220 ecx=0x0000002b edx=0x00000000 > >>> 0x80000004 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > >>> 0x80000005 0x00: eax=0x01ff01ff ebx=0x01ff01ff ecx=0x40020140 edx=0x40020140 > >>> 0x80000006 0x00: eax=0x00000000 ebx=0x42004200 ecx=0x02008140 edx=0x00808140 > >>> 0x80000007 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > >>> 0x80000008 0x00: eax=0x00003028 ebx=0x0100d000 ecx=0x00000000 edx=0x00000000 > >>> 0x80860000 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > >>> 0xc0000000 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > >>> > >>> > >>> cpuid.0ac2b19743 > >>> > >>> CPU 0: > >>> 0x00000000 0x00: eax=0x00000016 ebx=0x756e6547 ecx=0x6c65746e edx=0x49656e69 > >>> 0x00000001 0x00: eax=0x000806ea ebx=0x00000800 ecx=0xfffab223 edx=0x0f8bfbff > >>> 0x00000002 0x00: eax=0x00000001 ebx=0x00000000 ecx=0x0000004d edx=0x002c307d > >>> 0x00000003 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > >>> 0x00000004 0x00: eax=0x00000121 ebx=0x01c0003f ecx=0x0000003f edx=0x00000001 > >>> 0x00000004 0x01: eax=0x00000122 ebx=0x01c0003f ecx=0x0000003f edx=0x00000001 > >>> 0x00000004 0x02: eax=0x00000143 ebx=0x03c0003f ecx=0x00000fff edx=0x00000001 > >>> 0x00000004 0x03: eax=0x00000163 ebx=0x03c0003f ecx=0x00003fff edx=0x00000006 > >>> 0x00000005 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000003 edx=0x00000000 > >>> 0x00000006 0x00: eax=0x00000004 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > >>> 0x00000007 0x00: eax=0x00000000 ebx=0x009c4fbb ecx=0x00000004 edx=0xac000400 > >>> 0x00000008 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > >>> 0x00000009 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > >>> 0x0000000a 0x00: eax=0x07300402 ebx=0x00000000 ecx=0x00000000 edx=0x00008603 > >>> 0x0000000b 0x00: eax=0x00000000 ebx=0x00000001 ecx=0x00000100 edx=0x00000000 > >>> 0x0000000b 0x01: eax=0x00000000 ebx=0x00000001 ecx=0x00000201 edx=0x00000000 > >>> 0x0000000c 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > >>> 0x0000000d 0x00: eax=0x0000001f ebx=0x00000440 ecx=0x00000440 edx=0x00000000 > >>> 0x0000000d 0x01: eax=0x0000000f ebx=0x000003c0 ecx=0x00000000 edx=0x00000000 > >>> 0x0000000d 0x02: eax=0x00000100 ebx=0x00000240 ecx=0x00000000 edx=0x00000000 > >>> 0x0000000d 0x03: eax=0x00000040 ebx=0x000003c0 ecx=0x00000000 edx=0x00000000 > >>> 0x0000000d 0x04: eax=0x00000040 ebx=0x00000400 ecx=0x00000000 edx=0x00000000 > >>> 0x0000000e 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > >>> 0x0000000f 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > >>> 0x00000010 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > >>> 0x00000011 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > >>> 0x00000012 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > >>> 0x00000013 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > >>> 0x00000014 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > >>> 0x00000015 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > >>> 0x00000016 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > >>> 0x40000000 0x00: eax=0x40000001 ebx=0x4b4d564b ecx=0x564b4d56 edx=0x0000004d > >>> 0x40000001 0x00: eax=0x01007afb ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > >>> 0x80000000 0x00: eax=0x80000008 ebx=0x756e6547 ecx=0x6c65746e edx=0x49656e69 > >>> 0x80000001 0x00: eax=0x000806ea ebx=0x00000000 ecx=0x00000121 edx=0x2c100800 > >>> 0x80000002 0x00: eax=0x65746e49 ebx=0x2952286c ecx=0x726f4320 edx=0x4d542865 > >>> 0x80000003 0x00: eax=0x37692029 ebx=0x3536382d ecx=0x43205530 edx=0x40205550 > >>> 0x80000004 0x00: eax=0x392e3120 ebx=0x7a484730 ecx=0x00000000 edx=0x00000000 > >>> 0x80000005 0x00: eax=0x01ff01ff ebx=0x01ff01ff ecx=0x40020140 edx=0x40020140 > >>> 0x80000006 0x00: eax=0x00000000 ebx=0x42004200 ecx=0x02008140 edx=0x00808140 > >>> 0x80000007 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > >>> 0x80000008 0x00: eax=0x00003027 ebx=0x0100d000 ecx=0x00000000 edx=0x00000000 > >>> 0x80860000 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > >>> 0xc0000000 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > >>> > >> > >> I started looking at it. > >> > >> Claudio > >> > > > > I wonder how I missed this, the initialization functions for max_x86_cpu_initfn and kvm_cpu_max_instance_init end up being called in the wrong order. > > > > > Just to check whether this is actually the issue we are talking about, Sid et al, could you try this? > > > diff --git a/target/i386/cpu.c b/target/i386/cpu.c > index c496bfa1c2..810c46281b 100644 > --- a/target/i386/cpu.c > +++ b/target/i386/cpu.c > @@ -4252,6 +4252,7 @@ static void max_x86_cpu_initfn(Object *obj) > object_property_set_str(OBJECT(cpu), "model-id", > "QEMU TCG CPU version " QEMU_HW_VERSION, > &error_abort); > + accel_cpu_instance_init(CPU(cpu)); > } > > static const TypeInfo max_x86_cpu_type_info = { > ------------------------------------------------------------------------------------------ > > Does this band-aid happen to cover-up the issue? I think it mostly does - thanks; however the address widths are still wrong: address sizes : 40 bits physical, 48 bits virtual where as my little laptop can only think in 39bits physical; so I think that's still coming through from the TCG def. Dave > > I need to think about the proper fix though, any suggestions Paolo, Eduardo? > > The pickle here is that we'd need to call the accelerator specific initialization of the x86 accel-cpu only after the x86 cpu subclass initfn, > otherwise the accel-specific cpu initialization code has no chance to see the subclass (max) trying to set ->max_features. > > C. > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Windows fails to boot after rebase to QEMU master 2021-05-27 13:24 ` Dr. David Alan Gilbert @ 2021-05-27 18:43 ` Claudio Fontana 0 siblings, 0 replies; 14+ messages in thread From: Claudio Fontana @ 2021-05-27 18:43 UTC (permalink / raw) To: Dr. David Alan Gilbert Cc: Philippe Mathieu-Daudé, Siddharth Chandrasekaran, Eduardo Habkost, kvm, Michael S. Tsirkin, Marcelo Tosatti, Richard Henderson, qemu-devel, Cameron Esfahani, Roman Bolshakov, Paolo Bonzini On 5/27/21 3:24 PM, Dr. David Alan Gilbert wrote: > * Claudio Fontana (cfontana@suse.de) wrote: >> On 5/27/21 12:53 PM, Claudio Fontana wrote: >>> On 5/27/21 11:48 AM, Claudio Fontana wrote: >>>> On 5/27/21 11:15 AM, Dr. David Alan Gilbert wrote: >>>>> * Philippe Mathieu-Daudé (philmd@redhat.com) wrote: >>>>>> On 5/27/21 10:31 AM, Dr. David Alan Gilbert wrote: >>>>>>> * Claudio Fontana (cfontana@suse.de) wrote: >>>>>>>> On 5/26/21 9:30 PM, Dr. David Alan Gilbert wrote: >>>>>>>>> * Michael S. Tsirkin (mst@redhat.com) wrote: >>>>>>>>>> On Fri, May 21, 2021 at 11:17:19AM +0200, Siddharth Chandrasekaran wrote: >>>>>>>>>>> After a rebase to QEMU master, I am having trouble booting windows VMs. >>>>>>>>>>> Git bisect indicates commit f5cc5a5c1686 ("i386: split cpu accelerators >>>>>>>>>>> from cpu.c, using AccelCPUClass") to have introduced the issue. I spent >>>>>>>>>>> some time looking at into it yesterday without much luck. >>>>>>>>>>> >>>>>>>>>>> Steps to reproduce: >>>>>>>>>>> >>>>>>>>>>> $ ./configure --enable-kvm --disable-xen --target-list=x86_64-softmmu --enable-debug >>>>>>>>>>> $ make -j `nproc` >>>>>>>>>>> $ ./build/x86_64-softmmu/qemu-system-x86_64 \ >>>>>>>>>>> -cpu host,hv_synic,hv_vpindex,hv_time,hv_runtime,hv_stimer,hv_crash \ >>>>>>>>>>> -enable-kvm \ >>>>>>>>>>> -name test,debug-threads=on \ >>>>>>>>>>> -smp 1,threads=1,cores=1,sockets=1 \ >>>>>>>>>>> -m 4G \ >>>>>>>>>>> -net nic -net user \ >>>>>>>>>>> -boot d,menu=on \ >>>>>>>>>>> -usbdevice tablet \ >>>>>>>>>>> -vnc :3 \ >>>>>>>>>>> -machine q35,smm=on \ >>>>>>>>>>> -drive if=pflash,format=raw,readonly=on,unit=0,file="../OVMF_CODE.secboot.fd" \ >>>>>>>>>>> -drive if=pflash,format=raw,unit=1,file="../OVMF_VARS.secboot.fd" \ >>>>>>>>>>> -global ICH9-LPC.disable_s3=1 \ >>>>>>>>>>> -global driver=cfi.pflash01,property=secure,value=on \ >>>>>>>>>>> -cdrom "../Windows_Server_2016_14393.ISO" \ >>>>>>>>>>> -drive file="../win_server_2016.qcow2",format=qcow2,if=none,id=rootfs_drive \ >>>>>>>>>>> -device ahci,id=ahci \ >>>>>>>>>>> -device ide-hd,drive=rootfs_drive,bus=ahci.0 >>>>>>>>>>> >>>>>>>>>>> If the issue is not obvious, I'd like some pointers on how to go about >>>>>>>>>>> fixing this issue. >>>>>>>>>>> >>>>>>>>>>> ~ Sid. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> At a guess this commit inadvertently changed something in the CPU ID. >>>>>>>>>> I'd start by using a linux guest to dump cpuid before and after the >>>>>>>>>> change. >>>>>>>>> >>>>>>>>> I've not had a chance to do that yet, however I did just end up with a >>>>>>>>> bisect of a linux guest failure bisecting to the same patch: >>>>>>>>> >>>>>>>>> [dgilbert@dgilbert-t580 qemu]$ git bisect bad >>>>>>>>> f5cc5a5c168674f84bf061cdb307c2d25fba5448 is the first bad commit >>>>>>>>> commit f5cc5a5c168674f84bf061cdb307c2d25fba5448 >>>>>>>>> Author: Claudio Fontana <cfontana@suse.de> >>>>>>>>> Date: Mon Mar 22 14:27:40 2021 +0100 >>>>>>>>> >>>>>>>>> i386: split cpu accelerators from cpu.c, using AccelCPUClass >>>>>>>>> >>>>>>>>> i386 is the first user of AccelCPUClass, allowing to split >>>>>>>>> cpu.c into: >>>>>>>>> >>>>>>>>> cpu.c cpuid and common x86 cpu functionality >>>>>>>>> host-cpu.c host x86 cpu functions and "host" cpu type >>>>>>>>> kvm/kvm-cpu.c KVM x86 AccelCPUClass >>>>>>>>> hvf/hvf-cpu.c HVF x86 AccelCPUClass >>>>>>>>> tcg/tcg-cpu.c TCG x86 AccelCPUClass >>>>>> >>>>>> Well this is a big commit... I'm not custom to x86 target, and am >>>>>> having hard time following the cpu host/max change. >>>>>> >>>>>> Is it working when you use '-cpu max,...' instead of '-cpu host,'? >>>>> >>>>> No; and in fact the cpuid's are almost entirely different with and >>>>> without this patch! (both with -cpu host). It looks like with this >>>>> patch we're getting the cpuid for the TCG cpuid rather than the host: >>>>> >>>>> Prior to this patch: >>>>> :/# cat /proc/cpuinfo >>>>> processor : 0 >>>>> vendor_id : GenuineIntel >>>>> cpu family : 6 >>>>> model : 142 >>>>> model name : Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz >>>>> stepping : 10 >>>>> microcode : 0xe0 >>>>> cpu MHz : 2111.998 >>>>> cache size : 16384 KB >>>>> physical id : 0 >>>>> siblings : 1 >>>>> core id : 0 >>>>> cpu cores : 1 >>>>> apicid : 0 >>>>> initial apicid : 0 >>>>> fpu : yes >>>>> fpu_exception : yes >>>>> cpuid level : 22 >>>>> wp : yes >>>>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant >>>>> _tsc arch_perfmon rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_tim >>>>> er aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid >>>>> ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 xsaves arat umip md_clear arch_ca >>>>> pabilities >>>>> vmx flags : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest shadow_vmcs pml >>>>> bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa srbds >>>>> bogomips : 4223.99 >>>>> clflush size : 64 >>>>> cache_alignment : 64 >>>>> address sizes : 39 bits physical, 48 bits virtual >>>>> power management: >>>>> >>>>> With this patch: >>>>> processor : 0 >>>>> vendor_id : AuthenticAMD >>>>> cpu family : 6 >>>>> model : 6 >>>>> model name : QEMU TCG CPU version 2.5+ >>>>> stepping : 3 >>>>> cpu MHz : 2111.998 >>>>> cache size : 512 KB >>>>> physical id : 0 >>>>> siblings : 1 >>>>> core id : 0 >>>>> cpu cores : 1 >>>>> apicid : 0 >>>>> initial apicid : 0 >>>>> fpu : yes >>>>> fpu_exception : yes >>>>> cpuid level : 13 >>>>> wp : yes >>>>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm nopl cpu >>>>> id tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_ >>>>> lm abm 3dnowprefetch invpcid_single ssbd ibrs ibpb stibp vmmcall fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt >>>>> xsaveopt xsavec xgetbv1 xsaves arat umip md_clear arch_capabilities >>>>> bugs : fxsave_leak sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass taa >>>>> bogomips : 4223.99 >>>>> TLB size : 1024 4K pages >>>>> clflush size : 64 >>>>> cache_alignment : 64 >>>>> address sizes : 40 bits physical, 48 bits virtual >>>>> power management: >>>>> >>>>> cpuid.f5cc5a5c16 >>>>> >>>>> CPU 0: >>>>> 0x00000000 0x00: eax=0x0000000d ebx=0x68747541 ecx=0x444d4163 edx=0x69746e65 >>>>> 0x00000001 0x00: eax=0x00000663 ebx=0x00000800 ecx=0xfffab223 edx=0x0f8bfbff >>>>> 0x00000002 0x00: eax=0x00000001 ebx=0x00000000 ecx=0x0000004d edx=0x002c307d >>>>> 0x00000003 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>>> 0x00000004 0x00: eax=0x00000121 ebx=0x01c0003f ecx=0x0000003f edx=0x00000001 >>>>> 0x00000004 0x01: eax=0x00000122 ebx=0x01c0003f ecx=0x0000003f edx=0x00000001 >>>>> 0x00000004 0x02: eax=0x00000143 ebx=0x03c0003f ecx=0x00000fff edx=0x00000001 >>>>> 0x00000004 0x03: eax=0x00000163 ebx=0x03c0003f ecx=0x00003fff edx=0x00000006 >>>>> 0x00000005 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000003 edx=0x00000000 >>>>> 0x00000006 0x00: eax=0x00000004 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>>> 0x00000007 0x00: eax=0x00000000 ebx=0x009c4fbb ecx=0x00000004 edx=0xac000400 >>>>> 0x00000008 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>>> 0x00000009 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>>> 0x0000000a 0x00: eax=0x07300402 ebx=0x00000000 ecx=0x00000000 edx=0x00008603 >>>>> 0x0000000b 0x00: eax=0x00000000 ebx=0x00000001 ecx=0x00000100 edx=0x00000000 >>>>> 0x0000000b 0x01: eax=0x00000000 ebx=0x00000001 ecx=0x00000201 edx=0x00000000 >>>>> 0x0000000c 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>>> 0x0000000d 0x00: eax=0x0000001f ebx=0x00000440 ecx=0x00000440 edx=0x00000000 >>>>> 0x0000000d 0x01: eax=0x0000000f ebx=0x000003c0 ecx=0x00000000 edx=0x00000000 >>>>> 0x0000000d 0x02: eax=0x00000100 ebx=0x00000240 ecx=0x00000000 edx=0x00000000 >>>>> 0x0000000d 0x03: eax=0x00000040 ebx=0x000003c0 ecx=0x00000000 edx=0x00000000 >>>>> 0x0000000d 0x04: eax=0x00000040 ebx=0x00000400 ecx=0x00000000 edx=0x00000000 >>>>> 0x40000000 0x00: eax=0x40000001 ebx=0x4b4d564b ecx=0x564b4d56 edx=0x0000004d >>>>> 0x40000001 0x00: eax=0x01007afb ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>>> 0x80000000 0x00: eax=0x80000008 ebx=0x68747541 ecx=0x444d4163 edx=0x69746e65 >>>>> 0x80000001 0x00: eax=0x00000663 ebx=0x00000000 ecx=0x00000121 edx=0x2d93fbff >>>>> 0x80000002 0x00: eax=0x554d4551 ebx=0x47435420 ecx=0x55504320 edx=0x72657620 >>>>> 0x80000003 0x00: eax=0x6e6f6973 ebx=0x352e3220 ecx=0x0000002b edx=0x00000000 >>>>> 0x80000004 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>>> 0x80000005 0x00: eax=0x01ff01ff ebx=0x01ff01ff ecx=0x40020140 edx=0x40020140 >>>>> 0x80000006 0x00: eax=0x00000000 ebx=0x42004200 ecx=0x02008140 edx=0x00808140 >>>>> 0x80000007 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>>> 0x80000008 0x00: eax=0x00003028 ebx=0x0100d000 ecx=0x00000000 edx=0x00000000 >>>>> 0x80860000 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>>> 0xc0000000 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>>> >>>>> >>>>> cpuid.0ac2b19743 >>>>> >>>>> CPU 0: >>>>> 0x00000000 0x00: eax=0x00000016 ebx=0x756e6547 ecx=0x6c65746e edx=0x49656e69 >>>>> 0x00000001 0x00: eax=0x000806ea ebx=0x00000800 ecx=0xfffab223 edx=0x0f8bfbff >>>>> 0x00000002 0x00: eax=0x00000001 ebx=0x00000000 ecx=0x0000004d edx=0x002c307d >>>>> 0x00000003 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>>> 0x00000004 0x00: eax=0x00000121 ebx=0x01c0003f ecx=0x0000003f edx=0x00000001 >>>>> 0x00000004 0x01: eax=0x00000122 ebx=0x01c0003f ecx=0x0000003f edx=0x00000001 >>>>> 0x00000004 0x02: eax=0x00000143 ebx=0x03c0003f ecx=0x00000fff edx=0x00000001 >>>>> 0x00000004 0x03: eax=0x00000163 ebx=0x03c0003f ecx=0x00003fff edx=0x00000006 >>>>> 0x00000005 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000003 edx=0x00000000 >>>>> 0x00000006 0x00: eax=0x00000004 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>>> 0x00000007 0x00: eax=0x00000000 ebx=0x009c4fbb ecx=0x00000004 edx=0xac000400 >>>>> 0x00000008 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>>> 0x00000009 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>>> 0x0000000a 0x00: eax=0x07300402 ebx=0x00000000 ecx=0x00000000 edx=0x00008603 >>>>> 0x0000000b 0x00: eax=0x00000000 ebx=0x00000001 ecx=0x00000100 edx=0x00000000 >>>>> 0x0000000b 0x01: eax=0x00000000 ebx=0x00000001 ecx=0x00000201 edx=0x00000000 >>>>> 0x0000000c 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>>> 0x0000000d 0x00: eax=0x0000001f ebx=0x00000440 ecx=0x00000440 edx=0x00000000 >>>>> 0x0000000d 0x01: eax=0x0000000f ebx=0x000003c0 ecx=0x00000000 edx=0x00000000 >>>>> 0x0000000d 0x02: eax=0x00000100 ebx=0x00000240 ecx=0x00000000 edx=0x00000000 >>>>> 0x0000000d 0x03: eax=0x00000040 ebx=0x000003c0 ecx=0x00000000 edx=0x00000000 >>>>> 0x0000000d 0x04: eax=0x00000040 ebx=0x00000400 ecx=0x00000000 edx=0x00000000 >>>>> 0x0000000e 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>>> 0x0000000f 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>>> 0x00000010 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>>> 0x00000011 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>>> 0x00000012 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>>> 0x00000013 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>>> 0x00000014 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>>> 0x00000015 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>>> 0x00000016 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>>> 0x40000000 0x00: eax=0x40000001 ebx=0x4b4d564b ecx=0x564b4d56 edx=0x0000004d >>>>> 0x40000001 0x00: eax=0x01007afb ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>>> 0x80000000 0x00: eax=0x80000008 ebx=0x756e6547 ecx=0x6c65746e edx=0x49656e69 >>>>> 0x80000001 0x00: eax=0x000806ea ebx=0x00000000 ecx=0x00000121 edx=0x2c100800 >>>>> 0x80000002 0x00: eax=0x65746e49 ebx=0x2952286c ecx=0x726f4320 edx=0x4d542865 >>>>> 0x80000003 0x00: eax=0x37692029 ebx=0x3536382d ecx=0x43205530 edx=0x40205550 >>>>> 0x80000004 0x00: eax=0x392e3120 ebx=0x7a484730 ecx=0x00000000 edx=0x00000000 >>>>> 0x80000005 0x00: eax=0x01ff01ff ebx=0x01ff01ff ecx=0x40020140 edx=0x40020140 >>>>> 0x80000006 0x00: eax=0x00000000 ebx=0x42004200 ecx=0x02008140 edx=0x00808140 >>>>> 0x80000007 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>>> 0x80000008 0x00: eax=0x00003027 ebx=0x0100d000 ecx=0x00000000 edx=0x00000000 >>>>> 0x80860000 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>>> 0xc0000000 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 >>>>> >>>> >>>> I started looking at it. >>>> >>>> Claudio >>>> >>> >>> I wonder how I missed this, the initialization functions for max_x86_cpu_initfn and kvm_cpu_max_instance_init end up being called in the wrong order. >>> >> >> >> Just to check whether this is actually the issue we are talking about, Sid et al, could you try this? >> >> >> diff --git a/target/i386/cpu.c b/target/i386/cpu.c >> index c496bfa1c2..810c46281b 100644 >> --- a/target/i386/cpu.c >> +++ b/target/i386/cpu.c >> @@ -4252,6 +4252,7 @@ static void max_x86_cpu_initfn(Object *obj) >> object_property_set_str(OBJECT(cpu), "model-id", >> "QEMU TCG CPU version " QEMU_HW_VERSION, >> &error_abort); >> + accel_cpu_instance_init(CPU(cpu)); >> } >> >> static const TypeInfo max_x86_cpu_type_info = { >> ------------------------------------------------------------------------------------------ >> >> Does this band-aid happen to cover-up the issue? > > I think it mostly does - thanks; however the address widths are still > wrong: > > address sizes : 40 bits physical, 48 bits virtual > > where as my little laptop can only think in 39bits physical; so I think > that's still coming through from the TCG def. > > Dave Oh my, Another problem in that commit. Here I am attempting a fix, but for the proper reordering I'd need a good re-review of this. I am currently toying with these two changes, feedback and opinions welcome. The first uses instance_post_init to call accel_cpu_instance_init, in order to attempt to fix the max/host call order problem. The second moves the call to cpu_exec_realizefn() in a better place, in particular after the expansion of features. commit 5080a46d8833aad18ecb89e3270b726231a21f09 (HEAD -> master) Author: Claudio Fontana <cfontana@suse.de> Date: Thu May 27 20:01:22 2021 +0200 i386: run accel_cpu_instance_init as instance_post_init This partially fixes host and max cpu initialization, by running the accel cpu initialization only after all instance init functions are called for all X86 cpu subclasses. Partial Fix. Fixes: 48afe6e4eabf ("i386: split cpu accelerators from cpu.c, using AccelCPUClass") Signed-off-by: Claudio Fontana <cfontana@suse.de> diff --git a/target/i386/cpu.c b/target/i386/cpu.c index 6bcb7dbc2c..ae148fbd2f 100644 --- a/target/i386/cpu.c +++ b/target/i386/cpu.c @@ -6422,6 +6422,11 @@ static void x86_cpu_register_feature_bit_props(X86CPUClass *xcc, x86_cpu_register_bit_prop(xcc, name, w, bitnr); } +static void x86_cpu_post_initfn(Object *obj) +{ + accel_cpu_instance_init(CPU(obj)); +} + static void x86_cpu_initfn(Object *obj) { X86CPU *cpu = X86_CPU(obj); @@ -6473,9 +6478,6 @@ static void x86_cpu_initfn(Object *obj) if (xcc->model) { x86_cpu_load_model(cpu, xcc->model); } - - /* if required, do accelerator-specific cpu initializations */ - accel_cpu_instance_init(CPU(obj)); } static int64_t x86_cpu_get_arch_id(CPUState *cs) @@ -6810,6 +6812,8 @@ static const TypeInfo x86_cpu_type_info = { .parent = TYPE_CPU, .instance_size = sizeof(X86CPU), .instance_init = x86_cpu_initfn, + .instance_post_init = x86_cpu_post_initfn, + .abstract = true, .class_size = sizeof(X86CPUClass), .class_init = x86_cpu_common_class_init, commit 50191ee2792326b68d9203bb0a4867d4243ab250 Author: Claudio Fontana <cfontana@suse.de> Date: Thu May 27 19:55:39 2021 +0200 i386: reorder call to cpu_exec_realizefn in x86_cpu_realizefn we need to expand features first, before we attempt to check them in the accel realizefn code called by cpu_exec_realizefn(). At the same time we need checks for code_urev and host_cpuid_required, and modifications to cpu->mwait to happen after the initial setting of them inside the accel realizefn code. Partial Fix. Fixes: 48afe6e4eabf ("i386: split cpu accelerators from cpu.c, using AccelCPUClass") Signed-off-by: Claudio Fontana <cfontana@suse.de> diff --git a/target/i386/cpu.c b/target/i386/cpu.c index 9e211ac2ce..6bcb7dbc2c 100644 --- a/target/i386/cpu.c +++ b/target/i386/cpu.c @@ -6133,34 +6133,6 @@ static void x86_cpu_realizefn(DeviceState *dev, Error **errp) Error *local_err = NULL; static bool ht_warned; - /* Process Hyper-V enlightenments */ - x86_cpu_hyperv_realize(cpu); - - cpu_exec_realizefn(cs, &local_err); - if (local_err != NULL) { - error_propagate(errp, local_err); - return; - } - - if (xcc->host_cpuid_required && !accel_uses_host_cpuid()) { - g_autofree char *name = x86_cpu_class_get_model_name(xcc); - error_setg(&local_err, "CPU model '%s' requires KVM or HVF", name); - goto out; - } - - if (cpu->ucode_rev == 0) { - /* The default is the same as KVM's. */ - if (IS_AMD_CPU(env)) { - cpu->ucode_rev = 0x01000065; - } else { - cpu->ucode_rev = 0x100000000ULL; - } - } - - /* mwait extended info: needed for Core compatibility */ - /* We always wake on interrupt even if host does not have the capability */ - cpu->mwait.ecx |= CPUID_MWAIT_EMX | CPUID_MWAIT_IBE; - if (cpu->apic_id == UNASSIGNED_APIC_ID) { error_setg(errp, "apic-id property was not initialized properly"); return; @@ -6190,6 +6162,34 @@ static void x86_cpu_realizefn(DeviceState *dev, Error **errp) & CPUID_EXT2_AMD_ALIASES); } + /* Process Hyper-V enlightenments */ + x86_cpu_hyperv_realize(cpu); + + cpu_exec_realizefn(cs, &local_err); + if (local_err != NULL) { + error_propagate(errp, local_err); + return; + } + + if (xcc->host_cpuid_required && !accel_uses_host_cpuid()) { + g_autofree char *name = x86_cpu_class_get_model_name(xcc); + error_setg(&local_err, "CPU model '%s' requires KVM or HVF", name); + goto out; + } + + if (cpu->ucode_rev == 0) { + /* The default is the same as KVM's. */ + if (IS_AMD_CPU(env)) { + cpu->ucode_rev = 0x01000065; + } else { + cpu->ucode_rev = 0x100000000ULL; + } + } + + /* mwait extended info: needed for Core compatibility */ + /* We always wake on interrupt even if host does not have the capability */ + cpu->mwait.ecx |= CPUID_MWAIT_EMX | CPUID_MWAIT_IBE; + /* For 64bit systems think about the number of physical bits to present. * ideally this should be the same as the host; anything other than matching * the host can cause incorrect guest behaviour. ----------------------------------------------------------------------------------------- > >> >> I need to think about the proper fix though, any suggestions Paolo, Eduardo? >> >> The pickle here is that we'd need to call the accelerator specific initialization of the x86 accel-cpu only after the x86 cpu subclass initfn, >> otherwise the accel-specific cpu initialization code has no chance to see the subclass (max) trying to set ->max_features. >> >> C. >> ^ permalink raw reply related [flat|nested] 14+ messages in thread
end of thread, other threads:[~2021-05-27 18:43 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-05-21 9:17 Windows fails to boot after rebase to QEMU master Siddharth Chandrasekaran 2021-05-24 10:13 ` Michael S. Tsirkin 2021-05-26 19:30 ` Dr. David Alan Gilbert 2021-05-27 7:57 ` Claudio Fontana 2021-05-27 8:31 ` Dr. David Alan Gilbert 2021-05-27 9:01 ` Philippe Mathieu-Daudé 2021-05-27 9:15 ` Dr. David Alan Gilbert 2021-05-27 9:48 ` Claudio Fontana 2021-05-27 10:53 ` Claudio Fontana 2021-05-27 11:36 ` Claudio Fontana 2021-05-27 11:51 ` Siddharth Chandrasekaran 2021-05-27 13:21 ` Claudio Fontana 2021-05-27 13:24 ` Dr. David Alan Gilbert 2021-05-27 18:43 ` Claudio Fontana
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).