From: "Ralf Baechle" <firstname.lastname@example.org>:
> Basically we have two groups of interrupt handlers. Some contain
> workarounds for hardware bugs; the rest are very similar except having
> to handle different hazards. I was already thinking about building the
> actuall exception handlers from a piece of code that inserts the right
> number of (ss)nops etc. as required into the right place, thereby
> producing an optimal handler for every CPU.
I really don't think that's a good idea. That implies that we
could no longer simply inspect the exception handlers in
the source code or disassembled kernel binary file to
analyse them for correctness, and I think it would lead
to unnecessary and hard-to-find bugs. My personal
recommendation would be to keep the model we have
today, wherein handlers are selected at boot time from
some set of candidates built into the kernel binary, with
the slight modification that the templates be loaded into
the init segment, so that the memory consumed can be
reclaimed at run time. That would eliminate the only
argument I can see against having a larger set of
statically-built optimized handlers. The current
selection process is ad-hoc based on CPU ID.
We could easily formalize that a bit, and even
provide a boot command line option to override
the automatic selection with something "safer".