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
