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: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]


Thanks,
Razvan Cojocaru

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