All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: "Hulin, Patrick - 0559 - MITLL" <Patrick.Hulin@ll.mit.edu>,
	Richard Henderson <rth@twiddle.net>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] QEMU, self-modifying code, and Windows 7 64-bit (no KVM)
Date: Mon, 18 Aug 2014 23:12:40 +0200	[thread overview]
Message-ID: <53F26C48.7040904@redhat.com> (raw)
In-Reply-To: <98E51B30-6FC2-42D3-A5D2-6504B0B6472D@ll.mit.edu>

Il 18/08/2014 19:47, Hulin, Patrick - 0559 - MITLL ha scritto:
>> 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.
> 
> This isn’t about cross-page writes, although that might make fixing
> the problem 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 case of an xor this means the original xor gets
> undone, which is what breaks in Windows 7.

If you fill the TLB beforehand as suggested by Richard, you can reverse
again the direction of the "for" loop.  This should hopefully fix your bug.

Of course if the write is not cross-page, there's no need to do the TLB
pre-fill.

Thanks for the test case!

Paolo

  parent reply	other threads:[~2014-08-18 21:13 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAG5rQryFDdrYZKPWYm8k_5EPGOP9RgvUqamSkjWiO3UikieeAw@mail.gmail.com>
2014-08-13 18:36 ` [Qemu-devel] QEMU, self-modifying code, and Windows 7 64-bit (no KVM) Hulin, Patrick - 0559 - MITLL
2014-08-14 13:53   ` Hulin, Patrick - 0559 - MITLL
2014-08-15 20:48   ` Paolo Bonzini
2014-08-15 21:49     ` Hulin, Patrick - 0559 - MITLL
2014-08-17  5:21       ` Paolo Bonzini
2014-08-18 17:37         ` Richard Henderson
2014-08-18 17:47           ` Hulin, Patrick - 0559 - MITLL
2014-08-18 20:50             ` Hulin, Patrick - 0559 - MITLL
2014-08-19  6:16               ` Paolo Bonzini
2014-08-20 14:03                 ` Hulin, Patrick - 0559 - MITLL
2014-08-20 15:12                   ` Richard Henderson
2014-08-18 21:12             ` Paolo Bonzini [this message]
2014-08-18 17:47         ` Hulin, Patrick - 0559 - MITLL
2014-08-18 18:08           ` Hulin, Patrick - 0559 - MITLL

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53F26C48.7040904@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=Patrick.Hulin@ll.mit.edu \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.