[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] x86emul: suppress memory writes after faulting FPU insns



>>> On 12.01.17 at 17:43, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 12/01/17 16:12, Jan Beulich wrote:
>>>>> On 12.01.17 at 16:04, <andrew.cooper3@xxxxxxxxxx> 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.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.