From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48912) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XJR1n-0001wR-Ny for qemu-devel@nongnu.org; Mon, 18 Aug 2014 13:47:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XJR1i-0008By-Jx for qemu-devel@nongnu.org; Mon, 18 Aug 2014 13:47:31 -0400 Received: from mx2.ll.mit.edu ([129.55.12.46]:47700) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XJR1i-0008BC-Gd for qemu-devel@nongnu.org; Mon, 18 Aug 2014 13:47:26 -0400 From: "Hulin, Patrick - 0559 - MITLL" Date: Mon, 18 Aug 2014 17:47:08 +0000 Message-ID: <98E51B30-6FC2-42D3-A5D2-6504B0B6472D@ll.mit.edu> References: <5FAD0382C1B6944A908C8A46AB12DA9D03E1EB@LLE2K10-MBX02.mitll.ad.local> <53EE7214.9000603@redhat.com> <9BA52E25-E3BF-42FF-B080-86B7926D8B80@ll.mit.edu> <53F03BCC.705@redhat.com> <53F239D1.6070001@twiddle.net> In-Reply-To: <53F239D1.6070001@twiddle.net> Content-Language: en-US Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Qemu-devel] QEMU, self-modifying code, and Windows 7 64-bit (no KVM) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: Paolo Bonzini , "qemu-devel@nongnu.org" On Aug 18, 2014, at 1:37 PM, Richard Henderson wrote: > On 08/16/2014 10:21 PM, Paolo Bonzini wrote: >>>> Would it work to just call tb_invalidate_phys_page_range before the >>>> helper_ret_stb loop? >=20 > I doubt it. Correct. Doesn=92t work. Haven=92t fully diagnosed why, but it doesn=92t se= em to ever hit the current_tb_modified passage if you invalidate beforehand= . > I believe that the proper solution is to force *both* page table entries = into > the TLB before performing any actual memory operations. >=20 > We'll have done the page for the first byte at the top of > helper_{le,be}_{ld,st}_name. When we discover it's an unaligned access, = we > should load and check the pte for the second page. We might have to shuf= fle > those two tests around, since in theory the second page could be I/O mapp= ed and > we'd want to pass off the whole access to io_mem_*. >=20 > Since two adjacent pages can't conflict in our direct-mapped TLB, we can = then > safely pass off the work to secondary helpers without fear the first TLB = entry > will be flushed. This isn=92t about cross-page writes, although that might make fixing the p= roblem a little tricky. The issue occurs with two adjacent TBs on the same = page: because the individual writes are split up and done in reverse order,= writes (and reads) off the back of the current TB happen twice. In the cas= e of an xor this means the original xor gets undone, which is what breaks i= n Windows 7.=