Re: [Xen-devel] S3 sleep in dom0 breaks dom0<->domU wallclock synchronization

[Joanna Rutkowska <joanna@xxxxxxxxxxxxxxxxxxxxxx>]

On 07/06/10 00:50, Jeremy Fitzhardinge wrote:
> On 07/05/2010 03:43 PM, Joanna Rutkowska wrote:
>>> But the S3 suspend/resume is unnoticed by all the domUs, so they don't
>>> know that an enormous amount of time has passed in an instant?
>>>     
>> Correct. I don't think DomU are notified in any way about system suspend
>> -- at least nothing is in the dmesg/messages logs.
>>
>> 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?
> 
> As far as time goes, I think it makes most sense to try and resuse as
> much of the existing kernel machinery as possible, rather than inventing
> anything new.
> 
> I wonder if it makes sense to do a PV checkpoint-resume to PV domains on
> host S3?
> 
>>> Does that affect all the guest clocks, or just wallclock?
>>>
>>>     
>> Not sure if I understand your question -- what do you mean by "all guest
>> clocks"? Like timers? They don't seem to be affected [*], as the apps
>> run smoothly.
>>   
> 
> I mean the other clocks you can real with clock_gettime(), such as
> CLOCK_MONOTONIC or CLOCK_PROCESS_CPUTIME_ID, in addition to CLOCK_REALTIME.
> 

I guess all these other clocks have nothing to do with RTC/wallclock,
right? They are effectively just like any other system timers (they are
system timers), and they are updated by the timer interrupt and they
don't need RTC to be happy? So, I would say they are fine, just like all
the other timers, as otherwise I would expect DomUs to explode/hang
after resume.

joanna.

signature.asc
Description: OpenPGP digital signature

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