Re: microcode_ctl question (fwd)

Re: microcode_ctl question (fwd)

[Tigran Aivazian]

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

Re: microcode_ctl question (fwd)

[Dave Jones]

On Thu, May 06, 2004 at 01:23:42PM +0100, Tigran Aivazian wrote:

Hi Tigran,

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

I fixed up microcode.c to use on_each_cpu() last year sometime, which
I thought should fix things up wrt preemption. Can you point to the
bits you think are still problematic ?

		Dave

Re: microcode_ctl question (fwd)

[Tigran Aivazian]

On Thu, 6 May 2004, Dave Jones wrote:
> I fixed up microcode.c to use on_each_cpu() last year sometime, which
> I thought should fix things up wrt preemption. Can you point to the
> bits you think are still problematic ?

Ok, just looked at the definition of on_each_cpu() and I can see that it 
is disabling/enabling preemption explicitly, so there are no problems.

I assumed that on_each_cpu() is just a new 2.6 name for the old 
smp_call_function(), that is why I thought there may be problems with 
preemption. Thanks for clarifying this.

Kind regards
Tigran