[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] flushing before updating pc.ram
From: |
TeLeMan |
Subject: |
Re: [Qemu-devel] flushing before updating pc.ram |
Date: |
Fri, 19 Feb 2016 13:30:24 +0800 |
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