[Qemu-devel] Is there a particular reason why REP STOS/MOV are jitted this way?

[Qemu-devel] Is there a particular reason why REP STOS/MOV are jitted this way?

[farmdve]

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

The rep stosd instruction seems to be jitted in a really weird way and I
was wondering what are the design choices behind this.
Basically the code is jitted to an operation where there is a conditional
branch that tests the ECX register to see if it's zero or not(although I
could have gotten this part wrong). If it's not, it proceeds to prepare the
data to be placed at es:[edi], decrements ECX and executes another
conditional branch that ends up at a jmp to 'helper_le_stl_mmu' effectively
exiting the translation block as execution will end up re-entering that
same TB.

My question is why isn't this jitted to a loop and a call to this helper?

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

Re: [Qemu-devel] Is there a particular reason why REP STOS/MOV are jitted this way?

[Peter Maydell]

On 20 December 2015 at 23:13, farmdve <farmdve@gmail.com> wrote:
> The rep stosd instruction seems to be jitted in a really weird way and I was
> wondering what are the design choices behind this.
> Basically the code is jitted to an operation where there is a conditional
> branch that tests the ECX register to see if it's zero or not(although I
> could have gotten this part wrong). If it's not, it proceeds to prepare the
> data to be placed at es:[edi], decrements ECX and executes another
> conditional branch that ends up at a jmp to 'helper_le_stl_mmu' effectively
> exiting the translation block as execution will end up re-entering that same
> TB.
>
> My question is why isn't this jitted to a loop and a call to this helper?

helper_le_stl_mmu is part of the standard load/store code and not
visible at the 'generate i386 guest code' layer; in any case the
fast path won't call the helper but can just directly access
the guest RAM.

I suspect the reason we do it the way we do is so that we can
correctly take an interrupt midway through the rep stosd and
have the intermediate state be correct -- the comments in the
GEN_REPZ macro say we do it like Valgrind, so this isn't a
QEMU-specific oddity. Handling single-step of a rep stosd
also requires care.

Since we generate the do-another-repetition code with
gen_jmp(s, cur_eip) that should result in a jump-to-TB
which is chainable, so once we've gone round once we won't
have to go back out to the main loop while we're iterating.

thanks
-- PMM