From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35696) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X4Bel-0001sZ-DW for qemu-devel@nongnu.org; Mon, 07 Jul 2014 12:20:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X4Bec-000430-CW for qemu-devel@nongnu.org; Mon, 07 Jul 2014 12:20:43 -0400 Received: from mail-qc0-x230.google.com ([2607:f8b0:400d:c01::230]:35940) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X4Bec-00042o-0f for qemu-devel@nongnu.org; Mon, 07 Jul 2014 12:20:34 -0400 Received: by mail-qc0-f176.google.com with SMTP id w7so3919553qcr.21 for ; Mon, 07 Jul 2014 09:20:33 -0700 (PDT) Sender: Richard Henderson Message-ID: <53BAC8CC.9070301@twiddle.net> Date: Mon, 07 Jul 2014 09:20:28 -0700 From: Richard Henderson MIME-Version: 1.0 References: <20140703065104.GP18016@ZenIV.linux.org.uk> <20140703182501.GQ18016@ZenIV.linux.org.uk> <53B5BAC7.1010603@twiddle.net> <20140704005024.GT18016@ZenIV.linux.org.uk> <53B62DCD.6030201@twiddle.net> <20140704072937.GU18016@ZenIV.linux.org.uk> <20140705014055.GV18016@ZenIV.linux.org.uk> <20140705210951.GX18016@ZenIV.linux.org.uk> <20140705225513.GY18016@ZenIV.linux.org.uk> <53BAAAAE.2060009@twiddle.net> <20140707150629.GZ18016@ZenIV.linux.org.uk> In-Reply-To: <20140707150629.GZ18016@ZenIV.linux.org.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] alpha qemu arithmetic exceptions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Al Viro Cc: Peter Maydell , QEMU Developers On 07/07/2014 08:06 AM, Al Viro wrote: > On Mon, Jul 07, 2014 at 07:11:58AM -0700, Richard Henderson wrote: >> A couple of points here: >> >> 1) We should never raise this in user-only mode. In that mode, we emulate the >> whole fpu stack, all the way through from HW to the OS completion handler. > > How is that different from other cases where we have an exception raised > by an fp operation? In all other cases we know we're going to send SIGFPE. That's either through a non /S insn which the kernel wouldn't touch, or by having computed the true IEEE result and examined the exceptions to be raised. >> 2) Because of that, we have the capability of doing the same thing in system >> mode. This lets us do more of the computation in the host, and less in the >> guest, which is faster. The only thing this makes more difficult is debugging >> the OS completion handlers within the kernel, since they'll only get invoked >> when SIGFPE needs to be sent. > > Umm... The effect of software completion depends on current->ieee_state; > how would you keep track of that outside of guest kernel? The kernel essentially keeps a copy of IEEE_STATE in the FPCR. I don't see any missing bits in ieee_swcr_to_fpcr, do you? While real hardware might ignore some of those bits once stored, qemu doesn't. While in real hardware one could force the FPCR and IEEE_STATE to differ, honestly that'd be a bug. (Although a silly one; I wish the kernel took the EV6 FPCR as gospel for everything, not just the status flags. That could make certain libm.so computations much faster.) > >> 3) If we do want to implement a mode where we faithfully send SWC for all of >> the bits of IEEE that real HW didn't implement, do we really need to avoid a >> store to the output register when signalling this? I.e. can we notice this >> condition after the fact with float_flag_input_denormal, rather than having >> another function call to prep the inputs? > > But flag_input_denormal is raised only when we do have DNZ set. Which is > an entirely different case, where we should not (and do not) get an exception > at all... Ah, you're right about that. I'd mis-remembered the implementation. r~