From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38976) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RxECC-0006Oh-Lu for qemu-devel@nongnu.org; Tue, 14 Feb 2012 03:57:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RxECA-00061B-GB for qemu-devel@nongnu.org; Tue, 14 Feb 2012 03:57:08 -0500 Received: from mx1.redhat.com ([209.132.183.28]:31263) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RxEC9-000611-Vn for qemu-devel@nongnu.org; Tue, 14 Feb 2012 03:57:06 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1E8v4Eq023443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 14 Feb 2012 03:57:05 -0500 Message-ID: <4F3A21DD.2090601@redhat.com> Date: Tue, 14 Feb 2012 09:57:01 +0100 From: Gerd Hoffmann MIME-Version: 1.0 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> In-Reply-To: <20120214083753.GZ18866@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4 05/11] suspend: add infrastructure List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: qemu-devel@nongnu.org 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