qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 05/11] suspend: add infrastructure


From: Gerd Hoffmann
Subject: Re: [Qemu-devel] [PATCH v4 05/11] suspend: add infrastructure
Date: Tue, 14 Feb 2012 09:57:01 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.26) Gecko/20120130 Red Hat/3.1.18-1.el6_2 Thunderbird/3.1.18

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 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 entering s3.
>>
> Current code calls qemu_system_reset_request() which takes care of
> stopping (and reseting) all vcpus (and rest of the machine) by setting
> reset_requested flag immediately on suspend.

No.  The current code simply has no separate suspend and wakeup steps.

> We cannot just stop
> current cpu on S3 and delay reset till wakeup since guest can leave
> other vcpus in spinning state and they will take 100% of host cpu while
> guest is suspended.

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.

> I think it is also important to reset all device
> immediately to ensure that no device will do DMA into main memory after
> suspend.

Didn't investigate yet, but I suspect this could break wakeup from pci
devices (nic, usb-tablet via uhci) ...

> Technically if this happens it would be a guest bug since
> guest should make sure that devices are stopped before entering S3,
> but I wouldn't want to debug such bug report :)

... and it shouldn't be needed.  Although I agree that bugs in that area
are nasty to debug ...

cheers,
  Gerd



reply via email to

[Prev in Thread] Current Thread [Next in Thread]