On Mon, Jan 24, 2022 at 03:44:53PM +0100, Jan Beulich wrote: > On 20.01.2022 16:52, Roger Pau Monné wrote: > > On Thu, Jan 20, 2022 at 03:04:39PM +0100, Jan Beulich wrote: > >> From: Artem Bityutskiy <artem.bityuts...@linux.intel.com> > >> Unlike Linux we want to disable IRQs again after MWAITing, as > >> subsequently invoked functions assume so. > > > > I'm also wondering whether there could be interrupts that rely on some > > of the housekeeping that's done when returning from mwait. I guess > > it's unlikely for an interrupt handler to have anything to do with the > > TSC not having been restored. > > Actually this is a good point you make: We don't want to enable > IRQs when cstate_restore_tsc() is not a no-op, or else we might > confuse the time rendezvous. (I thought that I would remember > TSC to stop only in deeper C-states, but maybe I'm mixing this up > with the APIC timer.)
There's a comment in time.c that mentions the TSC only stopping in 'deep C states'. Also note that in that case the rendezvous function already updates the TSC, so I'm not sure whether calling it with an out of date TSC would be harmful - it will be updated anyway to match the master TSC. Might be safer to disable interrupts unconditionally on CPUs that don't have a non-stop TSC just to be on the safe side. Thanks, Roger.
