QEMU

windows2008r2 boot failed with uefi

Bug #1593605 reported by Richard Zhang on 2016-06-17

This bug affects 3 people

Affects		Status	Importance	Assigned to	Milestone
	QEMU	Invalid	Undecided	Unassigned

Bug Description

I want to run my win2008r2 with uefi. Hypervisor is ubuntu16.04 and my qemu command line show below:

qemu-system-x86_64 -enable-kvm -name win2008r2 -S -machine pc-i440fx-2.5,accel=kvm,usb=off -cpu host,hv_time,hv_relaxed,hv_spinlocks=0x2000 -drive file=/usr/share/qemu/OVMF.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=/var/lib/libvirt/qemu/nvram/win2008r2_VARS.fd,if=pflash,format=raw,unit=1 -m size=8388608k,slots=10,maxmem=1073741824k -realtime mlock=off -smp 8,maxcpus=96,sockets=24,cores=4,threads=1 -numa node,nodeid=0,cpus=0-7,mem=8192 -uuid 030638c5-c6aa-4f06-82f8-dd2d04fd5705 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-win2008r2/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,clock=vm,driftfix=slew -no-hpet -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device usb-ehci,id=usb1,bus=pci.0,addr=0x4 -device nec-usb-xhci,id=usb2,bus=pci.0,addr=0x5 -device lsi,id=scsi0,bus=pci.0,addr=0x6 -device virtio-scsi-pci,id=scsi1,bus=pci.0,addr=0x7 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x8 -drive file=/vms/images/win2008r2,format=qcow2,if=none,id=drive-ide0-0-0,cache=directsync -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive file=/vms/isos/cn_windows_server_2008_r2_standard_enterprise_datacenter_and_web_with_sp1_x64_dvd_617598.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on -device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/win2008r2.agent,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0 -vnc 0.0.0.0:0 -device VGA,id=video0,vgamem_mb=16,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0xa -msg timestamp=on

OVMF.fd is download from http://sourceforge.net/projects/edk2/files/OVMF/ OVMF-X64-r15214.zip.

When I boot my domain with windows2008 iso, the kvm was caught in endless interrupt. I enable trace on my host and I got this.

1. echo 1 > /sys/kernel/debug/tracing/events/kvm/enable
2. cat /sys/kernel/debug/tracing/trace_pipe
qemu-system-x86-1969 [006] .... 2093.019588: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000fd
qemu-system-x86-1969 [006] d... 2093.019590: kvm_entry: vcpu 0
qemu-system-x86-1966 [017] .... 2093.021424: kvm_set_irq: gsi 8 level 1 source 0
qemu-system-x86-1966 [017] .... 2093.021429: kvm_pic_set_irq: chip 1 pin 0 (edge|masked)
qemu-system-x86-1966 [017] .... 2093.021430: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced)
qemu-system-x86-1969 [006] .... 2093.021683: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000fd
qemu-system-x86-1969 [006] d... 2093.021686: kvm_entry: vcpu 0
qemu-system-x86-1969 [006] .... 2093.022592: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000ef
qemu-system-x86-1969 [006] d... 2093.022595: kvm_entry: vcpu 0
qemu-system-x86-1969 [006] .... 2093.022746: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000fd
qemu-system-x86-1969 [006] d... 2093.022749: kvm_entry: vcpu 0
qemu-system-x86-1966 [017] .... 2093.023434: kvm_set_irq: gsi 8 level 1 source 0
qemu-system-x86-1966 [017] .... 2093.023444: kvm_pic_set_irq: chip 1 pin 0 (edge|masked)
qemu-system-x86-1966 [017] .... 2093.023446: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced)
qemu-system-x86-1969 [006] .... 2093.023610: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000fd
qemu-system-x86-1969 [006] d... 2093.023612: kvm_entry: vcpu 0
qemu-system-x86-1966 [017] .... 2093.025430: kvm_set_irq: gsi 8 level 1 source 0
qemu-system-x86-1966 [017] .... 2093.025435: kvm_pic_set_irq: chip 1 pin 0 (edge|masked)
qemu-system-x86-1966 [017] .... 2093.025436: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced)
qemu-system-x86-1969 [006] .... 2093.025599: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000fd
qemu-system-x86-1969 [006] d... 2093.025601: kvm_entry: vcpu 0
qemu-system-x86-1969 [006] .N.. 2093.026593: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000ef
qemu-system-x86-1969 [006] d... 2093.026596: kvm_fpu: unload
qemu-system-x86-1969 [006] .... 2093.026598: kvm_ple_window: vcpu 0: ple_window 4096 (shrink 4096)
qemu-system-x86-1969 [006] .... 2093.026599: kvm_fpu: load
qemu-system-x86-1969 [006] d... 2093.026599: kvm_entry: vcpu 0
qemu-system-x86-1969 [006] .... 2093.026741: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000fd
qemu-system-x86-1969 [006] d... 2093.026744: kvm_entry: vcpu 0
qemu-system-x86-1969 [006] .... 2093.026841: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000fd
qemu-system-x86-1969 [006] d... 2093.026844: kvm_entry: vcpu 0
qemu-system-x86-1966 [017] .... 2093.027448: kvm_set_irq: gsi 8 level 1 source 0
qemu-system-x86-1966 [017] .... 2093.027454: kvm_pic_set_irq: chip 1 pin 0 (edge|masked)
qemu-system-x86-1966 [017] .... 2093.027455: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced)
qemu-system-x86-1966 [017] .... 2093.029444: kvm_set_irq: gsi 8 level 1 source 0
qemu-system-x86-1966 [017] .... 2093.029449: kvm_pic_set_irq: chip 1 pin 0 (edge|masked)
qemu-system-x86-1966 [017] .... 2093.029450: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced)
qemu-system-x86-1969 [006] .... 2093.029452: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000ef
qemu-system-x86-1969 [006] d... 2093.029454: kvm_entry: vcpu 0
qemu-system-x86-1969 [006] .... 2093.029633: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000fd
qemu-system-x86-1969 [006] d... 2093.029636: kvm_entry: vcpu 0
qemu-system-x86-1969 [006] .... 2093.030592: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000ef
qemu-system-x86-1969 [006] d... 2093.030595: kvm_entry: vcpu 0
qemu-system-x86-1969 [006] .... 2093.030745: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000fd
qemu-system-x86-1969 [006] d... 2093.030748: kvm_entry: vcpu 0
qemu-system-x86-1969 [006] .... 2093.030840: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000fd
qemu-system-x86-1969 [006] d... 2093.030843: kvm_entry: vcpu 0
qemu-system-x86-1966 [017] .... 2093.031454: kvm_set_irq: gsi 8 level 1 source 0
qemu-system-x86-1966 [017] .... 2093.031459: kvm_pic_set_irq: chip 1 pin 0 (edge|masked)
qemu-system-x86-1966 [017] .... 2093.031460: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced)
qemu-system-x86-1966 [017] .... 2093.032968: kvm_set_irq: gsi 8 level 1 source 0
qemu-system-x86-1966 [017] .... 2093.032974: kvm_pic_set_irq: chip 1 pin 0 (edge|masked)
qemu-system-x86-1966 [017] .... 2093.032975: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced)
qemu-system-x86-1969 [006] .... 2093.033229: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000fd
qemu-system-x86-1969 [006] d... 2093.033231: kvm_entry: vcpu 0
qemu-system-x86-1969 [006] .... 2093.034592: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000ef
qemu-system-x86-1969 [006] d... 2093.034595: kvm_entry: vcpu 0
qemu-system-x86-1969 [006] .... 2093.034781: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000fd
qemu-system-x86-1969 [006] d... 2093.034783: kvm_entry: vcpu 0
qemu-system-x86-1966 [017] .... 2093.034975: kvm_set_irq: gsi 8 level 1 source 0
qemu-system-x86-1966 [017] .... 2093.034980: kvm_pic_set_irq: chip 1 pin 0 (edge|masked)
qemu-system-x86-1966 [017] .... 2093.034981: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced)
qemu-system-x86-1969 [006] .... 2093.035113: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000fd
qemu-system-x86-1969 [006] d... 2093.035116: kvm_entry: vcpu 0
qemu-system-x86-1966 [017] .... 2093.036983: kvm_set_irq: gsi 8 level 1 source 0
qemu-system-x86-1966 [017] .... 2093.036989: kvm_pic_set_irq: chip 1 pin 0 (edge|masked)
qemu-system-x86-1966 [017] .... 2093.036990: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced)
qemu-system-x86-1969 [006] .... 2093.037154: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000fd
qemu-system-x86-1969 [006] d... 2093.037157: kvm_entry: vcpu 0

Tags:

Revision history for this message

Richard Zhang (richardzzj) wrote on 2016-06-17:

Download from http://sourceforge.net/projects/edk2/files/OVMF/, OVMF-X64-r15214.zip Edit (1.0 MiB, application/octet-stream)

Revision history for this message

Laszlo Ersek (Red Hat) (lersek) wrote on 2016-06-18:

The OVMF build you use (SVN r15214) is from Feb 2014 -- it is completely obsolete. I suggest you use the packages from https://www.kraxel.org/repos/ .

I'm marking this as "invalid" because supporting 2+ year old OVMF builds is unthinkable.

Changed in qemu:
status:	New → Invalid

Revision history for this message

Richard Zhang (richardzzj) wrote on 2016-06-18:

Download full text (3.6 KiB)

Thanks for your advice. I got newer version of OVMF from https://www.kraxel.org/repos/. And compile from source code(git://github.com/tianocore/edk2.git).
With these OVMF, it really works well on only 1 vcpu domain. But still failed with multi-vcpus.
The vcpu0 runnig in an endless loop, and other vcpus is halted. The stack of vcpu0 show below:
#0 0x00005571f4b10959 in address_space_update_topology_pass (as=0x5571f6b76de8, old_view=0x7f6884020690, new_view=0x7f6884022ab0, adding=true)
    at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:753
#1 0x00005571f4b10a18 in address_space_update_topology (as=0x5571f6b76de8) at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:768
#2 0x00005571f4b10bba in memory_region_transaction_commit () at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:809
#3 0x00005571f4b13d8b in memory_region_update_container_subregions (subregion=0x5571f6cc5140)
    at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:1658
#4 0x00005571f4b13e14 in memory_region_add_subregion_common (mr=0x5571f6a22530, offset=655360, subregion=0x5571f6cc5140)
    at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:1668
#5 0x00005571f4b13ee8 in memory_region_add_subregion_overlap (mr=0x5571f6a22530, offset=655360, subregion=0x5571f6cc5140, priority=2)
    at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:1687
#6 0x00005571f4b2c27a in vga_update_memory_access (s=0x5571f6cc4f38) at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/hw/display/vga.c:210
#7 0x00005571f4b2cddb in vga_ioport_write (opaque=0x5571f6cc4f38, addr=975, val=8)
    at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/hw/display/vga.c:538
#8 0x00005571f4cf7072 in qxl_vga_ioport_write (opaque=0x5571f6cc4f38, addr=975, val=8) at hw/display/qxl.c:1197
#9 0x00005571f4b03316 in portio_write (opaque=0x5571f6c72890, addr=14, data=2056, size=2)
    at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/ioport.c:201
#10 0x00005571f4b0ea9c in memory_region_write_accessor (mr=0x5571f6c72890, addr=14, value=0x7f688b73ab28, size=2, shift=0, mask=65535)
    at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:444
#11 0x00005571f4b0ebe4 in access_with_adjusted_size (addr=14, value=0x7f688b73ab28, size=2, access_size_min=1, access_size_max=4,
    access=0x5571f4b0ea00 <memory_region_write_accessor>, mr=0x5571f6c72890) at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:481
