Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1220042
| 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 |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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