From: Aurelien Jarno <aurelien@aurel32.net>
To: Pavel Dovgaluk <Pavel.Dovgaluk@ispras.ru>
Cc: pbonzini@redhat.com, leon.alrae@imgtec.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] MIPS: exceptions handling in icount mode
Date: Mon, 15 Jun 2015 10:28:44 +0200 [thread overview]
Message-ID: <20150615082844.GB931@aurel32.net> (raw)
In-Reply-To: <000801d0a73f$a5f85d00$f1e91700$@Dovgaluk@ispras.ru>
On 2015-06-15 10:48, Pavel Dovgaluk wrote:
> > From: Aurelien Jarno [mailto:aurelien@aurel32.net]
> > On 2015-06-15 07:53, Pavel Dovgaluk wrote:
> > > > From: Aurelien Jarno [mailto:aurelien@aurel32.net]
> > > > On 2015-06-10 11:33, Pavel Dovgalyuk wrote:
> > > > > This patch fixes exception handling in MIPS.
> > > > > MIPS instructions generate several types of exceptions.
> > > > > When exception is generated, it breaks the execution of the current translation
> > > > > block. Implementation of the exceptions handling in MIPS does not correctly
> > > > > restore icount for the instruction which caused the exception. In most cases
> > > > > icount will be decreased by the value equal to the size of TB.
> > > >
> > > > I don't think it is correct. There is no real point of always doing
> > > > retranslation for an exception triggered from the helpers, especially
> > > > when the CPU state has been saved before anyway?
> > >
> > > As you know, icount is processed as follows:
> > >
> > > TB:
> > > if icount < n then exit
> > > icount -= n
> > > instr1
> > > instr2
> > > ...
> > > instrn
> > > exit
> > >
> > > When one of the instructions initiates an exception, then icount should be restored
> > > and adjusted number of instructions should be subtracted instead of initial n.
> > >
> > > E.g., tlb_fill function passes retaddr to raise_exception, which allows restoring
> > > current instructions in TB and correct icount calculation.
> > >
> > > When exception triggered with other function (e.g. by embedding call to
> > > helper_raise_exception_err into TB), then PC is not passed as retaddr and
> > > correct icount is not recovered.
> > >
> > > This behavior leads to incorrect values of timers and non-deterministic execution
> > > of the code.
> >
> > Ok, this therefore doesn't looks something MIPS specific, but rather a
> > flaw in the icount design. Instead of fixing blindly one target, we
> > should try to fix it globally, or if not possible at least agree on a
> > way to fix that for all target and provide the infrastructure for that
> > (for example provide load/store functions which accept a return
> > address). Paolo any opinion on that?
>
> Recovering from is a tricky mechanism. It can break the correct execution
> if used inaccurately even when icount is disabled.
> I already posted a patch for maskmov instruction in i386:
> http://lists.nongnu.org/archive/html/qemu-devel/2014-09/msg02960.html
One solution there is to save the CPU state before calling the maskmov
helper. That would fix the bug, but not the icount problem you reported.
If we decided that we must always be able to do retranslation, we should
go with the second possibility from Richard:
| (2) Add helpers that accept the GETRA value from the top-level helper. And not
| hidden within a macro or always_inline function. This helps us see what
| portions of the code have been audited for the new interface. This will
| involve quite a bit more code churn, but shouldn't been too difficult for any
| single function.
And we should do it a way that it works for both user and softmmu modes,
to avoid too many #ifdef in the targets code, which in general is a
source of bugs.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
prev parent reply other threads:[~2015-06-15 8:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-10 8:33 [Qemu-devel] [PATCH] MIPS: exceptions handling in icount mode Pavel Dovgalyuk
2015-06-11 22:37 ` Aurelien Jarno
2015-06-15 4:53 ` Pavel Dovgaluk
2015-06-15 7:26 ` Aurelien Jarno
2015-06-15 7:39 ` Pavel Dovgaluk
2015-06-15 8:22 ` Aurelien Jarno
2015-06-15 7:48 ` Pavel Dovgaluk
2015-06-15 8:28 ` Aurelien Jarno [this message]
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=20150615082844.GB931@aurel32.net \
--to=aurelien@aurel32.net \
--cc=Pavel.Dovgaluk@ispras.ru \
--cc=leon.alrae@imgtec.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.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.