All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Aleksandar Markovic <amarkovic@wavecomp.com>
Cc: "Fredrik Noring" <noring@nocrew.org>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	"Aurelien Jarno" <aurelien@aurel32.net>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"Jürgen Urban" <JuergenUrban@gmx.de>
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)	[thread overview]
Message-ID: <alpine.LFD.2.21.1810291514390.1741@eddie.linux-mips.org> (raw)
In-Reply-To: <BN6PR2201MB1251F9D0D28E1177AF8E6B8DC6F30@BN6PR2201MB1251.namprd22.prod.outlook.com>

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	other threads:[~2018-10-29 15:45 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-14 14:29 [Qemu-devel] [PATCH] target/mips: Support Toshiba specific three-operand MADD and MADDU Philippe Mathieu-Daudé
2018-10-14 16:41 ` Fredrik Noring
2018-10-14 21:56   ` Philippe Mathieu-Daudé
2018-10-14 23:03     ` Maciej W. Rozycki
2018-10-15 17:02       ` Fredrik Noring
2018-10-16  9:43         ` Aleksandar Markovic
2018-10-16 18:19           ` Fredrik Noring
2018-10-16 18:37             ` Richard Henderson
2018-10-16 18:52               ` Fredrik Noring
2018-10-16 19:02                 ` Maciej W. Rozycki
2018-10-19 18:09                   ` Aleksandar Markovic
2018-10-28 19:43               ` Aleksandar Markovic
2018-10-28 20:00                 ` Maciej W. Rozycki
2018-10-29 11:52                 ` Aleksandar Markovic
2018-10-29 14:51                   ` Fredrik Noring
2018-10-29 15:03                     ` Aleksandar Markovic
2018-10-29 15:44                       ` Maciej W. Rozycki [this message]
2018-10-16 18:55             ` Maciej W. Rozycki
2018-10-15 15:36     ` Fredrik Noring
2018-10-24 18:01 ` Fredrik Noring
2018-10-26 11:17   ` Aleksandar Markovic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.21.1810291514390.1741@eddie.linux-mips.org \
    --to=macro@linux-mips.org \
    --cc=JuergenUrban@gmx.de \
    --cc=amarkovic@wavecomp.com \
    --cc=aurelien@aurel32.net \
    --cc=f4bug@amsat.org \
    --cc=noring@nocrew.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.