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

[Hulin, Patrick - 0559 - MITLL]

On Aug 19, 2014, at 2:16 AM, Paolo Bonzini <address@hidden> wrote:

> Il 18/08/2014 22:50, Hulin, Patrick - 0559 - MITLL ha scritto:
>>>> 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.
>> Yeah - mem_io_pc doesn¹t get updated until we¹re inside io_write, so
>> tb_invalidate_phys_page_range thinks we¹re inside a different TB. As a
>> result, it¹s ³is this TB modified² check still returns false.
> 
> We can set that (and probably mem_io_vaddr) before the for loop, too.
> 
> Paolo

Strange - keeping the loop reversed and calling tb_invalidate_phys_range, with 
mem_io_pc set, works on the test case but fails on real Windows 7. It must be 
breaking something else.

I think making the loop forwards again makes the most sense. I’m not sure if 
the bug from 2007 will even still occur. That was caused by QEMU’s longjmp’ing 
only after the page boundary, similar to how it now only longjmp’s after the TB 
boundary. QEMU currently decides whether to longjmp by checking whether any of 
the TBs that intersect the page (i.e. p->first_tb etc.) contain the write 
address, and every code page should be TLB-protected. So every unaligned (and 
therefore out-of-line) write that touches already-translated code should get 
caught. As far as I can tell, the only problem is when a write splits into 
partially touching translated and untranslated code.

Can you guys explain why calling tlb_fill is necessary on the page boundary 
case?