On Fri, 23 May 2008 16:19:43 +0200
Yes, thanks. My opinion is that mmiotrace can live well enough with
runtime-disabling extra cpus when tracing starts. Multi-cpu effects to
hardware access are not really in the focus but seeing the access in
the first place. I'd rather wait to see if the per-cpu page table
feature starts to evolve.
I quickly read through your code and tried to come up with race
scenarios, but failed. Ok, one question which might be far fetched:
is there a window for things to go wrong, when one cpu has faulted
and is submitting the NMI, but another cpu is managing cpus' online
state at the time? Is there a place in the cpu state management
that might fault at a point where cpu maps are inconsistent?
I doubt, but I don't know. And of course this could be a problem
only when something is bringing cpus on- or offline.
Btw. isn't reserving a cpumask_t variable from the stack discouraged
because it might have to deal with thousands of cpus and consume a
lot of memory?
--
Pekka Paalanen
http://www.iki.fi/pq/
--
