• Anshuman Khandual's avatar
    powerpc: Fix handling of DSCR related facility unavailable exception · c952c1c4
    Anshuman Khandual authored
    Currently DSCR (Data Stream Control Register) can be accessed with
    mfspr or mtspr instructions inside a thread via two different SPR
    numbers. One being the user accessible problem state SPR number 0x03
    and the other being the privilege state SPR number 0x11. All access
    through the privilege state SPR number get emulated through illegal
    instruction exception. Any access through the problem state SPR number
    raises one facility unavailable exception which sets the thread based
    dscr_inherit bit and enables DSCR facility through FSCR register thus
    allowing direct access to DSCR without going through this exception in
    the future. We set the thread.dscr_inherit bit whether the access was
    with mfspr or mtspr instruction which is neither correct nor does it
    match the behaviour through the instruction emulation code path driven
    from privilege state SPR number. User currently observes two different
    kind of behaviour when accessing the DSCR through these two SPR numbers.
    This problem can be observed through these two test cases by replacing
    the privilege state SPR number with the problem state SPR number.
    
    	(1) http://ozlabs.org/~anton/junkcode/dscr_default_test.c
    	(2) http://ozlabs.org/~anton/junkcode/dscr_explicit_test.c
    
    This patch fixes the problem by making sure that the behaviour visible
    to the user remains the same irrespective of which SPR number is being
    used. Inside facility unavailable exception, we check whether it was
    cuased by a mfspr or a mtspr isntrucction. In case of mfspr instruction,
    just emulate the instruction. In case of mtspr instruction, set the
    thread based dscr_inherit bit and also enable the facility through FSCR.
    All user SPR based mfspr instruction will be emulated till one user SPR
    based mtspr has been executed.
    Signed-off-by: default avatarAnshuman Khandual <khandual@linux.vnet.ibm.com>
    Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
    c952c1c4
traps.c 50.1 KB