[Qemu-devel] flushing before updating pc.ram

[Qemu-devel] flushing before updating pc.ram

[Egbert S.]

[-- Attachment #1: Type: text/plain, Size: 1168 bytes --]

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], al60000024  41      inc ecx60000025  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()?


[-- Attachment #2: Type: text/html, Size: 2183 bytes --]

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

[Paolo Bonzini]

Your solution seems sane, but I'd like a better understanding of what
happens.  Therefore...

On 18/02/2016 17:53, Egbert S. wrote:
> 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).

... can you provide the backtrace where QEMU translates the 'imul' from
within tb_invalidate_phys_page_fast?

Paolo

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

[TeLeMan]

On Fri, Feb 19, 2016 at 12:53 AM, Egbert S. <cjgd7-qemu@yahoo.com> 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