qemu-devel
[Top][All Lists]
Advanced

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

Re: Windows fails to boot after rebase to QEMU master


From: Philippe Mathieu-Daudé
Subject: Re: Windows fails to boot after rebase to QEMU master
Date: Thu, 27 May 2021 11:01:37 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1

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




reply via email to

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