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

[bobooscar]

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 <address@hidden> 
日期: 2013-07-04  18:06  (GMT+08:00) 
收件人： bobooscar <address@hidden> 
抄送： address@hidden 
主题： 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