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
|
Home