#12 0x00005571f4b11b28 in memory_region_dispatch_write (mr=0x5571f6c72890, addr=14, data=2056, size=2)
    at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:1138
#13 0x00005571f4b152ce in io_mem_write (mr=0x5571f6c72890, addr=14, val=2056, size=2) at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:1971
#14 0x00005571f4abd56b in address_space_rw (as=0x5571f5333b80, addr=974, buf=0x7f689a390000 "\b", <incomplete sequence \307>, len=2, is_write=true)
    at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/exec.c:2123
#15 0x00005571f4b0b028 in kvm_handle_io (port=974, data=0x7f689a390000, direction=1, size=2, count=1)
    at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/kvm-all.c:1616
#16 0x00005...

Thanks for your advice. I got newer version of OVMF from https://www.kraxel.org/repos/. And compile from source code(git://github.com/tianocore/edk2.git). 
With these OVMF, it really works well on only 1 vcpu domain. But still failed with multi-vcpus. 
The vcpu0 runnig in an endless loop, and other vcpus is halted. The stack of vcpu0 show below:
#0  0x00005571f4b10959 in address_space_update_topology_pass (as=0x5571f6b76de8, old_view=0x7f6884020690, new_view=0x7f6884022ab0, adding=true)
    at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:753
#1  0x00005571f4b10a18 in address_space_update_topology (as=0x5571f6b76de8) at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:768
#2  0x00005571f4b10bba in memory_region_transaction_commit () at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:809
#3  0x00005571f4b13d8b in memory_region_update_container_subregions (subregion=0x5571f6cc5140)
    at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:1658
#4  0x00005571f4b13e14 in memory_region_add_subregion_common (mr=0x5571f6a22530, offset=655360, subregion=0x5571f6cc5140)
    at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:1668
#5  0x00005571f4b13ee8 in memory_region_add_subregion_overlap (mr=0x5571f6a22530, offset=655360, subregion=0x5571f6cc5140, priority=2)
    at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:1687
#6  0x00005571f4b2c27a in vga_update_memory_access (s=0x5571f6cc4f38) at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/hw/display/vga.c:210
#7  0x00005571f4b2cddb in vga_ioport_write (opaque=0x5571f6cc4f38, addr=975, val=8)
    at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/hw/display/vga.c:538
#8  0x00005571f4cf7072 in qxl_vga_ioport_write (opaque=0x5571f6cc4f38, addr=975, val=8) at hw/display/qxl.c:1197
#9  0x00005571f4b03316 in portio_write (opaque=0x5571f6c72890, addr=14, data=2056, size=2)
    at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/ioport.c:201
#10 0x00005571f4b0ea9c in memory_region_write_accessor (mr=0x5571f6c72890, addr=14, value=0x7f688b73ab28, size=2, shift=0, mask=65535)
    at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:444
#11 0x00005571f4b0ebe4 in access_with_adjusted_size (addr=14, value=0x7f688b73ab28, size=2, access_size_min=1, access_size_max=4, 
    access=0x5571f4b0ea00 <memory_region_write_accessor>, mr=0x5571f6c72890) at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:481
#12 0x00005571f4b11b28 in memory_region_dispatch_write (mr=0x5571f6c72890, addr=14, data=2056, size=2)
    at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:1138
#13 0x00005571f4b152ce in io_mem_write (mr=0x5571f6c72890, addr=14, val=2056, size=2) at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:1971
#14 0x00005571f4abd56b in address_space_rw (as=0x5571f5333b80, addr=974, buf=0x7f689a390000 "\b", <incomplete sequence \307>, len=2, is_write=true)
    at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/exec.c:2123
#15 0x00005571f4b0b028 in kvm_handle_io (port=974, data=0x7f689a390000, direction=1, size=2, count=1)
    at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/kvm-all.c:1616
#16 0x00005571f4b0b5d1 in kvm_cpu_exec (cpu=0x5571f6a5d5e0) at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/kvm-all.c:1758
#17 0x00005571f4af0bf0 in qemu_kvm_cpu_thread_fn (arg=0x5571f6a5d5e0) at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/cpus.c:898
#18 0x00007f6899c18e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#19 0x00007f68963f938d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#20 0x0000000000000000 in ?? ()

