[Top][All Lists]

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

Re: [Qemu-devel] QEMU, self-modifying code, and Windows 7 64-bit (no KVM

From: Hulin, Patrick - 0559 - MITLL
Subject: Re: [Qemu-devel] QEMU, self-modifying code, and Windows 7 64-bit (no KVM)
Date: Mon, 18 Aug 2014 17:47:08 +0000

On Aug 18, 2014, at 1:37 PM, Richard Henderson <address@hidden> 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?
> I doubt it.

Correct. Doesn’t work. Haven’t fully diagnosed why, but it doesn’t seem 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.
> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]