On Thu, 3 Apr 2008 23:40:28 +0200
"Vegard Nossum" <vegard.nossum@gmail.com> wrote:

quoted text
> On Thu, Apr 3, 2008 at 11:07 PM, Pekka Paalanen <pq@iki.fi> wrote:
> > ...

quoted text
> We do indeed limit maxcpus to 1 at run-time if the kernel is compiled
> with CONFIG_SMP. kmemcheck is a debugging facility, and as such,
> actual multiprocessor support is not critical for the purpose of
> kmemcheck, in my opinion. Doesn't the same hold for mmiotrace?

Actually, I think kmemcheck should support SMP even more than mmiotrace.
Mmiotrace is just a reverse engineering tool for hardware drivers, but
kmemcheck as a debugging tool could be valuable specifically on SMP,
think about racing CPUs using and initializing memory. Dropping to UP
might hide those problems.

quoted text
> >  One more idea:
> >
> >  D) Emulate the faulting instruction.
> >  In __ioremap(), do the mapping, but steal it for mmiotrace's personal use,
> >  and return a bogus mapping that is identifiable in #pf handler. When
> >  something accesses the bogus mapping, emulate and step over the faulting
> >  instruction using the stolen IO memory mapping. This would get rid of
> >  the debug trap and single stepping, and also remove the need to disarm
> >  the mmio page, which means tracing would work reliably on SMP without
> >  any page table kludges. This would also remove the yet another instruction
> >  decoding code that mmiotrace has.
> >
> >  The catch is the instruction emulation. I see KVM has some emulation code,
> >  but I cannot understand it without a deep study that would take me weeks.
> >  Is that general enough to be used, or could it be generalized?
> >  Mmiotrace, apart from executing the instruction with a modified address,
> >  would need to extract the type of IO memory access, width and the data
> >  read/written. And since it is dealing with IO memory, the emulation
> >  should be very careful to access the hardware exactly like the original
> >  instruction would have.
> 
> I think that would be extremely difficult to do. I am personally
> trying to stay as far away from opcode decoding (and recoding!
> *shudder*) as possible. I do the minimal decoding for operand sizes,
> etc, which I think you do as well in mmiotrace.

To be honest, I don't know how easy or difficult it is. If there was a
general decoding facility, it shouldn't be that hard to use, if someone
else makes the facility for us ;-)
Could all relevant instructions be represented as three-address-code or
in some other simple form?
This seems to require some experimenting with code.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
--
unsubscribe notice
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/