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~
