On 05/24/2017 11:56 PM, Matt Brown wrote: > 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.
Thanks for the explanation! That makes sense. PC
