[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: Jan Beulich <JBeulich@xxxxxxxx>
  • From: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
  • Date: Thu, 03 Jul 2014 12:12:04 +0300
  • Cc: tim@xxxxxxx, xen-devel@xxxxxxxxxxxxx
  • Comment: DomainKeys? See http://domainkeys.sourceforge.net/
  • Delivery-date: Thu, 03 Jul 2014 09:11:16 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com; b=t6PoLI3YJls1VWT6Aek6n3dNP3yZT0mnn0ITGwCTJrBeh8DWIRdmch9NOn5DRKtZAc0QqoWN/vZ8u6vLxdMuitxAhAID/N7u3N5GJVXRVzFgCxN0jtEKtaH/FqH2bdCCWrs9fTj4d3DpRAMxvIHPo5Ltkhg/BfNCY3gHptLzhr3oyjT1zFPz11TQpYSR+zmCFVtcs1Cga5u4xcpgY7LHHG29iEpY47NLinjnz0+Ea08ZqG41GsVO54JExVZ38Wojm+xGjla7OvIaovNIj99Qs/EI67lAmEuhBFdAV6Ombn/rPvwZedxVO5SrGqhN4KI8QKKSLtrpWvVE2P9fnD/8Ew==; h=Received:Received:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-BitDefender-Scanner:X-BitDefender-Spam:X-BitDefender-SpamStamp:X-BitDefender-CF-Stamp;
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

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]

Razvan Cojocaru

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.