> On May 31, 2019, at 7:31 AM, Jiri Kosina <ji...@kernel.org> wrote:
> 
>> On Fri, 31 May 2019, Andy Lutomirski wrote:
>> 
>> 2. Put the CPU all the way to sleep by sending it an INIT IPI.
>> 
>> Version 2 seems very simple and robust.  Is there a reason we can't do
>> it?  We obviously don't want to do it for normal offline because it
>> might be a high-power state, but a cpu in the wait-for-SIPI state is
>> not going to exit that state all by itself.
>> 
>> The patch to implement #2 should be short and sweet as long as we are
>> careful to only put genuine APs to sleep like this.  The only downside
>> I can see is that an new kernel resuming and old kernel that was
>> booted with nosmt is going to waste power, but I don't think that's a
>> showstopper.
> 
> Well, if *that* is not an issue, than the original 3-liner that just 
> forces them to 'hlt' [1] would be good enough as well.
> 
> 

Seems okay to me as long as we’re confident we won’t get a spurious interrupt.

In general, I don’t think we’re ever suppose to rely on mwait *staying* asleep. 
 As I understand it, mwait can wake up whenever it wants, and the only real 
guarantee we have is that the CPU makes some effort to stay asleep until an 
interrupt is received or the monitor address is poked.

As a trivial example, if we are in a VM and we get scheduled out at any point 
between MONITOR and the eventual intentional wakeup, we’re toast. Same if we 
get an SMI due to bad luck or due to a thermal event happening shortly after 
pushing the power button to resume from hibernate.

For that matter, what actually happens if we get an SMI while halted?  Does RSM 
go directly to sleep or does it re-fetch the HLT?

It seems to me that we should just avoid the scenario where we have IP pointed 
to a bogus address and we just cross our fingers and hope the CPU doesn’t do 
anything.

I think that, as a short term fix, we should use HLT and, as a long term fix, 
we should either keep the CPU state fully valid or we should hard-offline the 
CPU using documented mechanisms, e.g. the WAIT-for-SIPI state.

Reply via email to