On 25/05/21 17:58, Sean Christopherson wrote:
The right place for the hw multiplier
field to be updated is inside set_tsc_khz() in common code when the ratio
changes.
Sort of, the problem is that you have two VMCS's to update. If properly
fixed, the cache is useful to fix the issue with KVM_SET_TSC_KHZ needing
to update both of them. For that to work, you'd have to move the cache
to struct loaded_vmcs.
So you can:
1) move the cached tsc_ratio to struct loaded_vmcs
2) add a function in common code (update_tsc_parameters or something
like that) to update both the offset and the ratio depending on
is_guest_mode()
3) call that function from nested vmentry/vmexit
And at that point the cache will do its job and figure out whether a
vmwrite is needed, on both vmentry and vmexit.
I actually like the idea of storing the expected value in kvm_vcpu and
the current value in loaded_vmcs. We might use it for other things such
as reload_vmcs01_apic_access_page perhaps.
Paolo
However, this requires adding another vendor callback etc. As all
this is further refactoring I believe it's better to leave this series as is -
ie only touching code that is directly related to nested TSC scaling and not
try to do everything as part of the same series.
But it directly impacts your code, e.g. the nested enter/exit flows would need
to dance around the decache silliness. And I believe it even more directly
impacts this series: kvm_set_tsc_khz() fails to handle the case where userspace
invokes KVM_SET_TSC_KHZ while L2 is active.
