Re: [PATCH v3 09/12] KVM: VMX: Remove vmx->current_tsc_ratio and decache_tsc_multiplier()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.





[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux