Re: [PATCH v8 13/17] KVM: x86: Disable preemption, not IRQs, when getting TSC+freq pair

On Wed, 2026-08-05 at 08:16 -0700, Sean Christopherson wrote:
> 
> David, any thoughts?  I'm leaning towards keeping IRQs disabled to minimize the
> chances of introducing a regression, even though I highly doubt disabling IRQs
> to provide an atomic-ish pair was ever done deliberately.  My main concern with
> disabling IRQs is that it will further muddy the waters with respect to what is
> actually necessary, versus weird things KVM does for historical reasons.  Though
> that can largely be solved with a verbose changelog.

I'm not sure I'd bother. There are plenty of other places we use an
"atomic-ish pair", although I've tried to kill most of those by the
time we get to the end of my series. And we don't disable interrupts
around them all; why should this one do so just because it accidentally
inherited it for other reasons?

I'd rather just keep on with eliminating those cases for all the
masterclock code paths, and reducing the cases where we *don't* use
masterclock (I've already fixed it for the case where TSCs are offset
but running at the same frequency; the old_kvmclock thing is on my
radar too).