From: Zhou Jacky <jackyzt98@gmail.com>
To: xen-devel@lists.xen.org
Subject: [bug report] Windows HVM Hang when reboot/power off using special config
Date: Tue, 5 Jun 2012 11:46:45 +0800 [thread overview]
Message-ID: <CAMT9dFFO05SLzc8GoF288AT08a5SJvzS77MMbCFdxtJ8_pHeVg@mail.gmail.com> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 2261 bytes --]
Hi,
Seems there's a bug when booting HVM guest Windows 2003 using
special config (pin 2 VCPUs to same phy CPU). The guest OS will hange when
reboot or power off system
in guest. The CPU will be 100 percent when watching xentop. The config file
as following:
****************************************************
kernel="/usr/lib/xen-4.1/boot/hvmloader"
builder='hvm'
name="windows_2003"
uuid="bb29f502-315a-488d-a234-c5651bcd6fbe"
memory=4096
vcpus=2
on_reboot='restart'
on_crash='restart'
sdl=0
vnc=1
vnclisten="0.0.0.0"
vncdisplay=29
stdvga=0
serial='pty'
usbdevice='tablet'
localtime=1
cpus=['5','5']
***************************************
Then I debug qemu-dm, find the OS never execute the ACPI register write, so
the QEMU can not catch the system reboot/power off event.
The normal case for guest OS poweroff will be : at first all system
process/driver quit, then OS write ACPI register to poweroff system power.
1. Qemu fetch the register memory map in shared page, judge if it's ACPI
register write.
2. If it's a reset, reboot, poweroff ACPI register operation, then
call qemu_system_shutdown_request() or qemu_system_reset_request()
to set a flag
3. If the flag be set, call destroy_hvm_domain()
4. Qemu process quit, xend clear other resource
In my case, the qemu_system_shutdown_request ( ACPI register write ) never
be triggered. And the VCPU usage be 100 percent.
So I think it must exist some spinlock-like code in guest OS which cause
the ACPI write never be executed.
If I pin one VCPU to another CPU like '6', then ACPI register write be
called immediately, guest OS poweroff smoothly.
So anyone know why it's not work when PIN 2 VCPUs to same physical CPU when
booting HVM Windows 2003? Thanks.
Normal call stack:
qemu_system_reset_request () at /root/qemu/xen-4.1.2/qemu/vl.c:3673
#1 0x000000000047950a in cpu_ioreq_pio (req=0x7ff6d7dbd000, env=0x22a1c40)
at /root/qemu/xen-4.1.2/qemu/i386-dm/helper2.c:351
#2 __handle_ioreq (env=0x22a1c40, req=0x7ff6d7dbd000) at
/root/qemu/xen-4.1.2/qemu/i386-dm/helper2.c:446
#3 0x0000000000479d7b in cpu_handle_ioreq (opaque=0x22a1c40) at
/root/qemu/xen-4.1.2/qemu/i386-dm/helper2.c:515
#4 0x000000000040d81f in main_loop_wait (timeout=<optimized out>) at
/root/qemu/xen-4.1.2/qemu/vl.c:3794
[-- Attachment #1.2: Type: text/html, Size: 2556 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next reply other threads:[~2012-06-05 3:46 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-05 3:46 Zhou Jacky [this message]
2012-06-06 11:12 ` [bug report] Windows HVM Hang when reboot/power off using special config George Dunlap
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMT9dFFO05SLzc8GoF288AT08a5SJvzS77MMbCFdxtJ8_pHeVg@mail.gmail.com \
--to=jackyzt98@gmail.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).