Re: [PATCH 00/58] Add support for Enhanced Virtual Addressing

[Markos Chandras <Markos.Chandras@imgtec.com>]

Hi David,

I have some comments

On 01/29/2014 06:37 PM, David Daney wrote:
> This whole thing seems very messy.  I see a couple of problems:
>
> 1) There are if(CONFIG_EVA) ... else ... endif  all over the place.  It
> is very ugly.
>
> 2) You cannot have a signel kernel with both EVA and non-EVA support.


Unfortunately, I don't think using eva=1 or whatever in the kernel 
command line would work. First of all, there is board specific init code 
long before the command line is available. See patch #51. At that point, 
the kernel command line is not 'exposed' yet so there is no way to tell 
if you are booting in EVA or non-EVA mode.

>
> Have you considered just tagging all the instructions that touch the
> user address space, and patching them at system boot with their EVA
> equivalents if EVA support is desired?

I don't think this is possible (or maybe i don't understand your 
proposal). Consider for example the copy_user function in memcpy.S. This 
function does copy_{to,from,in} user/kernel depending on the supplied 
virtual address. There is no way to tell in advance if a 'lb' 
instruction will load from kernel or user space. This is only possible 
during runtime by examining the get_fs() == get_ds() status. Therefore, 
it's necessary to have 4 variants of this functions replacing only the 
'store' or 'load' instructions that you really need to. For example

- load from user, store to kernel
- load from kernel, store to user
- load from user, store to user
- load from kernel, store to kernel

As you can see, static replacement of the instructions with the EVA ones 
during boot will not work as expected.

This is the reason I converted these functions to macros, so all the 
variants will be a simple 3 line assembler code that only replaces the 
instructions you are really interested in.

-- 
markos