Bug 986252

This use case corresponds to booting a windows OS on a physical machine, and keeping hitting the physical power button during boot. Windows has a very sensitive ACPI subsystem and considers the System Control Interrupt (raised by the power button) an unexpected event / a hardware error during boot. Could be caused by a "halfway configured" interrupt handler routine.

Please try to reproduce on a physical machine with the same windows OS, using the above power button method.

It's a guest problem in any case.

The RHEL guest doesn't care because when the SCI is injected / raised, you either have the full handler chain in place, or you don't, and in the latter case the event is simply lost. The handler chain consists of:
- kernel (exporting /proc/acpi/event),
- on RHEL-6: acpid and /etc/acpi/actions/power.sh,
- on RHEL-7: systemd and the /etc/systemd/logind.conf file
  (HandlePowerKey entry), plus whatever obscure handling gnome-session
  puts in place (see bug 980692).
- some utility that brings down the system ultimately (shutdown, systemd etc.)

(In theory there might be a narrow window in the Linux guest as well when the SCI leads to something unexpected.)

This is a windows bug, or a destructive sysadmin, dependent on whom you ask. I'm proposing NOTABUG, but I'll wait for the result of the physical test. Thanks.

Could you pleas upload the relevant crash dump file?
Thanks,
Vadim.

(In reply to Vadim Rozenfeld from comment #4)
> Could you pleas upload the relevant crash dump file?
> Thanks,
> Vadim.

Hi Vadim

    No crash dump file create,only see guest BSOD.


thanks

(In reply to langfang from comment #5)
> (In reply to Vadim Rozenfeld from comment #4)
> > Could you pleas upload the relevant crash dump file?
> > Thanks,
> > Vadim.
> 
> Hi Vadim
> 
>     No crash dump file create,only see guest BSOD.
> 
> 
> thanks

No problem.
Will try to catch it with WinDbg.
Best regards,
Vadim.

  Test this bug on physical machine, and keeping hitting the physical power button during boot. Not hit BSOD.


thanks

Test on latest version,hit the same problem.
Host:
# uname -r
3.10.0-111.el7.x86_64
# rpm -q qemu-kvm-rhev
qemu-kvm-rhev-1.5.3-53.el7.x86_64

Guest:win2008r2-64


How reproducible:
1/5

Host:
...
processor	: 1
vendor_id	: AuthenticAMD
cpu family	: 15
model		: 107
model name	: AMD Athlon(tm) Dual Core Processor 4450B
stepping	: 2
cpu MHz		: 2300.000
cache size	: 512 KB
physical id	: 0
siblings	: 2
core id		: 1
cpu cores	: 2
apicid		: 1
initial apicid	: 1
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
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 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good nopl extd_apicid pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch lbrv
bogomips	: 4609.69
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc 100mhzsteps


Steps:
1.Boot guest
 /usr/libexec/qemu-kvm -M rhel6.5.0 -cpu Opteron_G2 -m 1G -smp 2,sockets=2,cores=1,threads=1 -enable-kvm -usb -name win2008r2-64 -uuid 1bb0ef81-1021-4d3f-a424-49a48fedafa2 -rtc base=localtime,clock=host,driftfix=slew -boot menu=on -drive file=/home/win2008r2-64.qcow2,if=none,id=drive-ide0-1-0,format=qcow2 -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=1 -vnc :11 -vga std -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -serial unix:/tmp/ttyS0,server,nowait -qmp tcp:0:4445,server,nowait -monitor unix:/tmp/monitor-unix,nowait,server -monitor stdio

2.Repeadly "system_powerdown" while booting guest 
(qemu)system_powerdown
(qemu)system_powerdown
(qemu)system_powerdown
....


Results:BSOD ,see attachment

Created attachment 875871 [details]
BSOD-->first time

Created attachment 875873 [details]
BSOD-second time

Not urgent, deferring to 7.2

Reproduce this bug on latest version 
host
    qemu-kvm-1.5.3-140.el7.x86_64
    kernel-3.10.0-679.el7.x86_64
    seabios-bin-1.10.2-3.el7.noarch
guest:win2008r2-64

test steps:
1.boot a guest
/usr/libexec/qemu-kvm \
-M pc \
-cpu Opteron_G1,enforce \
-m 4G \
-smp 2,sockets=2,cores=1,threads=1 \
-enable-kvm \
-usbdevice tablet \
-name win2008r2-64 \
-uuid ac17ac05-cf4b-4247-8b9c-5cbd22d72679   \
-rtc base=localtime,clock=host,driftfix=slew  \
-boot menu=on \
-drive file=/root/bz986252/win2008-r2-64-virtio.qcow2,format=qcow2,if=none,id=drive-virtio-disk0,cache=none,werror=stop,rerror=stop \
-device virtio-blk-pci,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1  \
-netdev tap,id=hostnet0  \
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:a6:88:00  \
-vnc :11 \
-global PIIX4_PM.disable_s3=0 \
-global PIIX4_PM.disable_s4=0 \
-serial unix:/tmp/ttyS0,server,nowait \
-qmp tcp:0:4445,server,nowait \
-monitor unix:/tmp/monitor-unix,nowait,server \
-monitor stdio \
2.Repeadly "system_powerdown" while booting guest
(qemu) system_powerdown 
(qemu) system_powerdown

test results:BSOD

Host info:
#cat /proc/cpuinfo 
...
processor	: 3
vendor_id	: AuthenticAMD
cpu family	: 21
model		: 16
model name	: AMD A10-5800K APU with Radeon(tm) HD Graphics
stepping	: 1
microcode	: 0x6001119
cpu MHz		: 3800.000
cache size	: 2048 KB
physical id	: 0
siblings	: 4
core id		: 3
cpu cores	: 2
apicid		: 19
initial apicid	: 3
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 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc art rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb cpb hw_pstate bmi1 arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold
bogomips	: 7586.11
TLB size	: 1536 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro

Created attachment 1285958 [details]
BSOD

Still no crash-dump file was created, right?

Thanks,
Vadim.

(In reply to Vadim Rozenfeld from comment #20)
> Still no crash-dump file was created, right?

yes,hit BSOD but no crash-dump file in win2008r2-64 guest.

QEMU has been recently split into sub-components and as a one-time operation to avoid breakage of tools, we are setting the QEMU sub-component of this BZ to "General". Please review and change the sub-component if necessary the next time you review this BZ. Thanks

Hi,

Can be reproduce this bug with latest qemu build.

Host version:
kernel-4.18.0-240.5.1.el8_3.x86_64
qemu-kvm-5.1.0-14.module+el8.3.0+8790+80f9c6d8.1.x86_64
seabios-1.14.0-1.module+el8.3.0+7638+07cf13d2.x86_64
guest:win2008r2

test results:
BSOD, but no crash-dump file is generated in guest.


1)boot a guest with cmd
/usr/libexec/qemu-kvm \
    -name 'avocado-vt-vm1'  \
    -machine pc  \
    -nodefaults \
    -device VGA,bus=pci.0,addr=0x2 \
    -m 10240  \
    -smp 24,maxcpus=24,cores=12,threads=1,dies=1,sockets=2  \
    -cpu 'EPYC',-xsave,hv_stimer,hv_synic,hv_vpindex,hv_relaxed,hv_spinlocks=0xfff,hv_vapic,hv_time,hv_frequencies,hv_runtime,hv_tlbflush,hv_reenlightenment,hv_stimer_direct,hv_ipi,+kvm_pv_unhalt \
    -device qemu-xhci,id=usb1,bus=pci.0,addr=0x3 \
    -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 \
    -blockdev node-name=file_image1,driver=file,auto-read-only=on,discard=unmap,aio=threads,filename=/home/win2008-r2-64-virtio.qcow2,cache.direct=on,cache.no-flush=off \
    -blockdev node-name=drive_image1,driver=qcow2,read-only=off,cache.direct=on,cache.no-flush=off,file=file_image1 \
    -device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,write-cache=on,bus=pci.0,addr=0x4 \
    -device virtio-net-pci,mac=9a:31:71:23:4f:9d,id=idgwpiMr,netdev=idEEJIdf,bus=pci.0,addr=0x5  \
    -netdev tap,id=idEEJIdf,vhost=on \
    -vnc :0  \
    -monitor stdio \

2)host information
[root@dell-per6415-01 ~]# lscpu
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              48
On-line CPU(s) list: 0-47
Thread(s) per core:  2
Core(s) per socket:  24
Socket(s):           1
NUMA node(s):        4
Vendor ID:           AuthenticAMD
CPU family:          23
Model:               1
Model name:          AMD EPYC 7401P 24-Core Processor
Stepping:            2
CPU MHz:             2802.348
BogoMIPS:            3992.46
Virtualization:      AMD-V
L1d cache:           32K
L1i cache:           64K
L2 cache:            512K
L3 cache:            8192K
NUMA node0 CPU(s):   0,4,8,12,16,20,24,28,32,36,40,44
NUMA node1 CPU(s):   1,5,9,13,17,21,25,29,33,37,41,45
NUMA node2 CPU(s):   2,6,10,14,18,22,26,30,34,38,42,46
NUMA node3 CPU(s):   3,7,11,15,19,23,27,31,35,39,43,47
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid amd_dcm aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb hw_pstate sme ssbd sev ibpb vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf xsaveerptr arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov succor smca

Thanks for the update.
Is it reproducible on win10 guest?

Best,
Vadim.

(In reply to Vadim Rozenfeld from comment #35)
> Thanks for the update.
> Is it reproducible on win10 guest?
Hi,Vadim

I didn't reproduce this bug with win10_64bit guest.

Host version:
kernel-4.18.0-240.5.1.el8_3.x86_64
qemu-kvm-5.1.0-14.module+el8.3.0+8790+80f9c6d8.1.x86_64
seabios-1.14.0-1.module+el8.3.0+7638+07cf13d2.x86_64
guest:win10-64-virtio.qcow2

thanks,
yiqian

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.