aboutsummaryrefslogtreecommitdiffstats
path: root/tools/hotplug
diff options
context:
space:
mode:
authorKeir Fraser <keir.fraser@citrix.com>2009-12-14 07:55:35 +0000
committerKeir Fraser <keir.fraser@citrix.com>2009-12-14 07:55:35 +0000
commit75b0781226de01514018cdaf94a9bedd8cccc5e6 (patch)
treeb237fc2f81870769ba3a6effa60f837ae60a6e84 /tools/hotplug
parent3535332327305778c02ac1a8fc49bec29e842b20 (diff)
downloadxen-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