Marcelo Tosatti <mtosatti@xxxxxxxxxx> writes: > On Thu, Mar 18, 2021 at 07:05:49PM +0100, Paolo Bonzini wrote: >> On 18/03/21 19:04, Marcelo Tosatti wrote: >> > > >> > > Not clear why this is necessary, if the choice was to not touch TSC page >> > > at all, when invariant TSC is supported on the host... >> > >> > s/invariant TSC/TSC scaling/ >> > >> > > Ah, OK, this is not for the migration with iTSC on destination case, >> > > but any call to kvm_gen_update_masterclock, correct? >> >> Yes, any update can be racy. >> >> Paolo > > Which makes an unrelated KVM_REQ_MASTERCLOCK_UPDATE -> kvm_gen_update_masterclock > sequence to inadvertedly reduce performance a possibility, unless i am > missing something. > > Ah, OK, it should be enabled again at KVM_REQ_CLOCK_UPDATE. Right, this patch is loosely related to the original problem, it's just something I've noticed while debugging. Unlike kvmclock, which is per-cpu, TSC page is global so only vCPU0 updates it in kvm_guest_time_update() but the potential problem is: some other vCPU may enter the guest before we manage to update the page on vCPU0 and this is racy. Here, we just follow TLFS: invalidate TSC page while we're updating it (on KVM_REQ_MASTERCLOCK_UPDATE). PATCH4, which avoids updating TSC page when re-enlightenment is enabled, also disables this invalidation. This is OK as we're not going to update it. -- Vitaly
