Re: [Qemu-devel] [PATCH] linux-user: Use the 5KEf processor for 64-bit emulation

[Maciej W. Rozycki]

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