Re: [Xen-devel] [PATCH RFC 7/9] xen: Handle resumed instruction based on previous mem_event reply

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

On 07/03/2014 12:22 PM, Jan Beulich wrote:
>>>> On 03.07.14 at 11:12, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>> On 07/03/2014 12:02 PM, Jan Beulich wrote:
>>>>>> On 03.07.14 at 10:55, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>>>> On 07/02/2014 06:56 PM, Jan Beulich wrote:
>>>>>>>> On 02.07.14 at 15:33, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>>>>>> In a scenario where a page fault that triggered a mem_event occured,
>>>>>> p2m_mem_access_check() will now be able to either 1) emulate the
>>>>>> current instruction, 2) skip the current instruction, or 3) emulate
>>>>>> it, but don't allow it to perform any writes. Since some SSE2
>>>>>> instructions are problematic to emulate (Firefox uses some),
>>>>>> support for setting the A and D (accessed and dirty) bits has been
>>>>>> added (please see p2m_set_ad_bits()).
>>>>>
>>>>> Sadly that reference is useless - the function doesn't have any
>>>>> explanation what all this is about either.
>>>>
>>>> p2m_set_ad_bits() ends up calling the code in
>>>> xen/arch/x86/mm/hap/guest_walk.c, namely an "instantiation" of
>>>> hap_p2m_ga_to_gfn(GUEST_PAGING_LEVELS)(), which in turn calls
>>>> guest_walk_tables() (from xen/arch/x86/mm/guest_walk.c), which sets up
>>>> the A/D bits allowing the problematic instructions to run while
>>>> bypassing emulation for that specific case.
>>>
>>> That's the mechanical part one can indeed work out from the patch.
>>> The interesting but unexplained thing here is which "some SSE2
>>> instructions" you refer to, and what's so special about them (you
>>> not also including e.g. AVX here makes me further curious, as in
>>> most cases AVX ones are direct extensions of SSEn ones, and hence
>>> I'd expect them to be similarly problematic).
>>
>> An example that kept appearing with Xen 4.3 and Firefox in our test
>> environment was: divsd xmm0, qword ptr [0x21c290]
> 
> And what's so special about it? Just that there's a better chance of it
> raising #XM? And why would divss (which is SSE, not SSE2) or vdivsd
> (AVX) not have similar problems?

Nothing is particularly special about it, apart from the fact that it
caused our hypervisor to print out:

Emulation failed @ 001b:21107d: f2 0f 5e 05 90 c2 21 00 8b 4d

and Firefox crashed. Indeed, I agree with Andrew that this looks like a
bug in Xen's emulator, however rather than treating each case
individually and risk random application crashes with instructions we
missed, we decided to, for our purposes, treat this as a class of cases
that can be handled in the same way regardless of the specific instruction.


Thanks,
Razvan Cojocaru

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