[PATCH V2 2/2] powerpc/kexec: Reset HILE before kexec_sequence

[Stewart Smith]

Michael Ellerman <mpe at ellerman.id.au> writes:
>> > I think a better API would be that opal_return_cpu() deals with this under the
>> > covers. I think we talked about that, so maybe there was some reason that
>> > wasn't possible.
>> 
>> opal_return_cpu() acts on current CPU which if we started flipping HILE
>> there we'd hit PowerISA 2.07 Section 2.11:
>> "The contents of the HILE bit must be the same for all
>> threads under the control of a given instance of the
>> hypervisor; otherwise all results are undefined."
>> 
>> so we'd have to do something kind of funny in opal_return_cpu() to work
>> out what's going on. Keeping in mind that opal_return_cpu() is also used
>> in the fsp code update path (which I haven't gone and really looked at
>> in this context though).
>> 
>> I'm not convinced that opal_return_cpu() doing the HILE switch is
>> safe when we'd be relying on the kernel to pretty much do this all at
>> the same time (when we really have opal_reinit_cpus to do that)
>
> Yeah I agree.
>
> What I meant is that after you return a cpu to OPAL, when you (or actually
> someone else) restart it, at that point it should be put into a well defined
> state, including HILE.

I'll go and try and investigate exactly what's going on here with the
hardware, it's possible some of the hardware documentation is Anton
Blanchard and that needs to make it into documents rather than just
skiboot source. Especially around what makes sense for all-at-a-time
(reinit_cpu with HILE switch) versus one at a time (start
cpu/return_cpu).

Of course, that's a skiboot problem rather than a Linux one.

I think Sam is looking at doing the opal call in real mode somewhere in
kexec_sequence just before we jump into the new kernel. This should make
it so that everything works on existing OPAL APIs, while at the same
time we can go and check if there's a sensible/valid way we can deal
with the hardware to get a broader well defined state after certain
calls.

I'm in favor of using existing calls rather than making a firmware
upgrade a requirement though.