Re: [Qemu-devel] flushing before updating pc.ram

[TeLeMan]

On Fri, Feb 19, 2016 at 12:53 AM, Egbert S. <address@hidden> wrote:
> I have here a case (over at GitHub unicorn-engine/unicorn
> tests/unit/test_tb_x86.c) that is running a stack-based Alpha-Mixed sample
> that contains an instruction that changed an operand of the next
> instruction, the one that QEMU does not detect nor execute properly (even
> with TARGET_HAS_PRECISE_SMC define compiled in).  Stack-based writeable
> MemoryRegion "pc.ram" starts at 0x60000000.
>
>
> Live trace of QEMU is:
> ecx = 0x5ffffff8
> # Modify code location 60000028 to 0x10 from 0x51
> 60000021  304130  xor  byte ptr [ocx + 0x30], al
> 60000024  41      inc ecx
> 60000025  6b414151 imul eax, dword ptr [ecx + 0x41], 0x51
>
> In the notdirty_mem_write(), it does a tb_invalidate_phys_page_fast()
> firstly before writing directly to the "pc.ram".
>
> As a result, the newly reconstructed TB rebuilds the 'imul' micro-operation
> sequence , but still retrieving the original 0x51 immediate byte operand
> (and not the expected 0x10).
>
> Interestingly, doing a read operation of the exact 0x60000028 byte retrieves
> that updated (and correct) 0x10.
>
> Could it be that in the notdirty_mem_write(), that stX_p() must be performed
> firstly before the tb_invalidate_phys_page_fast()?
>

I think it is same as the old issue:

https://lists.nongnu.org/archive/html/qemu-devel/2014-08/msg02161.html