public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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