From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH 0/4] HVM Virtual S3 Date: Thu, 15 May 2008 12:51:35 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Pratt , "Ke, Liping" , "Yu, Ke" , xen-devel@lists.xensource.com Cc: "Tian, Kevin" , "Jiang, Yunhong" List-Id: xen-devel@lists.xenproject.org On 15/5/08 12:45, "Ian Pratt" wrote: >> The 'pause' state visible to tools is a specific type of >> domain_pause(), and >> *has* to be entered via the pause domctl hypercall. So don't worry -- >> your new type of pause should stack on top of 'xm pause/unpause' no > problem. > > In fact, does the S3 suspended guest need to go into a pause state at > all? Presumably we could just let it block? > Xend does need to be able to know when the S3 suspend has actually > happened -- there should probably be a VIRQ for this. S3 suspend is enacted by an I/O port write from the guest, trapped by qemu, so the final reset of machine state is synchronously triggered by the tools anyway. As for pause-vs-block I think this is just a matter of terminology. At the end of the day we want the domain to not run until s3-resume is triggered. The natural way to do this within the hypervisor is to maintain a per-domain is_s3_suspended flag and domain_[un]pause() when this flag toggles. -- Keir