Re: [PATCH] sparc64: shut down to OBP correctly

[Larry Bassel <larry.bassel@oracle.com>]

On 22 Dec 16 09:26, Alexandre Chartre wrote:
> 
> On 12/21/2016 09:15 PM, David Miller wrote:
> >From: Larry Bassel <larry.bassel@oracle.com>
> >Date: Wed, 21 Dec 2016 11:44:07 -0800
> >
> >>On 21 Dec 16 14:06, David Miller wrote:
> >>>From: Larry Bassel <larry.bassel@oracle.com>
> >>>Date: Wed, 21 Dec 2016 10:51:33 -0800
> >>>
> >>>>On 21 Dec 16 13:07, David Miller wrote:
> >>>>>From: Larry Bassel <larry.bassel@oracle.com>
> >>>>>Date: Wed, 21 Dec 2016 09:12:13 -0800
> >>>>>
> >>>>>>Orabug: 24789774
> >>>>>>
> >>>>>>The command "shutdown -h -H now" should shut down the system to
> >>>>>>OBP, however the machine was incorrectly being powered off instead
> >>>>>>(on both LDOM and bare metal).
> >>>>>>
> >>>>>>The "exit" command to the OBP must be run and then a hard
> >>>>>>loop to prevent return to the kernel.
> >>>>>>
> >>>>>>Signed-off-by: Larry Bassel <larry.bassel@oracle.com>
> >>>>>
> >>>>>On LDOM, once you boot past the early stages of the kernel, OBP is
> >>>>>considered volatile and thus unusable.
> >>>>
> >>>>My code does work on an 4.9.0 LDOM (we get to the ok prompt). So you're saying
> >>>>this was a "lucky accident" and there is no "clean" way of getting back to
> >>>>the OBP when we are in a LDOM (i.e. all we can do is power off which is
> >>>>what the current code does)?
> >>>
> >>>Yes, for a very long time the firmware/hypervisor engineers told me
> >>>exactly this.
> >>>
> >>>>Unfortunately, the variable "ldom_domaining_enabled" is 1 even when
> >>>>we are not in an LDOM (I just double checked this by printing
> >>>>the value out as we shut down) and so the current code will power off in
> >>>>the bare metal case as well. Is there is a good way of determining that
> >>>>we are running on bare metal?
> >>>
> >>>Even for bare metal the condition holds.  As long as we use the interfaces
> >>>guarded by ldom_domaining_enabled, the OBP is not reliably available after
> >>>early boot.
> >>
> >>I'm not sure I understand this comment -- are you saying that if we are
> >>bare metal (and somehow can know this), one still cannot call into the OBP?
> >>There are other calls to the OBP (p1275_cmd_direct) in prom/misc_64.c, some
> >>of which are not conditional on ldom_domaining_enabled (which means they
> >>would be called even in the LDOM case).
> >
> >We have to unconditionally allow p1275_cmd_direct() for certain earlier
> >boot calls.
> >
> >The problem, I was told, is that when you boot cpus into the machine using
> >the LDOM cpu start hypercall, you can't use OBP.
> >
> >This is why we pull the entire device tree from OBP into the kernel on
> >the boot processer very early in the boot.  That way we don't need to
> >make OBP calls once we start booting up the non-boot cpus.
> 
> 
> That's correct. The problem is that the OBP won't be aware of any configuration
> change in the domain (like adding/removing cpu, memory or devices) and the OBP
> won't update its device tree. So if you return to the OBP, the behavior is
> unpredictable because the OBP might have outdated information.
> 
> For example, on Solaris, a shutdown/halt command won't directly return to the
> OBP. Instead, it will reset the domain and stop at the OBP ok prompt after the
> domain has been reset. This is done by setting the OBP reboot-command to "noop"
> (to prevent an auto-boot after the reset) and then resetting the domain with
> HV_MACH_SIR.

Thanks for mentioning this. I'm aware of what Solaris does and even have an
earlier (on top of 4.6) version of this patch (which I never sent upstream)
which did exactly that (and it worked).

Is there a consensus that this approach is acceptable? If so, I'll clean up
the earlier version, re-test it and then submit that as v3.

> 
> 
> alex.

Larry