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