Re: [PATCH] x86: let 32bit use apic_ops too

[Maciej W. Rozycki]

On Sun, 13 Jul 2008, Cyrill Gorcunov wrote:

> Guys, when I was in attempt to unify apic code first thing was -
> renaming apic_write. Here is a patch for this - only ESR and K8
> registers are untouched - may be usefull to apply (actually not
> sure if it will apply without fuzz now). Wonder if this help :)

 Confirmed -- with one exception all the generic write accesses to the
APIC absolutely have to use apic_write_around() because of the lethal
implications of the double-write erratum of some local APIC versions
integrated with Pentium CPUs.

 The exception is the ESR register which cannot use the function because
of: 1. its semantics which gives side-effects on a read, 2. another
erratum, which makes the register lose its contents on a write.  
Therefore the approach is to avoid writes, which are architecturally
required, altogether on Pentium CPUs, which ignore them by their
implementation, and then use straigth apic_write() on all the newer APIC
versions which would lose some information if a read happened before a
write.

 The K8 does not have to use apic_write_around() for the same reasons
x86-64 does not, as neither are hit by the double-write erratum, so all
their processor-specific write accesses may use apic_write() to avoid a
performance hit when used with a kernel with X86_GOOD_APIC cleared.  
Unfortunately, the LOCK# bus access always implied by the XCHG is quite
expensive, but still less intrusive than a sequence involving masking
interrupts locally beforehand and then restoring the IF flag to the
previous state afterwards.  As the APIC is local to the CPU, the grant
should not extend outside to the external bus though.

 And last, but not least, alternatives can be used these days to patch the
expensive XCHG instructions out with cheap MOV ones -- something that was
not available when the workaround was designed some ten years ago.

  Maciej
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/