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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|