[RFC PATCH] powerpc/pseries/svm: capture instruction faulting on MMIO access, in sprg0 register
Laurent Dufour
ldufour at linux.ibm.com
Tue Jul 21 17:22:55 AEST 2020
Le 20/07/2020 à 22:24, Segher Boessenkool a écrit :
> On Mon, Jul 20, 2020 at 03:10:41PM -0500, Segher Boessenkool wrote:
>> On Mon, Jul 20, 2020 at 11:39:56AM +0200, Laurent Dufour wrote:
>>> Le 16/07/2020 à 10:32, Ram Pai a écrit :
>>>> + if (is_secure_guest()) { \
>>>> + __asm__ __volatile__("mfsprg0 %3;" \
>>>> + "lnia %2;" \
>>>> + "ld %2,12(%2);" \
>>>> + "mtsprg0 %2;" \
>>>> + "sync;" \
>>>> + #insn" %0,%y1;" \
>>>> + "twi 0,%0,0;" \
>>>> + "isync;" \
>>>> + "mtsprg0 %3" \
>>>> + : "=r" (ret) \
>>>> + : "Z" (*addr), "r" (0), "r" (0) \
>>>
>>> I'm wondering if SPRG0 is restored to its original value.
>>> You're using the same register (r0) for parameters 2 and 3, so when doing
>>> lnia %2, you're overwriting the SPRG0 value you saved in r0 just earlier.
>>
>> It is putting the value 0 in the registers the compiler chooses for
>> operands 2 and 3. But operand 3 is written, while the asm says it is an
>> input. It needs an earlyclobber as well.
Oh nice, I was not aware that compiler may choose registers this way.
Good to know, thanks for the explanation.
>>> It may be clearer to use explicit registers for %2 and %3 and to mark them
>>> as modified for the compiler.
>>
>> That is not a good idea, imnsho.
>
> (The explicit register number part, I mean; operand 2 should be an
> output as well, yes.)
Sure if the compiler can choose the registers that's far better.
Cheers,
Laurent.
More information about the Linuxppc-dev
mailing list