> > This patch implements a system that modifies the kernel code at runtime
> > depending on CPU features and SMPness.
> 
> Nice!
> > This patch requires the is_smp() patch I posted earlier and also
> > requires the new CPU selection code and the code that actually uses
> > both.
> > This code already exists, but needs a few adjustments so it may not
> > arrive immediately.
> > 
> > The code is invoked in the following ways:
> >         * Undefined exception handler: this is used to replace
> >           unsupported instructions with supported ones. Used for invlpg
> >           -> flushall, prefetchnta -> prefetch -> nop, *fence -> lock
> >           addl 0, (%esp), movntq -> movq
> >         * Int3 handler: this is used when a 1 byte opcode is desired.
> >           This is controlled by a config option so that debuggers and
> >           kprobe won't break. Used for lock/nop and APIC write
> 
> Why not do *everything* using int3 handler? It should simplify your code.
Because kdb, kgdb and kprobe want to use int3 so it must be used only if
the config option is enabled.

> Hooking on 'unknown instruction' should not be really neccessary if you
> replace all invlpgs (etc) with 0xcc...
It's better: first, if it is supported we have no faults.
Second, in some cases (e.g. movntq) it's not possible without adding
extra padding when using int xx (and int3 can't be used for the reason
above).

> > Unfortunately with this patch executing invalid code will cause the
> > processor to enter an infinite exception loop rather than panic. Fixing
> > this is not trivial for SMP+preempt so it's not done at the moment.
> 
> Using 0xcc for everything should fix that, right?
Not possible. See above.

This could be fixed by checking whether the opcode is not one generated
or recognized by the dynamic fixup code, assuming that nothing else can
change the code.
However, this fails to detect "impossible" cases like cpus that should
understand prefetches but that don't.