On 07/01/2010 09:12 AM, Keir Fraser wrote:
> On 01/07/2010 16:18, "Joanna Rutkowska" <joanna@xxxxxxxxxxxxxxxxxxxxxx>
> wrote:
>
>
>> Actually we're running a pvops kernel in DomUs (in fact a fairly recent
>> pvops0, as we had some bad experience with regular Fedora kernels in DomU).
>>
>> Running an NTP in every VM is not a good solution. Some VMs might be
>> forbidden any access to the network (e.g. my "vault" VM, that I use for
>> storing passwords, and other very sensitive stuff, doesn't have any
>> networking), while some other might be allowed only very limited network
>> traffic, e.g. only HTTPS to specific, white-listed servers (e.g.
>> "banking" VM).
>>
> Well it would be good to confirm first that this is a pv_ops domU issue. If
> so, it can probably be solved with a command-line option or somesuch, even
> if the default policy will not change.
>
So the problem is that dom0 does the S3 suspend/resume, and presumably
its wallclock time is updated properly via Linux's normal mechanisms.
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? Does
that affect all the guest clocks, or just wallclock?
How does Xen deal with the S3 suspend/resume? Does the system clock
just keep ticking as usual (so the whole suspended time appears to be
sub-nanosecond), but the wallclock offset gets updated? Or does it try
to workout how long the suspended time was and adjusts the system time
accordingly? That would allow guest timekeeping to compensate for the
suspended time, assuming they can deal with large forward leaps.
What happens with pending timers?
J
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home