search for: vmx_do_resume

...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 called before vmx_do_resume, which caused the vcpu_info time structure to be updated with the wrong values. This patch fixes this by calling update_vcpu_system_time after the call to hvm_set_guest_time has happened. Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Cc: Keir Fraser <keir@xen.org> Cc: Jan Beuli...

...xen-unstable changset 19590:f80cf52a4fb6 with debugger_attached set, I was seeing the debug traps getting lost from the EXCEPTION_BITMAP in vmx_update_guest_cr() when transitioning from real to protected mode. In my codebase, I could fix this trivially by clearing the debug_state_latch and letting vmx_do_resume() reapply the setting. However, while it looks like a valid issue in the unmodified codebase, I''m not sure. So maybe someone might test/examine it and decide if it is real and whether some more complex fix is required? John Byrne _______________________________________________ Xen-devel...

The attached patch uses per-cpu vmcs pointer to avoid unnecessary vmcs loading in vmx_do_resume(); Signed-off-by: Eric Liu <eric.e.liu@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

This patch series is a reworking of a series developed by Mukesh Rathor at Oracle. The entirety of the design and development was done by him; I have only reworked, reorganized, and simplified things in a way that I think makes more sense. The vast majority of the credit for this effort therefore goes to him. This version is labelled v13 because it is based on his most recent series, v11.