On 20.09.2022 16:26, Boris Ostrovsky wrote: > On 9/20/22 4:01 AM, Jan Beulich wrote: >> On 20.09.2022 00:42, Boris Ostrovsky wrote: >>> It is saving vpmu data from current pcpu's MSRs for a remote vcpu so @v >>> in vmx_find_msr() is not @current: >>> >>> vpmu_load() >>> ... >>> prev = per_cpu(last_vcpu, pcpu); >>> vpmu_save_force(prev) >>> core2_vpmu_save() >>> __core2_vpmu_save() >>> vmx_read_guest_msr() >>> vmx_find_msr() >>> >>> >>> The call to vmx_find_msr() was introduced by 755087eb9b10c. I wonder though >>> whether >>> this call is needed when code path above is executed (i.e. when we are >>> saving >>> remove vcpu) >> >> How could it not be needed? We need to obtain the guest value. The >> thing I don't understand is why this forced saving is necessary, >> when context_switch() unconditionally calls vpmu_switch_from(). > > > IIRC the logic is: > > 1. vcpuA runs on pcpu0 > 2. vcpuA is de-scheduled and is selected to run on pcpu1. It has not yet > called vpmu_load() from pcpu1
The calling of vpmu_load() shouldn't matter here. What does matter is that vpmu_save() was necessarily called already. Therefore I'm having trouble seeing why ... > 3. vcpuB is ready to run on pcpu0, calls vpmu_load() > 4. vcpuB discovers that pcpu0's MSRs are still holding values from vcpuA > 5. vcpuB calls vpmu_force_save(vcpuA) which stashes pcpu0's MSRs into vcpuA's > vpmu context. ... forced saving would be necessary here. What's necessary at this point is only the loading of vcpuB's MSR values. Jan
