From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: Zachary Amsden <zach@vmware.com>
Cc: Andi Kleen <andi@firstfloor.org>,
jbeulich@novell.com, "S. P. Prasanna" <prasanna@in.ibm.com>,
linux-kernel@vger.kernel.org, patches@x86-64.org,
Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: new text patching for review
Date: Fri, 20 Jul 2007 11:17:49 -0400 [thread overview]
Message-ID: <20070720151748.GA511@Krystal> (raw)
In-Reply-To: <46A00CC2.6010407@vmware.com>
* Zachary Amsden (zach@vmware.com) wrote:
> Mathieu Desnoyers wrote:
> >Yes, kprobes is case 1: atomic update. And we don't even have to bother
> >about Intel's erratum. This one is ok. That's mainly the
> >alternatives/paravirt code I worry about.
> >
>
> Paravirt and alternatives should all be ok because they are done before
> SMP bringup and with NMIs disabled. NMI watchdog is not setup until
> smp_prepare_cpus/check_nmi_watchdog, which happens way later, not during
> parse_args/setup_nmi_watchdog, which just decides which type of watchdog
> to setup.
>
I'm not so sure about this. You are right in that it has nothing to do
with parse_args, but I just went in detail through the source, and the
order seems to be:
1 - NMI is activated
2 - MCE is activated
3 - alternatives are applied
In detail:
start_kernel()
...
include/asm-i386/smp.h:smp_prepare_boot_cpu()
smp_ops.smp_prepare_boot_cpu()
arch/i386/kernel/smpboot.c:native_smp_prepare_boot_cpu()
arch/i386/kernel/smpboot.c:native_smp_prepare_cpus()
arch/i386/kernel/smpboot.c:smp_boot_cpus()
arch/i386/kernel/apic.c:setup_local_APIC()
arch/i386/kernel/nmi.c:setup_apic_nmi_watchdog()
arch/i386/kernel/cpu/perfctr-watchdog.c:lapic_watchdog_init()
wd_ops->setup() (e.g. setup_intel_arch_watchdog)
...
arch/i386/kernel/cpu/bugs.c:check_bugs()
arch/i386/kernel/cpu/common.c:identify_boot_cpu()
identify_cpu()
arch/i386/kernel/cpu/mcheck/mce.c:mcheck_init()
arch/i386/kernel/cpu/mcheck/p4.c:intel_p4_mcheck_init()
...
arch/i386/kernel/alternative_instructions()
...
Therefore, applying alternatives instructions seems to be done after NMI
and MCE init at boot time, or am I misunderstanding something ?
> I originally considered the NMI problem for paravirt-ops patching done
> during module load, and found that I would need to modify
> stop_machine_run to have an architecture specific callout to mask and
> unmask NMIs. I didn't imagine that would be very popular, and VMI was
> the only paravirt-ops that were considering module load time patching,
> so I flushed it.
>
> You get some other nasty issues as well with run-time switching, like
> missing early init calls (in particular, we would have to go to some
> heroics to retake the land surrounding the APIC local timer interrupt).
>
> Zach
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
next prev parent reply other threads:[~2007-07-20 15:18 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-19 9:05 new text patching for review Andi Kleen
2007-07-19 13:38 ` Mathieu Desnoyers
2007-07-19 13:46 ` Andi Kleen
2007-07-19 17:35 ` Mathieu Desnoyers
2007-07-19 21:14 ` Andi Kleen
2007-07-19 20:30 ` Jeremy Fitzhardinge
2007-07-19 20:46 ` [patches] " Andi Kleen
2007-07-19 20:51 ` Jeremy Fitzhardinge
2007-07-19 21:06 ` Andi Kleen
2007-07-19 21:08 ` Jeremy Fitzhardinge
2007-07-19 23:53 ` Mathieu Desnoyers
2007-08-20 0:55 ` Non atomic unaligned writes Mathieu Desnoyers
2007-08-20 5:03 ` Arjan van de Ven
2007-08-20 10:23 ` Andi Kleen
2007-07-19 23:51 ` new text patching for review Mathieu Desnoyers
2007-07-19 23:49 ` Mathieu Desnoyers
2007-07-20 1:15 ` Zachary Amsden
2007-07-20 7:37 ` Andi Kleen
2007-07-20 15:17 ` Mathieu Desnoyers [this message]
2007-07-21 6:19 ` Andi Kleen
2007-07-20 8:28 ` Andi Kleen
2007-07-20 14:36 ` Mathieu Desnoyers
2007-07-20 0:37 ` Zachary Amsden
2007-07-20 8:23 ` Andi Kleen
2007-08-10 19:00 ` Mathieu Desnoyers
-- strict thread matches above, loose matches on Subject: below --
2007-07-19 12:25 Jan Beulich
2007-07-19 12:41 ` Andi Kleen
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=20070720151748.GA511@Krystal \
--to=mathieu.desnoyers@polymtl.ca \
--cc=andi@firstfloor.org \
--cc=jbeulich@novell.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=patches@x86-64.org \
--cc=prasanna@in.ibm.com \
--cc=zach@vmware.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox