lkml.org 
[lkml]   [2004]   [May]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: microcode_ctl question (fwd)
Hello,

(cc'd linux-kernel so they can also participate in the discussion)

The microcode driver could be enhanced to support the operation which Kim
is asking for, i.e. to query for the current revision (and possibly other
flags). But we should carefully design the API, namely to take care
of multiple CPUs potentially having multiple revisions of microcode. So,
the user application should first interrogate the number of CPUs
present, by some other means (e.g. reading /proc/cpuinfo or calling
sysconf(_NPROCESSORS_ONLN), which is the same thing btw) and then pass
to the ioctl the address of a data structure like this:

struct microcode_query {
unsigned int sig; /* signature */
unsigned int pf; /* processor flags */
unsigned int rev; /* revision */
} microcode_query[]; /* as many elements as the number of cpus present */

then the driver would do an IPI with collect_cpu_info() as a function
which would fill in all the data and the rest of the ioctl code would just
copy it back to userspace. The only problem here is for the application to
not get confused about the ordering of CPUs.

The driver would order them in the "natural", i.e. smp_processor_id()
order and so that should be the order expected by the applications (maybe
this should be documented somewhere after such ioctl is implemented).

And after all this is done, microcode_ctl is the natural place to call the
ioctl (as a separate command line option).

Btw, I have just noticed what may be a bug wrt not being aware of kernel
preemption, i.e. we cache the CPU id in a local variable and later use it,
but then there seems to be no protection against kernel preemption (i.e.
we hold no spinlocks, only a semaphore) at that point, so the original CPU
id may not be quite the same as the CPU id for which the data was
collected. I should fix this if it is a problem. The question to
linux-kernel guys is to confirm that this is indeed a bug, i.e. to clarify
under which condition the kernel preemption can and cannot occur.

In particular can such preemption occur while executing a function called
via IPI mechanism?

Kind regards
Tigran

> ---------- Forwarded message ----------
> Date: Wed, 5 May 2004 20:17:06 +0100 (BST)
> From: Simon Trimmer <simon@urbanmyth.org>
> To: "JENSEN,KIM (HP-FtCollins,ex1)" <kim.jensen2@hp.com>
> Subject: Re: microcode_ctl question
>
> Hi Kim,
> Not off the top of my head; Tigran?
>
> The driver used to print it out as it seeks to load the new microcode, I
> guess you could attempt to reload it (it'll cope with the revisions being the
> same and it'll print out the version in the detail).
>
> -Simon
>
> On Wed, 5 May 2004, JENSEN,KIM (HP-FtCollins,ex1) wrote:
> > Simon,
> >
> > Do you know of any linux tools that allow one to query the version of ia32
> > intel microcode that has been loaded?
> >
> > Thanks!
> > Kim Jensen
> >
> > Linux Workstations R&D
> > Hewlett Packard


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:02    [W:0.304 / U:0.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site