diff options
author | Keir Fraser <keir.fraser@citrix.com> | 2009-12-14 07:55:35 +0000 |
---|---|---|
committer | Keir Fraser <keir.fraser@citrix.com> | 2009-12-14 07:55:35 +0000 |
commit | 75b0781226de01514018cdaf94a9bedd8cccc5e6 (patch) | |
tree | b237fc2f81870769ba3a6effa60f837ae60a6e84 /tools/hotplug | |
parent | 3535332327305778c02ac1a8fc49bec29e842b20 (diff) | |
download | xen-75b0781226de01514018cdaf94a9bedd8cccc5e6.tar.gz xen-75b0781226de01514018cdaf94a9bedd8cccc5e6.tar.bz2 xen-75b0781226de01514018cdaf94a9bedd8cccc5e6.zip |
Fix clock for XCP Windows PV drivers on restore
This fixes a timekeeping issue for 32 bit guests running XCP Windows
paravirtual drivers on a 64 bit hypervisor where their clock was set
to the 1970s after live migration or restore. Thanks to Paul Durrant
for helping track this down.
>From the original XCP patch:
Arrange that the wallclock time fields in the shared_info structure
are set correctly in 32 bit HVM guests on a 64 bit hypervisor. HVM
guests on a 64 bit hypervisor always start with a 64 bit shared info,
and then change to a 32 bit one if they're using 32 bit drivers. The
32-bit and 64-bit shared info structures put their wallclock times in
slightly different places, and so the wallclock time needs to be
regenerated when you do the conversion.
It can be argued that we should convert the other fields of shared
info at the same time (e.g. if an event channel is pending beforehand,
it should be pending afterwards), but that's much harder to arrange,
because the 32 bit structure can't represent all the states which the
64 bit one can. Just setting the time seems to be sufficient for
our purposes.
Signed-off-by: Steven Smith <steven.smith@citrix.com>
Signed-off-by: Keith Coleman <keith@scaltro.com>
Diffstat (limited to 'tools/hotplug')
0 files changed, 0 insertions, 0 deletions