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 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).

Jan


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