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 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.