qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: qemu-devel@nongnu.org, qemu-ppc@nongnu.org
Cc: David Gibson <david@gibson.dropbear.id.au>,
	Paul Mackerras <pmac@au1.ibm.com>,
	Anton Blanchard <anton@au1.ibm.com>,
	Fabien Chouteau <chouteau@adacore.com>,
	Tristan Gingold <gingold@adacore.com>,
	Richard Henderson <rth@twiddle.net>
Subject: [Qemu-devel] ppc: TCG and FP exceptions, is it right ?
Date: Mon, 25 Jul 2016 19:44:46 +1000	[thread overview]
Message-ID: <1469439886.5978.31.camel@kernel.crashing.org> (raw)

Hi folks !

I could use a bit of help determining if something is quite right in
TCG emulation of FP ops.

Fabien, Tristan, you submitted a patch back in 2013:

db72c9f256ae70b30c5d5985234f085df4226c55 "powerpc: correctly handle fpu
exceptions" which effectively makes any of the exceptions generated
for underflow, overflow and inexact fire right away
(helper_raise_exception_err will exit the cpu loop with a setjmp).

This makes them effectively do the same thing
as float_zero_divide_excp().

However I *think* it might not be what we want, according to the
comment in helper_float_check_status() that says

 /* Differred floating-point exception after target FPR update */

And according to the architecture definition for those exceptions,
where we indeed want the target FPR updated before we take the
interrupts.

The code as writte will take the exception before the FPR is updated,
I *think*, or am I missing something here  ?

I think the intent was to return to the translated code so the FPRons
update happen, though we ideally would need to also set some state
so the translated code itself can then check for an exception and
fire it.

However as you noticed, that doesn't work well either.

What do you think is the most appropriate implementation here?

I'm thinking it's almost worth bringing FE0/FE1 into the hflags
so that we know at translation time whether to be precise, imprecise,
or ignore FP exceptions.

Then we could do something along the lines of:
 
  - In the helpers, when checking status, set an env flag if an
exception should occur.

  - In all the translate call sites, if FE0/1 is non-0 (at translate
time), generate call to check that flag and shoot the exception

  - Optionally, we could even implement some smarts to defer this to
the end of a TB in imprecise mode.

An additional note is that if FE0/FE1 are 0, we still in some case
leave an exception behind in cs->exception_index. Now, I *think*
that's ok, it will just be silently dropped at some point, but I am not
100% certain as that's a part of TCG I'm an not super familiar with
yet.

What do you guys reckon ? I am missing something here ?

Cheers,
Ben.

             reply	other threads:[~2016-07-25  9:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-25  9:44 Benjamin Herrenschmidt [this message]
2016-07-25 13:35 ` [Qemu-devel] ppc: TCG and FP exceptions, is it right ? Richard Henderson
2016-07-25 21:38   ` Benjamin Herrenschmidt
2016-07-25 15:12 ` Tristan Gingold
2016-07-25 21:50   ` Benjamin Herrenschmidt

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=1469439886.5978.31.camel@kernel.crashing.org \
    --to=benh@kernel.crashing.org \
    --cc=anton@au1.ibm.com \
    --cc=chouteau@adacore.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=gingold@adacore.com \
    --cc=pmac@au1.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=rth@twiddle.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).