From: Eduardo Habkost <ehabkost@redhat.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Avi Kivity <avi@redhat.com>, Ingo Molnar <mingo@elte.hu>,
Andrey Borzenkov <arvidjaar@mail.ru>,
mingo@redhat.com, Andrew Morton <akpm@osdl.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Use BIOS reboot on Toshiba Portege 4000
Date: Tue, 4 Nov 2008 09:57:41 -0200 [thread overview]
Message-ID: <20081104115741.GE23893@blackpad> (raw)
In-Reply-To: <m163n3burt.fsf@frodo.ebiederm.org>
On Tue, Nov 04, 2008 at 03:22:30AM -0800, Eric W. Biederman wrote:
> Avi Kivity <avi@redhat.com> 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
prev parent reply other threads:[~2008-11-04 11:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-31 18:18 [PATCH] Use BIOS reboot on Toshiba Portege 4000 Andrey Borzenkov
2008-11-03 9:08 ` Ingo Molnar
2008-11-03 10:02 ` Avi Kivity
2008-11-03 10:04 ` Ingo Molnar
2008-11-03 13:33 ` Eduardo Habkost
2008-11-03 14:41 ` Avi Kivity
2008-11-03 16:13 ` Eric W. Biederman
2008-11-03 17:01 ` Eduardo Habkost
2008-11-04 10:47 ` Avi Kivity
2008-11-04 11:22 ` Eric W. Biederman
2008-11-04 11:57 ` Eduardo Habkost [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081104115741.GE23893@blackpad \
--to=ehabkost@redhat.com \
--cc=akpm@osdl.org \
--cc=arvidjaar@mail.ru \
--cc=avi@redhat.com \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mingo@redhat.com \
--cc=rjw@sisk.pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox