[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 0/6] PM extension to domU


  • To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Wed, 07 Feb 2007 01:57:20 +0000
  • Delivery-date: Tue, 06 Feb 2007 17:57:07 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcdJxpGp/qx+TgWOS6iQUGwbfBu5mQAcYarIAAczzZAAAZln5g==
  • Thread-topic: [Xen-devel] [PATCH 0/6] PM extension to domU

On 7/2/07 01:25, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:

>> Have you considered destroying and recreating driver domains rather
>> than
>> sleeping them? They are stateless after all, and should be quick (enough)
>> to
>> boot.
> 
> Sorry that I don't quite understand you. For suspend-to-disk, maybe
> we can use that policy to recreate driver domains. But for
> suspend-to-ram, that process is still slow and we just need suspend
> domain itself. Also I'm not sure why it's stateless... How do you
> recover workloads after re-creation?

A proper driver domain would be little more than a device driver wrapped in
minios-style Xen-interfacing code. They should be quick to start, and
restart would lose no workload. I suppose there are people running device
drivers as part of a full guest however...

Is it necessary to sleep/wake non driver domains? Could we check in S3
support that would work for systems with all drivers in dom0, and then
consider this patchset as an extension?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.