Messages in this thread | | | Date | Thu, 6 May 2004 13:23:42 +0100 (BST) | From | Tigran Aivazian <> | Subject | Re: 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/
| |