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 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.
>
Nod.
> > 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.
Yes. We should not trust a guest to do the "right thing".
>
> > 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) ...
Yes. Can't say I fully understand how this works on real HW. I know
that there are separate "power planes" for different system sates
(this is defined in ACPI spec). So in S3 some devices (or even part of
a device?) may be powered down, but others still have power. Not sure
we should dive into emulating that in this patch series.
>
> > 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
--
Gleb.
