Re: [Xen-devel] [PATCH 2/3] tests/x86emul: Save and restore FPU state in the emulator callbacks

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 09.03.18 at 12:45, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 09/03/18 11:41, Jan Beulich wrote:
>>>>> On 06.03.18 at 21:24, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> Currently with then native toolchain on Debian Jessie ./test_x86_emulator
>>> yeilds:
>>>
>>>   Testing AVX2 256bit single native execution...okay
>>>   Testing AVX2 256bit single 64-bit code sequence...[line 933] failed!
>>>
>>> The bug is that libc's memcpy() in read() uses %xmm8 (specifically, in
>>> __memcpy_sse2_unaligned()), which corrupts %ymm8 behind the back of the AVX2
>>> test code.
>>>
>>> Switch all hooks to use "goto out" style returns, and use
>>> emul_{save,restore}_fpu_state().
>> "Switch hooks to  use "goto out" style returns as necessary, and ..."?
>> You don't even touch all of them, and even one of those that you
>> touch doesn't obtain any "goto".
>>
>>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>> As an immediate workaround
>> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
>> (also for patch 4)
>>
>> But of course this doesn't fully deal with the problem: Structure
>> assignments may still cause library functions to be invoked. Plus
>> there are explicit uses of memcpy() [which look safe] and
>> memset() [most or even all of which don't] in the core emulator.
>> I was therefore considering to instead provide hidden visibility
>> wrappers inside the binary, which would save/forward/restore.
>> That would also deal with someone wanting to add some printf()
>> in the middle of e.g. x86_emulate() for debugging purposes.
>>
>> Obviously sooner or later we'll need the same for the fuzzer hooks;
>> that alternative approach would perhaps result in less code churn
>> there as well (the source to provide the wrappers could likely be
>> shared).
> 
> I'm afraid that I don't understand what you mean here.  Are you
> proposing that we wrap all libc functions, and ifso, how?

Yes - all the ones we use, or that the compiler may be reasonably
expected to produce accesses to them, and that we see any risk
they might touch {x,y,z}mm registers. As to how - let me see if I
can make this work.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel