This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] PV driver domains and S3 sleep

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] PV driver domains and S3 sleep
From: Rafal Wojtczuk <rafal@xxxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 16 Sep 2010 13:44:24 +0200
Delivery-date: Thu, 16 Sep 2010 04:48:47 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.20 (2009-12-10)

The topic is self-explanatory: how to ensure that a PV driver domain correctly 
prepares its PCI devices for S3 sleep?
If I do "pm-suspend" in dom0, and the driver domain has active network 
suspend hangs the system. Yes, in case of this particular machine, suspend works
fine when there is no driver domain. 
It is possible to manually invoke scripts from /usr/lib64/pm-utils/sleep.d/ in 
domain. In the test case, "ifconfig down wlan0" in the driver domain allows
the suspend to go smoothly. But generally, is it enough ? The kernel device 
driver should 
prepare the PCI device properly for S3, shouldn't it ?  
Would it be more proper to [somehow] notify a driver domain _kernel_ that we 
going to S3 (just like dom0 kernel is notified), and let it execute all 
necessary actions 
(including, but not only, launching of usermode pm-utils scripts), just like 
dom0 kernel 
does ? Would it work at all, considering that driver domain kernel has no 
access to 
ACPI tables ? 
Currently, how are these issues taken care of in the mainstream Xen? 

Thanks in advance,
Rafal Wojtczuk


Xen-devel mailing list