>>> 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.
Not exactly - we don't need a full save as long as insns writing to
memory don't alter other registers (that'll become an issue with
vscatter). It would be sufficient to store FSW up front, leaving most
of the additional overhead to just the failed-write path.
Xen-devel mailing list