Changed in qemu:
status:	Invalid → Incomplete

Revision history for this message

Richard Zhang (richardzzj) wrote on 2016-06-18:

When I change qemu version from 2.1.2 to 2.6.0. The vcpu0 will return 0 qemu.
I got strace like this:
strace -p 1180
Process 1180 attached - interrupt to quit
rt_sigtimedwait([BUS USR1], 0x7f719b5fa960, {0, 0}, 8) = -1 EAGAIN (Resource temporarily unavailable)
rt_sigpending([]) = 0
futex(0x55669f356d60, FUTEX_WAKE_PRIVATE, 1) = 1
ioctl(26, KVM_RUN

The kvm tracing like this:
             kvm-1180 [018] d... 63148.545821: kvm_entry: vcpu 0
             kvm-1180 [018] d... 63148.545944: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
             kvm-1180 [018] d... 63148.545948: kvm_entry: vcpu 0
             kvm-1180 [018] d... 63148.546083: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
             kvm-1180 [018] d... 63148.546085: kvm_entry: vcpu 0
             kvm-1180 [018] d... 63148.546200: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
             kvm-1180 [018] d... 63148.546202: kvm_entry: vcpu 0
             kvm-1180 [018] d... 63148.546317: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
             kvm-1180 [018] d... 63148.546320: kvm_entry: vcpu 0
             kvm-1180 [018] d... 63148.546436: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
             kvm-1180 [018] d... 63148.546439: kvm_entry: vcpu 0
             kvm-1180 [018] d... 63148.546553: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
             kvm-1180 [018] d... 63148.546556: kvm_entry: vcpu 0
             kvm-1180 [018] d... 63148.546689: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
             kvm-1180 [018] d... 63148.546691: kvm_entry: vcpu 0
             kvm-1180 [018] d... 63148.546807: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
             kvm-1180 [018] d... 63148.546810: kvm_entry: vcpu 0
             kvm-1180 [018] d... 63148.546927: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
             kvm-1180 [018] d... 63148.546930: kvm_entry: vcpu 0
             kvm-1180 [018] d... 63148.547067: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
             kvm-1180 [018] d... 63148.547070: kvm_entry: vcpu 0
             kvm-1180 [018] d... 63148.547186: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
             kvm-1180 [018] d... 63148.547189: kvm_entry: vcpu 0
             kvm-1180 [018] d... 63148.547304: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
             kvm-1180 [018] d... 63148.547307: kvm_entry: vcpu 0
             kvm-1180 [018] d... 63148.547384: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000ef
             kvm-1180 [018] d... 63148.547391: kvm_entry: vcpu 0

When I change qemu version from 2.1.2 to 2.6.0. The vcpu0 will return 0 qemu.
I got strace like this:
strace -p 1180
Process 1180 attached - interrupt to quit
rt_sigtimedwait([BUS USR1], 0x7f719b5fa960, {0, 0}, 8) = -1 EAGAIN (Resource temporarily unavailable)
rt_sigpending([])                       = 0
futex(0x55669f356d60, FUTEX_WAKE_PRIVATE, 1) = 1
ioctl(26, KVM_RUN

The kvm tracing like this:
             kvm-1180  [018] d... 63148.545821: kvm_entry: vcpu 0
             kvm-1180  [018] d... 63148.545944: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
             kvm-1180  [018] d... 63148.545948: kvm_entry: vcpu 0
             kvm-1180  [018] d... 63148.546083: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
             kvm-1180  [018] d... 63148.546085: kvm_entry: vcpu 0
             kvm-1180  [018] d... 63148.546200: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
             kvm-1180  [018] d... 63148.546202: kvm_entry: vcpu 0
             kvm-1180  [018] d... 63148.546317: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
             kvm-1180  [018] d... 63148.546320: kvm_entry: vcpu 0
             kvm-1180  [018] d... 63148.546436: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
             kvm-1180  [018] d... 63148.546439: kvm_entry: vcpu 0
             kvm-1180  [018] d... 63148.546553: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
             kvm-1180  [018] d... 63148.546556: kvm_entry: vcpu 0
             kvm-1180  [018] d... 63148.546689: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
             kvm-1180  [018] d... 63148.546691: kvm_entry: vcpu 0
             kvm-1180  [018] d... 63148.546807: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
             kvm-1180  [018] d... 63148.546810: kvm_entry: vcpu 0
             kvm-1180  [018] d... 63148.546927: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
             kvm-1180  [018] d... 63148.546930: kvm_entry: vcpu 0
             kvm-1180  [018] d... 63148.547067: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
             kvm-1180  [018] d... 63148.547070: kvm_entry: vcpu 0
             kvm-1180  [018] d... 63148.547186: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
             kvm-1180  [018] d... 63148.547189: kvm_entry: vcpu 0
             kvm-1180  [018] d... 63148.547304: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
             kvm-1180  [018] d... 63148.547307: kvm_entry: vcpu 0
             kvm-1180  [018] d... 63148.547384: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000ef
             kvm-1180  [018] d... 63148.547391: kvm_entry: vcpu 0

Revision history for this message

Denis V. Lunev (r-den) wrote on 2016-06-18:

Win2k8 EFI has a bug under HyperV. This will never work without a specific hack in UEFI. I can dig in my archives to find a patch if you are really interested in. AFAIR some memory in video driver has to be marked not as boot services but differently and will stay permanently.

Revision history for this message

Richard Zhang (richardzzj) wrote on 2016-06-18:

Hi Denis, thank you very much. I do really be interested in it. If the patch can be found, it readlly help me.

And I still have another question. I notice that Win2k8 cound runnig with UEFI normally on Xen and VMare. Is there any diffrence between them abount handling with video, especially on Xen enviroment？

Thank you very much!

Revision history for this message

Denis V. Lunev (r-den) wrote on 2016-06-18:

you CAN run, but you have to disable HyperV enlightments. This means that these options "hv_time,hv_relaxed,hv_spinlocks=0x2000" must NOT be set.

I have not found exact patch, sorry. But something like the following should be done even to start thinking on running win2k8 with EFI if HyperV is enabled. Look into OvmfPkg/QemuVideoDxe/ and replace allocations of EfiBootServicesData/EfiBootServicesCode with EfiACPIMemoryNVS.

For our case we have found that "The problem is triggered by the Windows memory manager unmapping the page #0 while Windows HAL keeps thinking it's still available and accesses it.

The unmapping happens because the page #0 is marked by OVMF as EfiBootServicesCode.

Reportedly the access of the page #0 by HAL only happens when the VM announces
the support for Hyper-V enlightenments; otherwise no crashes are observed."

Revision history for this message

Richard Zhang (richardzzj) wrote on 2016-06-18:

Thank you very much. After disabling all HyperV feature, Win2k8 can runnig with multi-vcpus in my enviroment.

Referring to your advice, I will try to runnig Win2k8 with HyperV feature. Thank you very much.

Revision history for this message

Laszlo Ersek (Red Hat) (lersek) wrote on 2016-06-18:

Denis, thanks a lot for the reminder and the analysis here. I knew about this issue at one point -- see https://bugzilla.redhat.com/show_bug.cgi?id=1185253 -- but by now I've completely forgotten that HyperV enlightenments and UEFI SMP Win7 don't mix.

Also, for your analysis in comment #7 -- thanks for that too; I've never dug into it this deep. In the RHBZ I referenced above, there's a link to MSDN -- https://technet.microsoft.com/en-us/library/dn282285.aspx -- which indicates that the UEFI Win7 family was never meant to be run as HyperV guests. Those docs were enough explanation to me.

I don't think hacking on OVMF's VBE shim would be smart at this point -- the VBE shim is already an ugly hack to trick Win7 into working. I think the best course of action here is to disable HyperV enlightenments for Win7 UEFI guests. That's what virt-manager does as well:

https://github.com/virt-manager/virt-manager/commit/cbba1c4dd381

Given that this is not a QEMU issue, I'm closing the report (again).

Changed in qemu:
status:	Incomplete → Invalid

Denis V. Lunev (r-den) on 2016-06-18

Changed in qemu:
status:	Invalid → Confirmed

Revision history for this message

Denis V. Lunev (r-den) wrote on 2016-06-18:

#10

Actually I can provide you with the patch which makes win2k8 + UEFI working if you willing to accept it for mainstream QEMU. It was quite simple. We have prepared it but not sent. Parallels Server 6/Parallels Desktop have this hack around 3-5 years.

I have missed you comment. Closing again.

Changed in qemu:
status:	Confirmed → Invalid

Revision history for this message

Denis V. Lunev (r-den) wrote on 2016-06-18:

#11

sorry, I meant not QEMU but UEFI above.

Revision history for this message

Laszlo Ersek (Red Hat) (lersek) wrote on 2016-06-18:

#12

... In addition to what I said above in comment #9 (which stands), the technical problem with turning the memory allocation in question into AcpiNVS type is that it would prevent *all* OSes from reusing the area.

It would prevent the Windows 7 memory manager from deallocating page #0 (thereby saving Windows 7 HAL's buttocks), correct, but the page would also be lost for other, actually UEFI-abiding, OSes as well. That's a way too high price to pay for bug-compatibility with Windows 7.

This is actually documented in the commit message of https://github.com/tianocore/edk2/commit/90803342b1b6 . An excerpt:

    The Int10h real-mode IVT entry is covered with a Boot Services Code page,
    making that too unaccessible to the rest of edk2. (Thus UEFI guest OSes
    different from the Windows 2008 family can reclaim the page. The Windows
    2008 family accesses the page at zero regardless of the allocation type.)

This was in fact a difference between v1 and v2 of the patch. V1 used EfiReservedMemoryType, but v2 changed that, so that no other OSes would be punished. See esp. the Notes section of v2:

http://thread.gmane.org/gmane.comp.bios.tianocore.devel/7047
http://thread.gmane.org/gmane.comp.bios.tianocore.devel/7127

Revision history for this message

Aleksei Kovura (alex3kov) wrote on 2016-10-13:

#13

I had the same problem and it took me some time to get to this bug report.

Since this behaviour will not change in future versions of Qemu/OVMF, maybe Qemu should recognize this configuration as invalid and print error message instead of failing silently?

Revision history for this message

Laszlo Ersek (Red Hat) (lersek) wrote on 2016-10-15:

#14

@alex3kov -- I think you mean the question as

"""
Since this behaviour will not change in future versions of Windows 7 / Windows Server 2008 R2, ...
"""

because, again, the problem is not in OVMF but in the Windows guest.

QEMU cannot be expected to recognize (guest OS, guest firmware, hw config) combinations that might not work. That's not QEMU's business.

Such (automatic or semi-automatic) config tweaks belong to the management layer. If you use virt-manager or virt-install to create your guest, and select the guest OS type correctly (or let virt-manager / virt-install recognize the guest type from a signature of the installer ISO, which I believe is implemented with the help of libosinfo), then virt-manager / virt-install will automatically disable Hyper-V enlightments for you. This is what https://bugzilla.redhat.com/show_bug.cgi?id=1185253 was about, which I referenced here earlier.

The virt-manager change is <https://github.com/virt-manager/virt-manager/commit/cbba1c4dd3815e3981d3b315bf28d1018f838702>.

So, the answer to your question is to use libvirt and its tools (which is recommended anyway). Thanks.

(In general, I have no idea why large groups of users keep struggling with QEMU command lines, when the interface that libvirt provides is just so much better and easier for production use. The reason I always recommend libvirt is not because I'm an RH zealot, the reason I recommend it is that libvirt adds *actual value*, even for the individual, interactive user.)