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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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?

Jan


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