Re: [patch 05/10] x86/traps: Document do_spurious_interrupt_bug()

Frederic Weisbecker
2020-02-26T17:09:01Z

On Tue, Feb 25, 2020 at 10:36:41PM +0100, Thomas Gleixner wrote:
> Add a comment which explains why this empty handler for a reserved vector
> exists.
>
> Requested-by: Josh Poimboeuf <jpoimboe@redhat.com>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> ---
> arch/x86/kernel/traps.c | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -862,6 +862,25 @@ do_simd_coprocessor_error(struct pt_regs
> dotraplinkage void
> do_spurious_interrupt_bug(struct pt_regs *regs, long error_code)
> {
> + /*
> + * This addresses a Pentium Pro Erratum:
> + *
> + * PROBLEM: If the APIC subsystem is configured in mixed mode with
> + * Virtual Wire mode implemented through the local APIC, an
> + * interrupt vector of 0Fh (Intel reserved encoding) may be
> + * generated by the local APIC (Int 15). This vector may be
> + * generated upon receipt of a spurious interrupt (an interrupt
> + * which is removed before the system receives the INTA sequence)
> + * instead of the programmed 8259 spurious interrupt vector.
> + *
> + * IMPLICATION: The spurious interrupt vector programmed in the
> + * 8259 is normally handled by an operating system's spurious
> + * interrupt handler. However, a vector of 0Fh is unknown to some
> + * operating systems, which would crash if this erratum occurred.
> + *
> + * In theory this could be limited to 32bit, but the handler is not
> + * hurting and who knows which other CPUs suffer from this.
> + */
> }

Nice to have!

Reviewed-by: Frederic Weisbecker <frederic@kernel.org>