Message ID | alpine.DEB.1.10.1411201131270.2881@tp.orcam.me.uk |
---|---|
State | New |
Headers | show |
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>
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
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