lkml.org 
[lkml]   [2008]   [Jul]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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 -


    \
     
     \ /
      Last update: 2008-07-14 18:51    [W:3.729 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site