From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46611) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XJQsD-0005eR-1H for qemu-devel@nongnu.org; Mon, 18 Aug 2014 13:37:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XJQs3-0004tl-W2 for qemu-devel@nongnu.org; Mon, 18 Aug 2014 13:37:36 -0400 Received: from mail-qc0-x22f.google.com ([2607:f8b0:400d:c01::22f]:48051) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XJQs3-0004t5-RG for qemu-devel@nongnu.org; Mon, 18 Aug 2014 13:37:27 -0400 Received: by mail-qc0-f175.google.com with SMTP id w7so5045304qcr.20 for ; Mon, 18 Aug 2014 10:37:26 -0700 (PDT) Sender: Richard Henderson Message-ID: <53F239D1.6070001@twiddle.net> Date: Mon, 18 Aug 2014 10:37:21 -0700 From: Richard Henderson MIME-Version: 1.0 References: <5FAD0382C1B6944A908C8A46AB12DA9D03E1EB@LLE2K10-MBX02.mitll.ad.local> <53EE7214.9000603@redhat.com> <9BA52E25-E3BF-42FF-B080-86B7926D8B80@ll.mit.edu> <53F03BCC.705@redhat.com> In-Reply-To: <53F03BCC.705@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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: Paolo Bonzini , "Hulin, Patrick - 0559 - MITLL" Cc: "qemu-devel@nongnu.org" 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? I doubt it. >> Maybe. I think there’s another issue, which is that QEMU’s ending up >> in the I/O read/write code instead of the normal memory RW. This could >> be QEMU messing up, it could be PatchGuard doing something weird, or it >> could be me misunderstanding what’s going on. I never really figured out >> how the control flow works here. > > That's okay. Everything that's in the slow path goes down > io_mem_read/write (in this case TLB_NOTDIRTY is set for dirty-page > tracking and causes QEMU to choose that path). > > Try making a self-contained test case using the kvm-unit-tests harness > (git://git.kernel.org/pub/scm/virt/kvm/kvm-unit-tests.git). I believe that the proper solution is to force *both* page table entries into the TLB before performing any actual memory operations. 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 shuffle those two tests around, since in theory the second page could be I/O mapped and we'd want to pass off the whole access to io_mem_*. 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. r~