search for: stime_offset

When using a vtsc, hvm_set_guest_time changes hvm_vcpu.stime_offset, which is used in the vcpu time structure to calculate the tsc_timestamp, so after updating stime_offset we need to propagate the change to vcpu_time in order for the guest to get the right time if using the PV clock. This was not done correctly, since in context_switch update_vcpu_system_time was...

Hi Ian/Stefano: I changed over to the PV clock for hybrid liked we talked at the hackathon. I still have the hang in update_wall_time() after dom0 switches to xen as clocksource. The source of hang seems to be in xen stime_local_stamp in cpu_time that suddenly jumps to a large 64bit value. I''ve been chasing to figure where that happens, and why for the hybrid and not PV. It appears the

flight 18092 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/18092/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail pass in 18090 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass

The value of ACPI PM-Timer may be broken on save unless the timer mode is delay_for_missed_ticks. With other timer modes, vcpu->arch.hvm_vcpu.guest_time is always zero and the adjustment from its value is wrong. This patch fixes the saved value of ACPI PM-Timer: - don''t adjust the PM-Timer if vcpu->arch.hvm_vcpu.guest_time is zero. - consolidate calculations of PM-Timer to one