Re: [PATCH 2/5] x86/idle: re-arrange dead-idle handling

["Jan Beulich" <JBeulich@suse.com>]

>>> On 07.09.18 at 19:08, <andrew.cooper3@citrix.com> wrote:
> On 01/08/18 15:31, Jan Beulich wrote:
>> In order to be able to wake parked CPUs from default_dead_idle(), the
>> function must not itself loop. Move the loop into play_dead(), and use
>> play_dead() as well on the AP boot error path.
>>
>> Furthermore, not the least considering the comment in play_dead(),
>> make sure NMI raised (for now this would be a bug elsewhere, but that's
>> about to change) against a parked or fully offline CPU won't invoke the
>> actual, full-blown NMI handler.
> 
> I'm concerned by this.  It isn't necessarily a bug elsewhere, because
> the CPU can still participate in SMM, and still have the SMM handler
> raise an NMI.

What significance does an NMI have when raised towards an offline
CPU? If SMM does this, then I'd very much guess this is happening in
a broadcast fashion (otherwise they'd surely raised it against CPU 0),
and in that case NOP-ing the effect for parked CPUs seems quite
appropriate to me.

> Equally, it may still be able to service #MC's, so I can't see how it is
> safe for us to ever free the percpu data.

I'm having trouble seeing how this remark relates to the series here.
Plus it's a theoretical problem at present only anyway:
- physical hot remove is not implemented (there's no source of the
  new CPU_REMOVE notification),
- Intel CPUs get parked, i.e. never have their per-CPU data freed,
- AMD CPUs don't broadcast #MC.

Bottom line for both parts of your reply: I don't see any proposal /
request of what you think needs changing, and how. Unless,
perhaps, you're suggesting the entire series is rubbish, in which
case I'd like you to propose an alternative approach to address
the problem of parking CPUs in C1 instead of deepest possible
C-states.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel