From mboxrd@z Thu Jan 1 00:00:00 1970 From: Razvan Cojocaru Subject: Re: [PATCH RFC 7/9] xen: Handle resumed instruction based on previous mem_event reply Date: Thu, 03 Jul 2014 12:12:04 +0300 Message-ID: <53B51E64.5020602@bitdefender.com> References: <1404308041-15461-1-git-send-email-rcojocaru@bitdefender.com> <1404308041-15461-7-git-send-email-rcojocaru@bitdefender.com> <53B447BA020000780001FB54@mail.emea.novell.com> <53B51A6A.30802@bitdefender.com> <53B538350200007800020017@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <53B538350200007800020017@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: tim@xen.org, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 07/03/2014 12:02 PM, Jan Beulich wrote: >>>> On 03.07.14 at 10:55, wrote: >> On 07/02/2014 06:56 PM, Jan Beulich wrote: >>>>>> On 02.07.14 at 15:33, 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