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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 10.09.18 at 12:13,  wrote:
>>>> On 07.09.18 at 19:08, <andrew.cooper3@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel