Messages in this thread | | | Date | Mon, 14 Jul 2008 20:48:09 +0400 | From | Cyrill Gorcunov <> | Subject | Re: [PATCH] x86: let 32bit use apic_ops too |
| |
[Maciej W. Rozycki - Mon, Jul 14, 2008 at 12:46:11AM +0100] | 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 |
Maciej, but if we eliminate LOCK# by using simple MOV there will not be guarantee for atomicity. Am I wrong?
- Cyrill -
| |