[Qemu-devel] new MIPS instructions

[Qemu-devel] new MIPS instructions

[Fabrice Bellard]

Hi,

Since many new MIPS instructions are added, I think it is very important 
  now to add a way to dynamically select the exact MIPS processor model 
that is emulated in QEMU.

I suggest adding a parameter to cpu_mips_init() telling the exact CPU 
model which is emulated. Optionnal features (such as the FPU) could be 
specified with an additionnal parameter.

Regards,

Fabrice.

Re: [Qemu-devel] new MIPS instructions

[Thiemo Seufer]

Fabrice Bellard wrote:
> Hi,
> 
> Since many new MIPS instructions are added, I think it is very important 
>  now to add a way to dynamically select the exact MIPS processor model 
> that is emulated in QEMU.

FWIW, I added MIPS32R2 instructions to my local copy while keeping the
CPU a MIPS32R1 4k. This is enough to boot a R2 Linux kernel, and it
should also be good enough to run a R2 userland.

I used the generic architecture spec, currently without using a specific
implementation (the latter would be nice for watchpoints and performance
registers, which are implementation specific).

> I suggest adding a parameter to cpu_mips_init() telling the exact CPU 
> model which is emulated. Optionnal features (such as the FPU) could be 
> specified with an additionnal parameter.

Probably with an additional switch "emulate everything we know about",
which would be especially useful for usermode emulation where CPU
specifics don't matter that much.


Thiemo

Re: [Qemu-devel] new MIPS instructions

[Dirk Behme]

Thiemo Seufer wrote:
> Fabrice Bellard wrote:
>>I suggest adding a parameter to cpu_mips_init() telling the exact CPU 
>>model which is emulated. Optionnal features (such as the FPU) could be 
>>specified with an additionnal parameter.
> 
> Probably with an additional switch "emulate everything we know about",
> which would be especially useful for usermode emulation where CPU
> specifics don't matter that much.

Good points, but I don't know which is the best way to go ;) 
I think there are pros for both ways:

Pro "emulate everything we know about" or "one MIPS fits 
all": Compile your program with a -march option you want, 
load the binary (or now the ELF as well ;) ) into QEMU and 
(if QEMU has support for the selected architecture) it will 
run. Without the user to select any special configuration on 
the command line (or tweaking inside QEMUs source code). It 
will run correctly without the user even to think about any 
special QEMU configuration. This was what I assumed before 
investigating why my code with a special -march option 
didn't work.

Pro "additional parameter": FPU is a good example for this. 
If the processor I want to emulate has no FPU I would assume 
if my code uses (accidently?)  FPU instructions I get 
exception/error/warning from QEMU. It confused me that QEMU 
(wrongly) executes my program with unsupported instructions 
(architecture) without any warning.

"one MIPS fits all" is a user friendly and QEMU easy to use 
option, while "additional parameter" is the option for 
emulation accuracy.

I'm not an ELF expert: Does ELF contain information about 
architecture compiled for? If yes, we can combine both ways 
above? Load ELF file, read architecture from it and let QEMU 
autoselect correct architecture features (or give error if 
not supported). Then we have emulation accuracy but don't 
need additional options.

Dirk

Re: [Qemu-devel] new MIPS instructions

[Paul Brook]

On Sunday 23 April 2006 19:41, Dirk Behme wrote:
> Thiemo Seufer wrote:
> > Fabrice Bellard wrote:
> >>I suggest adding a parameter to cpu_mips_init() telling the exact CPU
> >>model which is emulated. Optionnal features (such as the FPU) could be
> >>specified with an additionnal parameter.
> >
> > Probably with an additional switch "emulate everything we know about",
> > which would be especially useful for usermode emulation where CPU
> > specifics don't matter that much.
>
> Good points, but I don't know which is the best way to go ;)
> I think there are pros for both ways:

The way the Arm emulation handles this is to have a set of features that are 
checked by the emulation code. Or at least that's the idea, current CVS 
doesn't actually enforce most of these.

CPU selection is done by CPU model. This selects which features are available, 
and cpu specific info (Device IDs, etc). If neccy for usermode emulation you 
can invent a fictional CPU that contains the superset of all features.

I think ppc does something similar. Ideally there would be a common mechanism, 
but that doesn't exist.

The important thing is to make the emulation conditional, even if the initial 
implementation just uses compile time constants. Once the conditionals are 
there it's relatively easy to wire them up to whatever cpu selection 
mechanisms qemu invents.

Paul

Re: [Qemu-devel] new MIPS instructions

[Thiemo Seufer]

Dirk Behme wrote:
[snip]
> Pro "additional parameter": FPU is a good example for this. 
> If the processor I want to emulate has no FPU I would assume 
> if my code uses (accidently?)  FPU instructions I get 
> exception/error/warning from QEMU. It confused me that QEMU 
> (wrongly) executes my program with unsupported instructions 
> (architecture) without any warning.

In the long term we want both, I think, but ATM enhancing the emulation
capabilities has clearly priority for me.

We should probably go for a two-way approach: a per-ISA switch for
the userland emulation, and a per (generic-ish) CPU switch for
system emulation.

> I'm not an ELF expert: Does ELF contain information about 
> architecture compiled for? If yes, we can combine both ways 
> above? Load ELF file, read architecture from it and let QEMU 
> autoselect correct architecture features (or give error if 
> not supported). Then we have emulation accuracy but don't 
> need additional options.

Binutils adds usually header flags for the ISA, but it doesn't have to,
and the original ELF ABI mandates even the flags should be zero.

It doesn't cover FPU, and MIPS16 as only ASE AFAIR.


Thiemo