[Qemu-devel] 回复： Re: 回复： Re: 回复： Re: Which part of qemu responds to ACPI control method?

[Qemu-devel] 回复： Re: 回复： Re: 回复： Re: Which part of qemu responds to ACPI control method?

[bobooscar]

[-- Attachment #1: Type: text/plain, Size: 2952 bytes --]

To laszlo: unfortunitely, thereˊs no _S3, _S4, _S5 either.

Back to the *actual* question, the exact problem is as follows:
1 We found that the guest os(rhel 6.1) got stuck(suspended) for about 30-60 seconds after it migrates from host A to host B.
2 such problem doesnˊt occur with guest os rhel6.3
3 itˊs stuck on the dest host, which means that, something is wrong with “resuming” procedure, rather than the “suspend” procedure.
4 we tryed to disable acpi in the guest, (by add “acpi=off” in file /boot/grub/menu.lst),  the problem disappeared!!!

Thus, we suspect that maybe thereˊs some bugs in “acpi” and the “resume” procedure in rhel6.1 guest os, or maybe qemu. Is that because acpi got to resume a list os devices, and resuming a certain device costs too much time?

There comes a question: how do the guest os and qemu communicate with each other, to suspend and resume the guest os, as well as its devices with acpi? 

The exact problem we encouter is: the guest os got suspended for too long while itˊs waking up after migration.

Any suggestion how to analyse and resolve such problem?

Meanwhile, to laszlo, what's the purpose of using “
-global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0” to add to qemu's args?

Thank you very much!!



已从三星手机发送

-------- 原始邮件 --------
发件人： Laszlo Ersek <lersek@redhat.com> 
日期: 2013-07-04  18:06  (GMT+08:00) 
收件人： bobooscar <bobooscar@gmail.com> 
抄送： qemu-devel@nongnu.org 
主题： Re: 回复： Re: 回复： Re: [Qemu-devel] Which part of qemu responds to ACPI control method? 
 
On 07/04/13 08:05, bobooscar wrote:
> Thank you laszlo. however, after I got DSDT.dsl, I found that there is
> no “_PTS” method, even if “_TTS” “_GTS”.  
> Then I go through all the acpi tables, still found no PTS/TTS methods:
>     acpidump > acpidump.out
>     acpixtract -a acpidump.out
>     for file in `ls |grep dat`; do iasl -a $file; done
> 
> The guest os is redhat 6.1 hvm.
> 
> What does that mean? Does that mean this OS does not support
> sleep/wakeup(suspend/resume) with acpi? What caused this problem? Does
> that have anything to do with qemu? (I tried to add logs in
> hwsleep.c:acpi_enter_sleep_mode in the guest kernel code, and found that
> the os does not get here)

Some tables can have several instances, like SSDT; see the --skip option.

But, it seems reasonable that you have found no _PTS method, as SeaBIOS
doesn't seem to define such. Since you started your email with _PTS, I
treated the method as something given in your case. Now I'm supposing
you use SeaBIOS and _PTS not being there is consistent with that.

So, back to square 1, what is your *actual* problem?

In any of the dumped / decompiled SSDT tables, do you see _S3, _S4, _S5
objects?

Maybe try passing the following options to qemu:

  -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0

Laszlo

[-- Attachment #2: Type: text/html, Size: 3635 bytes --]

Re: [Qemu-devel] 回复： Re: 回复： Re: 回复： Re: Which part of qemu responds to ACPI control method?

[Laszlo Ersek]

On 07/08/13 14:24, bobooscar wrote:
> To laszlo: unfortunitely, thereˊs no _S3, _S4, _S5 either.
> 
> Back to the *actual* question, the exact problem is as follows:
> 1 We found that the guest os(rhel 6.1) got stuck(suspended) for about
> 30-60 seconds after it migrates from host A to host B.
> 2 such problem doesnˊt occur with guest os rhel6.3
> 3 itˊs stuck on the dest host, which means that, something is wrong with
> “resuming” procedure, rather than the “suspend” procedure.
> 4 we tryed to disable acpi in the guest, (by add “acpi=off” in file
> /boot/grub/menu.lst),  the problem disappeared!!!
> 
> Thus, we suspect that maybe thereˊs some bugs in “acpi” and the “resume”
> procedure in rhel6.1 guest os, or maybe qemu. Is that because acpi got
> to resume a list os devices, and resuming a certain device costs too
> much time?
> 
> There comes a question: how do the guest os and qemu communicate with
> each other, to suspend and resume the guest os, as well as its devices
> with acpi? 
> 
> The exact problem we encouter is: the guest os got suspended for too
> long while itˊs waking up after migration.
> 
> Any suggestion how to analyse and resolve such problem?

Although you didn't specify your host OS / qemu versions, this might be
related to <https://bugzilla.redhat.com/show_bug.cgi?id=886798>. CC'ing
Amit. Considering the first sentence in your email, and assuming that
you use a RHEL-6 host, the by-default lack of _S3 and _S4 implies a
RHEL-6.2+ host.

The problem could be an ACPI bug in the RHEL-6.1 guest kernel too, one
that got fixed for RHEL-6.3. Any reason you're sticking with a 6.1 guest?

The acpi=off guest kernel parameter probably masks the problem in either
case.

You might want to report the problem through your normal RH channels,
with all relevant details. (We're discussing the problem in reverse
direction now.) For example, host version numbers. A guest vmcore while
stuck could be helpful too.

> Meanwhile, to laszlo, what's the purpose of using “
> -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0” to add to
> qemu's args?

qemu-kvm in RHEL-6.4 (= host) disables S3 and S4 by default. The above
options reenable those sleep states.

Laszlo