Re: [PATCH] Ensure PSR.ac is cleared for early userspace

[Rick Jones <rick.jones2@hp.com>]

Tony Luck wrote:
> On Fri, Nov 14, 2008 at 7:26 PM, David Mosberger-Tang
> <dmosberger@gmail.com> wrote:
> 
>> In any case, as I remember, the idea was that the kernel would always
>> execute with PSR.AC=1 to avoid silent performance bugs and just since
>> the kernel should be alignment-clean, anyhow.  The fys-code doesn't
>> turn on PSR.AC, but I believe the heavy-weight syscall path does.  I
>> don't know why head.S turns off PSR.AC.  Seems like a bug to me.
> 
> 
> Running base code and interrupt/trap code with different settings of PSR.ac
> does sound like a bug ... but the question of what we should set it to deserves
> a little more thought.
> 
> Perhaps the best option would be for test & development kernels to set
> PSR.ac=1 to aid in tracking down any alignment problems in the code.
> But production kernels should set PSR.ac=0 so that they don't take the
> cost of a trap on unaligned access that the specific model of processor
> can handle anyway.  If this is the right path, then it should become a
> CONFIG option.

If the hypothesis is that test and development kernels would catch the 
alignment problems, then there shouldn't be any in the production 
kernels right?  However, if there _are_ any out there in production 
don't we want them to become visible?  Even on processors which can 
handle them it is still better to not have the unaligned acesses in the 
first place right?

rick jones