linux-user: Use the 5KEf processor for 64-bit emulation

Replace the 20Kc original MIPS64 ISA processor used for 64-bit user
emulation with the 5KEf processor that implements the MIPS64r2 ISA,
complementing the choice of the 24Kf processor for 32-bit emulation.

Signed-off-by: Maciej W. Rozycki <macro@codesourcery.com>
---
Hi,

 For user emulation mode I think we want to default to the highest ISA 
level supported, for maximum user flexibility.  Currently the MIPS64r2 
ISA is the highest 64-bit ISA we have a real processor support for so 
use it and the 5KEf which is the processor we have that implements it.  
Later, as newer processors are added, we can bump it further up.

 I think we should consider picking something for microMIPS support too 
sometime, perhaps based on ELF file flags, however the thing is with 
that we have no FPU processor to choose.  So let's skip it for now.

 I have tested it lightly by running the GCC test suite for the 
mips-linux-gnu target and the n64 ABI (`-EB -mabi=64' multilib), using 
MIPS64r2 code.

 Please apply.

  Maciej

qemu-mips-user-5kef.diff

On 20 November 2014 16:00, Maciej W. Rozycki <macro@codesourcery.com> wrote:
> Replace the 20Kc original MIPS64 ISA processor used for 64-bit user
> emulation with the 5KEf processor that implements the MIPS64r2 ISA,
> complementing the choice of the 24Kf processor for 32-bit emulation.
>
> Signed-off-by: Maciej W. Rozycki <macro@codesourcery.com>
> ---
> Hi,
>
>  For user emulation mode I think we want to default to the highest ISA
> level supported, for maximum user flexibility.  Currently the MIPS64r2
> ISA is the highest 64-bit ISA we have a real processor support for so
> use it and the 5KEf which is the processor we have that implements it.
> Later, as newer processors are added, we can bump it further up.

Is it feasible to define an "any" CPU for linux-user which
basically enables all known ISA features? This is what we
do on ARM and some other target CPU families. If some CPU
features conflict with each other (so you can't validly
have a CPU with all of them) that might make it awkward, though.

-- PMM

On Thu, 20 Nov 2014, Peter Maydell wrote:

> >  For user emulation mode I think we want to default to the highest ISA
> > level supported, for maximum user flexibility.  Currently the MIPS64r2
> > ISA is the highest 64-bit ISA we have a real processor support for so
> > use it and the 5KEf which is the processor we have that implements it.
> > Later, as newer processors are added, we can bump it further up.
> 
> Is it feasible to define an "any" CPU for linux-user which
> basically enables all known ISA features? This is what we
> do on ARM and some other target CPU families. If some CPU
> features conflict with each other (so you can't validly
> have a CPU with all of them) that might make it awkward, though.

 It's not possible, the MIPS16 and microMIPS instruction sets are 
mutually exclusive as the same resource (the ISA bit or the LSB of the 
PC) is used to switch to either mode from the standard MIPS mode, 
depending on what a given processor implements.

 Besides it is worthwhile to have a processor that implements the 
microMIPS or the standard MIPS instruction set only, to trap unwanted 
mode switches in software that is supposed to use one of these 
instruction sets only (there is no such issue with the MIPS16 
instruction set as it it not fully self-contained and the presence of 
the standard MIPS instruction set is also required).

 Additionally MIPSr6 is incompatible with any earlier ISA in the 
standard MIPS mode.

 The rest can probably be arranged although there are grey areas, 
specifically not all optional instruction sets have their opcodes 
defined in the microMIPS instruction set.  But for the user emulation 
mode that should probably be OK as long the artificial processor is not 
available for the system emulation mode.

 In the system emulation mode such a processor could lead software to 
confusion, for example the Linux kernel examines processor configuration 
bits and configures itself accordingly.  That works just fine across all 
the optional features in the standard MIPS mode, but a microMIPS kernel 
will not have access to the relevant maintenance instructions that have 
not been defined in the microMIPS instruction set.  An example is the 
SmartMIPS extension whose ACX register has to be maintained in context 
switches and the access to which requires instructions that have not 
been defined in the microMIPS instruction set.  So most likely there's a 
stub somewhere there that makes it panic instead.

 But in any case we'd need at least 3 processors anyway: MIPSr5 with the 
MIPS16 extension, MIPSr5 with the microMIPS extension and MIPSr6.

 Please note that as I suggested the right emulation could be chosen 
automagically based on ELF file header flags.  In fact I have a patch 
outstanding already down the queue that does some processor 
reconfiguration based on that, just like the Linux kernel would do.  
That approach could be further extended up to selecting among processors 
available, so e.g. a program that contains some microMIPS code would 
pick up a microMIPS-enabled processor and one including MIPS16 code 
would pick up one with the MIPS16 extension instead.

 Thanks for your input though, the idea makes sense overall where 
possible.

  Maciej

On 20 November 2014 17:21, Maciej W. Rozycki <macro@codesourcery.com> wrote:
>  It's not possible, the MIPS16 and microMIPS instruction sets are
> mutually exclusive as the same resource (the ISA bit or the LSB of the
> PC) is used to switch to either mode from the standard MIPS mode,
> depending on what a given processor implements.

Pity.

>  Besides it is worthwhile to have a processor that implements the
> microMIPS or the standard MIPS instruction set only, to trap unwanted
> mode switches in software that is supposed to use one of these
> instruction sets only (there is no such issue with the MIPS16
> instruction set as it it not fully self-contained and the presence of
> the standard MIPS instruction set is also required).

Indeed; for ARM "any" is an addition to the usual set of
CPU options, not a replacement for them.

>  The rest can probably be arranged although there are grey areas,
> specifically not all optional instruction sets have their opcodes
> defined in the microMIPS instruction set.  But for the user emulation
> mode that should probably be OK as long the artificial processor is not
> available for the system emulation mode.

Yes; for ARM we don't define the "any" CPU in system mode for
pretty much this reason.

>  Please note that as I suggested the right emulation could be chosen
> automagically based on ELF file header flags.  In fact I have a patch
> outstanding already down the queue that does some processor
> reconfiguration based on that, just like the Linux kernel would do.
> That approach could be further extended up to selecting among processors
> available, so e.g. a program that contains some microMIPS code would
> pick up a microMIPS-enabled processor and one including MIPS16 code
> would pick up one with the MIPS16 extension instead.

That would probably be a useful default. My views here are really
based on two things:
 * the binfmt-misc registration just starts QEMU with no -cpu options,
   so it's helpful if the default can run any binary that matches the
   ELF magic specification
 * the ifdef ladder in linux-user/main.c is kind of ugly :-)

thanks
-- PMM

On 20/11/2014 16:00, Maciej W. Rozycki wrote:
> Replace the 20Kc original MIPS64 ISA processor used for 64-bit user
> emulation with the 5KEf processor that implements the MIPS64r2 ISA,
> complementing the choice of the 24Kf processor for 32-bit emulation.
> 
> Signed-off-by: Maciej W. Rozycki <macro@codesourcery.com>
> ---
> Hi,
> 
>  For user emulation mode I think we want to default to the highest ISA 
> level supported, for maximum user flexibility.  Currently the MIPS64r2 
> ISA is the highest 64-bit ISA we have a real processor support for so 
> use it and the 5KEf which is the processor we have that implements it.  
> Later, as newer processors are added, we can bump it further up.
> 
>  I think we should consider picking something for microMIPS support too 
> sometime, perhaps based on ELF file flags, however the thing is with 
> that we have no FPU processor to choose.  So let's skip it for now.
> 
>  I have tested it lightly by running the GCC test suite for the 
> mips-linux-gnu target and the n64 ABI (`-EB -mabi=64' multilib), using 
> MIPS64r2 code.
> 
>  Please apply.
> 
>   Maciej
> 
> qemu-mips-user-5kef.diff
> Index: qemu-git-trunk/linux-user/main.c
> ===================================================================
> --- qemu-git-trunk.orig/linux-user/main.c	2014-11-20 10:47:31.000000000 +0000
> +++ qemu-git-trunk/linux-user/main.c	2014-11-20 10:50:57.098940605 +0000
> @@ -3929,7 +3929,7 @@ int main(int argc, char **argv, char **e
>  #endif
>  #elif defined(TARGET_MIPS)
>  #if defined(TARGET_ABI_MIPSN32) || defined(TARGET_ABI_MIPSN64)
> -        cpu_model = "20Kc";
> +        cpu_model = "5KEf";
>  #else
>          cpu_model = "24Kf";
>  #endif
> 

Reviewed-by: Leon Alrae <leon.alrae@imgtec.com>