Hi,
>> I see. I've expeced the the guest os putting them into a hlt loop or
>> some simliar idle state. Play save and expliticly pausing them all is
>> certainly good from a robustness perspective.
> Yes. We should not trust a guest to do the "right thing".
Updated patch attached.
>>> I thin
On Tue, Feb 14, 2012 at 09:57:01AM +0100, Gerd Hoffmann wrote:
> On 02/14/12 09:37, Gleb Natapov wrote:
> > On Tue, Feb 14, 2012 at 09:18:34AM +0100, Gerd Hoffmann wrote:
> >> Hi,
> >>
> >>> Shouldn't we stop the whole VM at some point, not only vcpu that
> >>> does ACPI IO? May be I missed where
On 02/14/12 09:37, Gleb Natapov wrote:
> On Tue, Feb 14, 2012 at 09:18:34AM +0100, Gerd Hoffmann wrote:
>> Hi,
>>
>>> Shouldn't we stop the whole VM at some point, not only vcpu that
>>> does ACPI IO? May be I missed where it is done in the patch series.
>>
>> It isn't hidden elsewhere, qemu does
On Tue, Feb 14, 2012 at 09:18:34AM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > Shouldn't we stop the whole VM at some point, not only vcpu that
> > does ACPI IO? May be I missed where it is done in the patch series.
>
> It isn't hidden elsewhere, qemu doesn't do it. The code was like that
> befor
Hi,
> Shouldn't we stop the whole VM at some point, not only vcpu that
> does ACPI IO? May be I missed where it is done in the patch series.
It isn't hidden elsewhere, qemu doesn't do it. The code was like that
before, and I think the reason is that the guest has to stop the other
cpus before
On Thu, Feb 09, 2012 at 06:05:37PM +0100, Gerd Hoffmann wrote:
> This patch adds some infrastructure to handle suspend and resume to
> qemu. First there are two functions to switch state and second there
> is a suspend notifier:
>
> * qemu_system_suspend_request is supposed to be called when the
