From: Borislav Petkov <bp@amd64.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Borislav Petkov <bp@amd64.org>, Daniel Drake <dsd@laptop.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Geode LX boot fails after x86 microcode revision change
Date: Tue, 22 Nov 2011 14:00:48 +0100 [thread overview]
Message-ID: <20111122130048.GB11020@aftab> (raw)
In-Reply-To: <4EB9AAF1.4040103@zytor.com>
On Tue, Nov 08, 2011 at 02:19:29PM -0800, H. Peter Anvin wrote:
> > If so, then a family check is unavoidable.
>
> Either that, or make changes so that we can handle exceptions earlier.
> That would be useful for other reasons.
Well, I did some experimenting with this by forcing a guest to #GP on a
rdmsr in kvm. What I got was the early_idt_handler's panic message:
"PANIC: early exception %02lx rip %lx:%lx error %lx cr2 %lx\n"
because of the following boot code flow:
x86_64_start_kernel
|-> ... set_intr_gate /* register early_idt_handler */
|-> x86_64_start_reservations
|-> start_kernel
|-> setup_arch
|-> early_cpu_init() /*
* this is where we need the extable for
* rdmsr_safe
*/
...
|-> trap_init() /* switch to default #GP handler */
and do_general_protection does the actual exception fixup. Now, the
whole setup_arch() is running with the initial traps and only after we
finish it and a bunch of other stuff, we switch to the #GP handler in
trap_init().
>From where I stand, maybe I could try to teach the early_idt_handler in
head_64.S to do fixup_exception() ?
Also, we might need the patches which sort extable at build time too,
which are floating around lkml currently.
Hmm...
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
next prev parent reply other threads:[~2011-11-22 13:00 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-08 19:59 Geode LX boot fails after x86 microcode revision change Daniel Drake
2011-11-08 20:31 ` Borislav Petkov
2011-11-08 22:01 ` H. Peter Anvin
2011-11-08 22:13 ` Petkov, Borislav
2011-11-08 22:17 ` Daniel Drake
2011-11-08 22:37 ` Borislav Petkov
2011-11-08 22:59 ` Daniel Drake
2011-11-09 17:34 ` Borislav Petkov
2011-11-10 13:05 ` Srivatsa S. Bhat
2011-11-10 13:28 ` Borislav Petkov
2011-11-10 13:37 ` Srivatsa S. Bhat
2011-11-10 13:34 ` Srivatsa S. Bhat
2011-11-11 18:40 ` Daniel Drake
2011-11-12 13:50 ` Borislav Petkov
2011-11-08 22:19 ` H. Peter Anvin
2011-11-08 22:40 ` Borislav Petkov
2011-11-22 13:00 ` Borislav Petkov [this message]
2011-11-22 18:54 ` H. Peter Anvin
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=20111122130048.GB11020@aftab \
--to=bp@amd64.org \
--cc=dsd@laptop.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
/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