From: Borislav Petkov <borislav.petkov@amd.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: akpm@linux-foundation.org, greg@kroah.com, mingo@elte.hu,
norsk5@yahoo.com, tglx@linutronix.de, mchehab@redhat.com,
aris@redhat.com, edt@aei.ca, linux-kernel@vger.kernel.org,
Andreas Herrmann <andreas.herrmann3@amd.com>
Subject: Re: [PATCH 01/22] x86: add methods for writing of an MSR on several CPUs
Date: Wed, 20 May 2009 16:49:05 +0200 [thread overview]
Message-ID: <20090520144905.GA27991@aftab> (raw)
In-Reply-To: <4A1392A9.9010609@zytor.com>
Hi,
On Tue, May 19, 2009 at 10:18:33PM -0700, H. Peter Anvin wrote:
> Borislav Petkov wrote:
> > +
> > +/* rdmsr on a bunch of CPUs
> > + *
> > + * @mask: which CPUs
> > + * @msr_no: which MSR
> > + * @msrs: array of MSR values
> > + *
> > + * Returns:
> > + * 0 - success
> > + * <0 - read failed on at least one CPU (latter in the mask)
> > + */
> > +int rdmsr_on_cpus(const cpumask_t *mask, u32 msr_no, struct msr *msrs)
> > +{
> > + struct msr *reg;
> > + int cpu, tmp, err = 0;
> > + int off = cpumask_first(mask);
> > +
> > + for_each_cpu(cpu, mask) {
> > + reg = &msrs[cpu - off];
> > +
> > + tmp = rdmsr_on_cpu(cpu, msr_no, ®->l, ®->h);
> > + if (tmp)
> > + err = tmp;
> > + }
> > + return err;
> > +}
> > +EXPORT_SYMBOL(rdmsr_on_cpus);
> > +
> > +/*
> > + * wrmsr of a bunch of CPUs
> > + *
> > + * @mask: which CPUs
> > + * @msr_no: which MSR
> > + * @msrs: array of MSR values
> > + *
> > + * Returns:
> > + * 0 - success
> > + * <0 - write failed on at least one CPU (latter in the mask)
> > + */
> > +int wrmsr_on_cpus(const cpumask_t *mask, u32 msr_no, struct msr *msrs)
> > +{
> > + struct msr reg;
> > + int cpu, tmp, err = 0;
> > + int off = cpumask_first(mask);
> > +
> > + for_each_cpu(cpu, mask) {
> > + reg = msrs[cpu - off];
> > +
> > + tmp = wrmsr_on_cpu(cpu, msr_no, reg.l, reg.h);
> > + if (tmp)
> > + err = tmp;
> > + }
> > + return err;
> > +}
> > +EXPORT_SYMBOL(wrmsr_on_cpus);
> > +
>
> Okay, now I'm *really* confused.
>
> I thought the whole point of these functions was to allow these MSR
> references to take place in parallel, as opposed to doing outcalls to
> each CPU in order... but that's exactly what these functions do.
>
> So what was the point of them again?
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?
Opinions? Flames?
--
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
next prev parent reply other threads:[~2009-05-20 14:49 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-15 12:22 [RFC PATCH 00/21 v4] amd64_edac: EDAC module for AMD64 Borislav Petkov
2009-05-15 12:22 ` [PATCH 01/22] x86: add methods for writing of an MSR on several CPUs Borislav Petkov
2009-05-19 17:24 ` Borislav Petkov
2009-05-20 5:18 ` H. Peter Anvin
2009-05-20 14:49 ` Borislav Petkov [this message]
2009-05-20 21:39 ` H. Peter Anvin
2009-05-21 14:08 ` Borislav Petkov
2009-05-21 14:21 ` H. Peter Anvin
2009-05-21 16:26 ` Borislav Petkov
2009-05-21 17:38 ` H. Peter Anvin
2009-05-22 14:39 ` Borislav Petkov
2009-05-22 16:47 ` H. Peter Anvin
2009-05-25 11:01 ` Borislav Petkov
2009-05-25 11:02 ` Borislav Petkov
2009-05-25 11:03 ` Borislav Petkov
2009-05-15 12:22 ` [PATCH 02/22] edac: fold __func__ into edac_debug_printk Borislav Petkov
2009-05-15 13:25 ` Mauro Carvalho Chehab
2009-05-15 12:22 ` [PATCH 03/22] amd64_edac: add driver header Borislav Petkov
2009-05-15 12:22 ` [PATCH 04/22] amd64_edac: add debugging/testing code Borislav Petkov
2009-05-15 12:22 ` [PATCH 05/22] amd64_edac: add DRAM error injection logic using sysfs Borislav Petkov
2009-05-15 12:22 ` [PATCH 06/22] amd64_edac: add MCA error types Borislav Petkov
2009-05-15 12:22 ` [PATCH 07/22] amd64_edac: add memory scrubber interface Borislav Petkov
2009-05-15 12:22 ` [PATCH 08/22] amd64_edac: add sys addr to memory controller mapping helpers Borislav Petkov
2009-05-15 12:22 ` [PATCH 09/22] amd64_edac: add functionality to compute the DRAM hole Borislav Petkov
2009-05-15 12:22 ` [PATCH 10/22] amd64_edac: add DRAM address type conversion facilities Borislav Petkov
2009-05-15 12:22 ` [PATCH 11/22] amd64_edac: add helper to dump relevant registers Borislav Petkov
2009-05-15 12:22 ` [PATCH 12/22] amd64_edac: assign DRAM chip select base and mask in a family-specific way Borislav Petkov
2009-05-15 12:22 ` [PATCH 13/22] amd64_edac: add k8-specific methods Borislav Petkov
2009-05-15 12:22 ` [PATCH 14/22] amd64_edac: add F10h-and-later methods-p1 Borislav Petkov
2009-05-15 12:22 ` [PATCH 15/22] amd64_edac: add F10h-and-later methods-p2 Borislav Petkov
2009-05-15 12:22 ` [PATCH 16/22] amd64_edac: add F10h-and-later methods-p3 Borislav Petkov
2009-05-15 12:22 ` [PATCH 17/22] amd64_edac: add per-family descriptors Borislav Petkov
2009-05-15 12:22 ` [PATCH 18/22] amd64_edac: add ECC chipkill syndrome mapping table Borislav Petkov
2009-05-15 12:22 ` [PATCH 19/22] amd64_edac: add error decoding logic Borislav Petkov
2009-05-15 12:22 ` [PATCH 20/22] amd64_edac: add EDAC core-related initializers Borislav Petkov
2009-05-15 12:22 ` [PATCH 21/22] amd64_edac: add ECC reporting initializers Borislav Petkov
2009-05-15 12:22 ` [PATCH 22/22] amd64_edac: add module registration routines Borislav Petkov
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=20090520144905.GA27991@aftab \
--to=borislav.petkov@amd.com \
--cc=akpm@linux-foundation.org \
--cc=andreas.herrmann3@amd.com \
--cc=aris@redhat.com \
--cc=edt@aei.ca \
--cc=greg@kroah.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab@redhat.com \
--cc=mingo@elte.hu \
--cc=norsk5@yahoo.com \
--cc=tglx@linutronix.de \
/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