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:34:10 +0300 Message-ID: <53B52392.1080804@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> <53B51E64.5020602@bitdefender.com> <53B53CEC0200007800020095@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <53B53CEC0200007800020095@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:22 PM, Jan Beulich wrote: >>>> On 03.07.14 at 11:12, wrote: >> 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] > > 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