On 15/03/17 16:43, Boris Ostrovsky wrote: > On 03/15/2017 11:26 AM, Andrew Cooper wrote: >> On 15/03/17 15:23, Olaf Hering wrote: >>> On Wed, Mar 15, Olaf Hering wrote: >>> >>>> On Wed, Mar 15, Andrew Cooper wrote: >>>>> As a crazy idea, doest this help? >>>>> tsc->incarnation = 0 >>> This does indeed help. One system shows now the results below, which >>> means the performance goes down during migration (to localhost) and goes >>> back to normal after migration. >>> >>> What impact has such change to ->incarnation? >> So what this means is that, after migrate, Xen sees that the advertised >> TSC value doesn't match the current hardwares TSC, so enables rdtsc >> interception so the values reported back can be emulated at the old >> frequency. >> >> There is no easy solution to this problem. > > Would > > tsc_mode="never" > > help?
Only for frequency matched hosts. Hmm, especially for pv guests this should be solvable: after a migration the guest kernel could resync the tsc frequency and there wouldn't be further tsc emulation needed. This would just require a new hypercall for obtaining the current tsc frequency. This hypercall would: - switch off tsc emulation for the calling vcpu (if allowed by tsc_mode) - return the real tsc frequency (and offset?) As the guest kernel is aware of the migration it could issue the new hypercall on each vcpu and everyone is happy again. Thoughts? Juergen _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
