On Wed, May 24, 2017 at 11:36 PM, Paul Clarke <p...@us.ibm.com> wrote: > On 05/23/2017 06:45 PM, Matt Brown wrote: >> The xor_vmx.c file is used for the RAID5 xor operations. In these functions >> altivec is enabled to run the operation and then disabled. However due to >> compiler instruction reordering, altivec instructions are being run before >> enable_altivec() and after disable_altivec(). > > If altivec instructions can be reordered after disable_altivec(), then > disable_altivec() is broken, I'd think. > > Could it be because the isync in mtmsr_isync() is after the mtmsr? > > disable_kernel_altivec > - msr_check_and_clear > - __msr_check_and_clear > - mtmsr_isync
So it turns out the enable / disable functions don't actually enable or disable the use of vector instructions. If we have marked the file to be compiled with altivec the compiler has free reign to reorder the vector instructions wherever it likes. Including reordering it before or after the enable/disable_altivec commands. The enable_kernel_altivec and disable_kernel_altivec functions are mainly there to empty and restore the vector registers which could have been used in user-space. So those functions work as intended, although not particularly intuitive. Splitting the files and only compiling the xor_vmx.c file with altivec will guarantee that there are no vector instructions in the xor_vmx_glue.c file, and that no vector instructions are outside of the enable/disable block. - Matt Brown > > PC >
