On Aug 19, 2014, at 2:16 AM, Paolo Bonzini <[email protected]> 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?
