From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33764) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RxENI-0001nJ-PR for qemu-devel@nongnu.org; Tue, 14 Feb 2012 04:08:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RxENC-00086D-U7 for qemu-devel@nongnu.org; Tue, 14 Feb 2012 04:08:36 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36100) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RxENC-000863-Lu for qemu-devel@nongnu.org; Tue, 14 Feb 2012 04:08:30 -0500 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1E98Tsv027405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 14 Feb 2012 04:08:29 -0500 Date: Tue, 14 Feb 2012 11:08:28 +0200 From: Gleb Natapov Message-ID: <20120214090827.GB18866@redhat.com> References: <1328807143-29499-1-git-send-email-kraxel@redhat.com> <1328807143-29499-6-git-send-email-kraxel@redhat.com> <20120213092123.GV18866@redhat.com> <4F3A18DA.4070405@redhat.com> <20120214083753.GZ18866@redhat.com> <4F3A21DD.2090601@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F3A21DD.2090601@redhat.com> Subject: Re: [Qemu-devel] [PATCH v4 05/11] suspend: add infrastructure List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel@nongnu.org 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.