Re: [Xen-ia64-devel] [Fwd: [Xen-bugs] [Bug 1392] New: Problems with denormalized floating point numbers on XEN-virtualized Linux/IA64]

[Isaku Yamahata <yamahata@xxxxxxxxxxxxx>]

On Sat, Dec 06, 2008 at 11:10:22AM +0800, Zhang, Xiantao wrote:
> > If we fail to get a bundle in a guest when FP trap,
> > we can't reexecute the instruction. We have to inject floating
> > point trap into guest.
> 
> For HVM, injecting  it to guest should be the right way to go.  

Another issue.
When fpswa library in xen VMM returns status > 0, 
what should we do for PV/HVM domain? 
I suppose this case hasn't been tested.
The current implementation just inject FP trap/fault into guest,
and guest calls fpswa itself.

In such a case, fpswa is called twice. I tried to revert the effect
of fpswa library call with the new patch series, but it wasn't enough.
In order to revert the effect, all the fp register must be saved
before the call. It would impose unacceptable performance overhead.

Some considerations:

- let fpswa library be called twice.
  Is it safe to call fpswa library twice? If this answer is yes,
  this option can be taken.
  However I'm not sure. the specification[1] doesn't tell much.
  Looking at the linux trap handler, might it be sufficent
  for fpswa to return error > 0 on the second call?

  [1] "Itanium Processor floating-point software assistance and 
       floating-point exception handling."

- Ignore this issue.
  Are there any applications which depend on SIGFPE process signal?
  If no, we might be able to ignore this case.
  On native Linux, SIGPFE is delivered to the process when fpswa
  returns status > 0.
  If there is no application to use SIGPFE to recover its computation,
  we might be able to ignore this issue (until an unfortunate application
  developers complains).

- save the result of fpswa call in xen VMM and return the value
  when fpswa hypercall is issued assuming the guest kernel is none
  preemptive. This is only for PV domain.
  The first thing which comes into my mind is that the guest kernel might
  be preemptive.
  The previous implementation (before my patch) assumes that
  the PV guest kernel is none preemptive, and it calls fpswa library call
  right after the fp fault/trap.
  So it saves the result of fpswa call in Xen VMM and returned
  the return values.
  The Linux fp fault/trap handler assumes not to be preempted between
  fault/trap occurrence and fpswa library call because it uses
  processor's f2-f5, f12-f127.
  As for HVM domain case, guest firmware uses its own fpswa library,
  the call isn't hooked to Xen VMM. So this isn't an option for HVM
  domain.

- abandon to handle fp trap/fault in Xen VMM.
  Always inject the fp trap/fault into a guest without calling
  fpswa library in Xen VMM. This should work and the implementation
  would become simple. But how about performance?

thanks,
-- 
yamahata

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel