>>> On 12.01.17 at 17:43, <andrew.coop...@citrix.com> wrote: > On 12/01/17 16:12, Jan Beulich wrote: >>>>> On 12.01.17 at 16:04, <andrew.coop...@citrix.com> wrote: >>> On 12/01/17 14:02, Jan Beulich wrote: >>>> Furthermore I think we have another issue with writes: If the write >>>> faults, the FSW (or MXCSR, albeit there only for instructions we don't >>>> emulate yet) register may have been updated already, so we'd need to >>>> undo that update. >>> Do you mean restore the value before we sample it, or before the guest >>> gets to see it? >> Read it, run the stub, call ->write(), and upon failure restore the >> value read in the first step. >> >>> (I can't see what the problem is here.) >> The stub execution may modify FSW/MXCSR, if the operation causes >> an exception to be latched (for MXCSR this would need to be a >> masked exception), but if ->write() fails architecturally the update to >> FSW/MXCSR should not be committed. > > Ok - I see now. Yes - this is ugly corner case. Short of doing a > pre-emptive fpu save before emulation, I don't see an alternative. This > at least makes us no worse than taking a context switch.
And apparently one which even hardware gets wrong: While FPU insns (I've tried just one) look to work as expected, VCVTPS2PH updates MXCSR even when raising #PF. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
