From: Cyrill Gorcunov <gorcunov@gmail.com>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: Don Zickus <dzickus@redhat.com>, Andi Kleen <andi@firstfloor.org>,
mingo@elte.hu, fweisbec@gmail.com, robert.richter@amd.com,
linux-kernel@vger.kernel.org
Subject: Re: [RFC] arch generic way to trigger unknown NMIs
Date: Sat, 16 Oct 2010 20:36:57 +0400 [thread overview]
Message-ID: <20101016163657.GB6763@lenovo> (raw)
In-Reply-To: <alpine.LFD.2.00.1010161710290.15889@eddie.linux-mips.org>
On Sat, Oct 16, 2010 at 05:15:16PM +0100, Maciej W. Rozycki wrote:
> On Sat, 16 Oct 2010, Cyrill Gorcunov wrote:
>
> > Hi Maciej, the send_IPI_self could be modified to send NMI (at moment it
> > uses self shortcut with fixed delivery mode). The question is rather if
> > we need it without a real caller yet. When Don's patch gets merged we
> > will have a real caller then and could update send_IPI_self to support
> > NMI delivery mode. Something like that :)
>
> Sounds backwards to me. My understanding is a need has just arisen, so
> why not:
>
> 1. Update send_IPI_self().
>
> 2. Add code that makes use of the new functionality.
>
> 3. Submit all the changes as self-contained patches in a single series to
> be applied at the same time.
>
> ? That's what I'd imagine the most natural way of doing this would be.
>
> Maciej
>
Well, Maciej I believe the problem is not in modifying send_IPI_self
but rather _how_ to make it more natural and do not introduce overhead.
apic code is already weird enough :) Need to think.
(
btw, we will have to add additional flag which would check for NMI
being generated by "NMI-tester" and make a second apic write to
ICR to deassert level line, ie it could be something like
apic->send_IPI_self(NMI_VECTOR) ; with asserts level
default_do_nmi() ; check for NMI being sent for testing purpose
apic->send_IPI_self(NMI_VECTOR) ; with deasserts level
iirc apic itself doesn't deassert nmi line on message with
nmi deliver mode arrival
)
Cyrill
next prev parent reply other threads:[~2010-10-16 16:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-07 3:08 [RFC] arch generic way to trigger unknown NMIs Don Zickus
2010-10-07 7:26 ` Andi Kleen
2010-10-07 14:01 ` Don Zickus
2010-10-07 15:11 ` Andi Kleen
2010-10-07 15:47 ` Don Zickus
2010-10-07 16:17 ` Andi Kleen
2010-10-07 22:45 ` Maciej W. Rozycki
2010-10-10 20:23 ` Cyrill Gorcunov
2010-10-16 7:24 ` Maciej W. Rozycki
2010-10-16 15:32 ` Cyrill Gorcunov
2010-10-16 16:15 ` Maciej W. Rozycki
2010-10-16 16:36 ` Cyrill Gorcunov [this message]
2010-10-16 23:59 ` Maciej W. Rozycki
2010-10-17 8:58 ` Cyrill Gorcunov
2010-10-17 16:08 ` Cyrill Gorcunov
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=20101016163657.GB6763@lenovo \
--to=gorcunov@gmail.com \
--cc=andi@firstfloor.org \
--cc=dzickus@redhat.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=macro@linux-mips.org \
--cc=mingo@elte.hu \
--cc=robert.richter@amd.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.