On Wed, 2023-09-13 at 07:50 -0700, Sean Christopherson wrote: > On Wed, Sep 13, 2023, David Woodhouse wrote: > > Userspace used to be able to force a sync by writing zero. You are > > removing that from the ABI without any explanation about why; > > No, my suggestion did not remove that from the ABI. A @user_value of '0' would > still force synchronization. Ah, OK. Yes, you're right. Thanks. > It's necessary for "user_set_tsc" to be an accurate name. The code in v6 yields > "user_set_tsc_to_non_zero_value". And I don't think it's just a naming issue, In another thread, you said that the sync code doesn't differentiate between userspace initializing the TSC And userspace attempting to synchronize the TSC. I responded that *I* don't differentiate the two and couldn't see the difference. I think we were both wrong. Userspace does *explicitly* synchronize the TSC by writing zero, and the sync code *does* explicitly handle that, yes? And the reason I mention it here is that we could perhaps reasonable say that userspace *syncing* the TSC like that is not the same as userspace *setting* the TSC, and that it's OK for user_set_tsc to remain false? It saves adding another argument to kvm_synchronize_tsc() making it even more complex for a use case that just doesn't make sense anyway... > e.g. if userspace writes '0' immediately after creating, and then later writes a > small delta, the v6 code wouldn't trigger synchronization because "user_set_tsc" > would be left unseft by the write of '0'. True, but that's the existing behaviour, and it doesn't make much sense for the user to write 0 to trigger a sync immediately after creating, because the *kernel* does that anyway. I don't feel particularly strongly. Having a commit message and code comments which clearly set out the reasoning for the 1-second slop and the reasons why we want to *stop* doing it in this case, is the important part. That had got lost.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
