Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1220042

Re: Dealing with the NMI mess

From Paolo Bonzini <pbonzini@redhat.com>
Newsgroups linux.kernel
Subject Re: Dealing with the NMI mess
Date 2015-09-07 12:30 +0200
Message-ID <q61Qu-2MN-19@gated-at.bofh.it> (permalink)
References (7 earlier) <pSaTE-4fr-5@gated-at.bofh.it> <pSdy9-84E-3@gated-at.bofh.it> <q5XjQ-4JR-1@gated-at.bofh.it> <q5ZlE-7A1-5@gated-at.bofh.it> <q5ZOG-8nj-21@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw



On 07/09/2015 10:19, Maciej W. Rozycki wrote:
>> > Essentially the ICE breakpoint instruction enters SMM mode?
>  I didn't do stuff at the probe firmware level so I can't say for sure, 
> but my gut feeling is the debug mode is indeed very close if not the same 
> as SMM.  I think duplicating the logic would be an unnecessary waste of 
> silicon.

I researched SMM a bit recently in order to implement it in KVM, and the
best source of folklore seems to be http://www.rcollins.org/ddj (which I
also have on paper :)).

The author there says that SMM design was roughly based on the 386's
probe/ICE mode design, but it's actually separate.  Most notably, on the
386 the state save areas almost mirror each other, but when I say
mirror... I do mean mirror: directions are reversed, and what is on top
for probe mode is on bottom for SMM. :)

In addition, AMD tried reusing ICE mode for SMM, and was sued by Intel
who actually won the lawsuit.  I couldn't find more information about
the lawsuit.

It's probably diverged more and more over time, for example because SMM
is now considered security-sensitive while probe mode isn't.  In
addition, the same DDJ article says that Pentium JTAG probe mode
"doesn't resemble SMM at all, doesn't use a state save map, or even
execute any code of its own", whatever that means.

Paolo

>  And obviously it's any cause of #DB that enters this mode.  The probe can
> also request it right at the exit from the reset state, so that you can 
> debug software (e.g BIOS startup) right from the reset vector.  You don't 
> need working RAM for that.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: Dealing with the NMI mess "Maciej W. Rozycki" <macro@linux-mips.org> - 2015-09-07 07:40 +0200
  Re: Dealing with the NMI mess Ingo Molnar <mingo@kernel.org> - 2015-09-07 09:50 +0200
    Re: Dealing with the NMI mess "Maciej W. Rozycki" <macro@linux-mips.org> - 2015-09-07 10:20 +0200
      Re: Dealing with the NMI mess Paolo Bonzini <pbonzini@redhat.com> - 2015-09-07 12:30 +0200
        Re: Dealing with the NMI mess "Maciej W. Rozycki" <macro@linux-mips.org> - 2015-09-07 19:10 +0200
          Re: Dealing with the NMI mess Andy Lutomirski <luto@amacapital.net> - 2015-09-07 19:30 +0200
            Re: Dealing with the NMI mess "Maciej W. Rozycki" <macro@linux-mips.org> - 2015-09-07 21:40 +0200
              Re: Dealing with the NMI mess Andy Lutomirski <luto@amacapital.net> - 2015-09-08 00:00 +0200
                Re: Dealing with the NMI mess "Maciej W. Rozycki" <macro@linux-mips.org> - 2015-09-08 18:30 +0200

csiph-web