Re: [PATCH] Use BIOS reboot on Toshiba Portege 4000

[Eduardo Habkost]

On Tue, Nov 04, 2008 at 03:22:30AM -0800, Eric W. Biederman wrote:
> Avi Kivity <avi@xxxxxxxxxx> writes:
> 
> > Eric W. Biederman wrote:
> >> I think we are confusing two issues here.
> >>
> >> - Ordinary machine_restart which happens to call emergency_restart.
> >>   And is proceeded by machine_shutdown.
> >>
> >> - And emergency_restart itself.
> >>
> >> To some extent I would be a lot happier if Alt-sysrq-r did what
> >> was necessary to get into a context where it can call machine_restart
> >> or even better kernel_restart().
> >> emergency_restart() is a nice idea but is broken by design.
> >>
> >>
> >
> > Isn't emergency_restart() equivalent to kexec()?  Both start from indeterminite
> > conditions.
> 
> Good point.  That is a reasonable direction to evolve it on x86.
> Similar to and sharing some of the same code as the kexec on panic path.
> 
> We may need to separate out emergency_restart from the normal clean
> restart to make that happen.  It would be pointless and silly to be
> sending NMI at other cpus for example if we have cleanly shut them
> down already.

When pulling the NMI stuff to the reboot code, I've just hit this issue:
currently, machine_ops.emergency_restart has two possible semantics:

- The function that should be called to immediately reboot the machine,
  after the cleanup done by machine_restart()
- The function that should be called to reboot the machine when we are
  on a possibly inconsistent state (and will do the vmx-disabling
  stuff)

Currently we don't do anything special on emergency_restart() case,
so both cases are equivalent. But now we will need to differentiate
both cases.


...all this work because VMX breaks the good old reset lines.  :\

-- 
Eduardo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/