[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090521140800.GA3462@aftab>
Date: Thu, 21 May 2009 16:08:00 +0200
From: Borislav Petkov <borislav.petkov@....com>
To: "H. Peter Anvin" <hpa@...or.com>
CC: akpm@...ux-foundation.org, greg@...ah.com, mingo@...e.hu,
norsk5@...oo.com, tglx@...utronix.de, mchehab@...hat.com,
aris@...hat.com, edt@....ca, linux-kernel@...r.kernel.org,
Andreas Herrmann <andreas.herrmann3@....com>
Subject: Re: [PATCH 01/22] x86: add methods for writing of an MSR on
several CPUs
On Wed, May 20, 2009 at 02:39:29PM -0700, H. Peter Anvin wrote:
> Borislav Petkov wrote:
> >
> > We currently need them for enabling the NB error reporting bank over
> > MCG_CTL on each core on the node. The question is whether we really need
> > the concurrency when accessing an MSR on several cores. With MCG_CTL,
> > BKDG says "It is expected that this register is programmed to the same
> > value in all nodes," but nothing concerning concurrency.
> >
> > But you're right, if this interface is supposed to be generic enough,
> > it is probably wise to access an MSR concurrently. I could imagine
> > an obscure case where this is required. However, is sending IPIs
> > (smp_call_function_many) guaranteeing the needed concurrency? Or, should
> > it be more like how the mtrr code jumps through hoops (set_mtrr())
> > in order to ensure that _ALL_ registers have been written _before_
> > continuing?
> >
>
> smp_call_function_many() does allow concurrent execution.
Well, IMHO, not an absolutely concurrent execution since you can't
control at what moment in time the IPIs will be executed on each core,
IOW, the respective call function IPIs will generally not coincide on
each core at a given moment in time. This is especially true if you're
sending IPIs to cores across nodes.
And there's hypothetically a small window where you might get an
inconsistent MSR content across cores. It's a whole another question
whether this is going to be relevant.
> Looping over a list with smp_call_function_one() -- which you
> currently have -- is serializing, at which point we might just push
> the loop into the caller rather than worrying about a new interface.
So, the actual question is do we need that done in msr.c? If there are
no potential users, I could easily do the whole thing in the driver and
do not touch x86 code.
Hmm?
--
Regards/Gruss,
Boris.
Operating | Advanced Micro Devices GmbH
System | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany
Research | Geschäftsführer: Thomas M. McCoy, Giuliano Meroni
Center | Sitz: Dornach, Gemeinde Aschheim, Landkreis München
(OSRC) | Registergericht München, HRB Nr. 43632
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists