qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] target/mips: Support Toshiba specific three-ope


From: Maciej W. Rozycki
Subject: Re: [Qemu-devel] [PATCH] target/mips: Support Toshiba specific three-operand MADD and MADDU
Date: Mon, 29 Oct 2018 15:44:57 +0000 (GMT)
User-agent: Alpine 2.21 (LFD 202 2017-01-01)

On Mon, 29 Oct 2018, Aleksandar Markovic wrote:

> > > Without TARGET_MIPS64, we can't say we emulate R5900 - we are emulating
> > > some other CPU that never existed.
> > >
> > > Convince me that I am wrong.
> > 
> > R5900 O32 is usable.
> 
> Absolutely not. This kind of emulation infidelity can't be in QEMU 
> upstream. Even one step further, this should be forbidden, impossible to 
> build.

 What do you mean by "R5900 o32 is not usable unless TARGET_MIPS64"?

 The user emulation mode does not emulate a CPU, it emulates an OS's user 
ABI.  None of the MIPS/Linux user ABIs exposes the privileged context and 
the user instruction set is also defined by the ABI, as far as both 
limitations (e.g. in o32 no MIPS III instructions are allowed, though 
32-bit MIPS IV ones are) and extensions (e.g. many FPU instructions, LL/SC 
and RDHWR implemented even if missing from hardware) are concerned.

 So user emulation is never going to be an accurate CPU emulation anyway.

 The R5900 specifically indeed has no way to enforce the o32 instruction 
set, unlike all the other MIPS CPUs, but that has to be considered a 
quirk, because the operation of the disallowed instructions is 
unpredictable in o32 anyway and the first context switch when actually 
executing real Linux rather than QEMU user emulation would clobber user 
registers.  And I don't think we need to define unpredictable operation in 
hardware-specific way, it may well send SIGILL telling the user they did 
something wrong (as opposed to silent context corruption observed with 
real hw).

 If you spoke about system emulation, then that would be a different 
matter and I would tend to agree, noting however that even there QEMU does 
not emulate all aspects of the architecture anyway, so it's always an 
approximation defined such as to fit the people's needs.

 What is this discussion about anyway?  Do you require now for new CPU 
subarchitecture acceptance that the whole instruction set has been 
implemented with the first submission?  I don't think that was the case in 
the past and even artificial inexisting CPUs have been created (which 
still are there AFAICT), but maybe I'm missing something, and of course 
the rules may change.

  Maciej



reply via email to

[Prev in Thread] Current Thread [Next in Thread]