On 07/06/10 12:02, Jan Beulich wrote: >>>> On 06.07.10 at 11:10, Joanna Rutkowska <joanna@xxxxxxxxxxxxxxxxxxxxxx> >>>> wrote: >> On 07/06/10 05:52, Keir Fraser wrote: >>> On 05/07/2010 23:50, "Jeremy Fitzhardinge" <jeremy@xxxxxxxx> wrote: >>> >>>>> BTW: wouldn't it be good to actually notify them? Consider e.g. DomU >>>>> that has some device assigned to it (say a NIC) -- if we emulated S3 >>>>> suspend/resume for this DomU, there is a hope it would properly >>>>> suspend/reinitialize the NIC, wouldn't it? >>>>> >>>> >>>> I guess? That implies some kind of PV S3 suspend and resume event to >>>> feed into the dom U's device model. What does 2.6.18-xen do? >>> >>> I don't think our S3 support is very compatible with PV device passthrough. >>> We support HVM virtual S3, and can S3-sleep HVM guests across real host S3, >>> but we don't have similar for PV guests. >>> >> >> How about implementing something very simple, like a notification via >> xenstore (say, Dom0 would be setting some key)? Interested DomUs could >> then register a watch, and get notified when the system was resumed from >> S3. This would let them e.g. to call whatever hypercall is used normally >> on DomU boot to sync DomU wallclock, or reinitialize/reconnect the NIC. > > Wouldn't it be much simpler to not introduce any new logic at all and > just let Dom0 tools/scripts take care of properly suspending > (checkpointing) all (minimally all pv, but I would really think treating > different kinds of guests differently here is unnecessary) guests > before doing a host suspend, as Jeremy had suggested in an earlier > reply? > But wouldn't this require dumping all the VMs memory do disk? Can we use xm pause instead, i.e. will it notify VMs properly? j.
Description: OpenPGP digital signature
_______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel