From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH 0/4] HVM Virtual S3 Date: Thu, 08 May 2008 16:03:15 +0100 Message-ID: References: <391BF3CDD2DC0848B40ACB72FA97AD590352E41A@pdsmsx413.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <391BF3CDD2DC0848B40ACB72FA97AD590352E41A@pdsmsx413.ccr.corp.intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Ke, Liping" , Ian Pratt , xen-devel@lists.xensource.com Cc: "Tian, Kevin" , "Jiang, Yunhong" , "Yu, Ke" List-Id: xen-devel@lists.xenproject.org On 8/5/08 15:57, "Ke, Liping" wrote: >> Further, do we actually need the s3 resume hypercall? Couldn't we just >> put the VCPUs and xen-emulated devices into the right state for resume >> at the end of s3 sleep and just leave the domain paused (i.e. >> unscheduled)? > As I can understand, when S3, HVM will perform like native-machine S3, > all execution context are in memory When resume back, jump to the CS/EIP, > those vcpus resume execution normally. > Ke& Kevin, any coments here? I think part of what Ian means is that you may as well have a single interface into each device model in Xen -- e.g., hpet_reset(), pit_reset(), and so on. Rather than have separate poweroff/poweron functions. Apart from the greater simplicity, some models already have a reset interface, and I'm not sure the implemented poweroff/poweron splits are all correct. And then, once the poweron calls are all gone, what else does s3_resume actually have to do? -- Keir