Re: [Qemu-devel] Question about gen_jmp_tb

Re: [Qemu-devel] Question about gen_jmp_tb

[Jack Biggs]

Hi Richard, thanks for your help.

Which instruction, then, I should add my gen_helper to in order for it 
to be called at the end of each basic block, as I've previously stated? 
Is there a way I can generically have this change apply to every target?

Jack

On 05/30/2014 06:25 PM, Richard Henderson wrote:
> On 05/30/2014 01:56 AM, Jack Biggs wrote:
>> Hi all,
>>
>> I'm trying to add some arbitrary code to the end of each translation block, and
>> I wanted to confirm my suspicion that each translation block ends in a jmp
>> instruction, and that each translation block ends (or jumps to another TB) with
>> the call to gen_jmp_tb. My guest is i386, but if this is architecture-specific
>> I'd like to know more about per-target semantics.
> No, not every tb ends with gen_jmp_tb.  Indeed, only those for which we have an
> immediate address end that way.  Plenty of tb's end with indirect branches, or
> for a variety of other reasons.
>
> Certainly gen_jmp_tb is specific to the i386 translator.
>
>
> r~

Re: [Qemu-devel] Question about gen_jmp_tb

[Alex Bennée]

Jack Biggs writes:

> Hi Richard, thanks for your help.
>
> Which instruction, then, I should add my gen_helper to in order for it 
> to be called at the end of each basic block, as I've previously stated? 
> Is there a way I can generically have this change apply to every target?
>
> Jack
>
> On 05/30/2014 06:25 PM, Richard Henderson wrote:
>> On 05/30/2014 01:56 AM, Jack Biggs wrote:
>>> Hi all,
>>>
>>> I'm trying to add some arbitrary code to the end of each translation block, and
>>> I wanted to confirm my suspicion that each translation block ends in
>>> a jmp

When you say arbitrary code what do you mean? Are you wanting to put
backend specific code there or a common post-amble of tcg ops?

Can you give a bit more detail about your use case?

>>> instruction, and that each translation block ends (or jumps to another TB) with
>>> the call to gen_jmp_tb. My guest is i386, but if this is architecture-specific
>>> I'd like to know more about per-target semantics.
>> No, not every tb ends with gen_jmp_tb.  Indeed, only those for which we have an
>> immediate address end that way.  Plenty of tb's end with indirect branches, or
>> for a variety of other reasons.
>>
>> Certainly gen_jmp_tb is specific to the i386 translator.
>>
>>
>> r~

-- 
Alex Bennée

Re: [Qemu-devel] Question about gen_jmp_tb

[Jack Biggs]

> When you say arbitrary code what do you mean? Are you wanting to put 
> backend specific code there or a common post-amble of tcg ops? Can you 
> give a bit more detail about your use case?

I'm trying to add a clock-synchronization library so that I can have two 
(or more) instances of QEMU run in a synchronized (deterministic) 
fashion. The "arbitrary code" is more or less a function call (i.e., 
callq) instruction to a function that uses shared semaphores to block 
execution.

Jack

Re: [Qemu-devel] Question about gen_jmp_tb

[Peter Maydell]

On 2 June 2014 11:15, Jack Biggs <john.biggs@epfl.ch> wrote:
>> When you say arbitrary code what do you mean? Are you wanting to put
>> backend specific code there or a common post-amble of tcg ops? Can you give
>> a bit more detail about your use case?
>
>
> I'm trying to add a clock-synchronization library so that I can have two (or
> more) instances of QEMU run in a synchronized (deterministic) fashion. The
> "arbitrary code" is more or less a function call (i.e., callq) instruction
> to a function that uses shared semaphores to block execution.

Bear in mind that we can also exit a TB via taking an unexpected
exception [usually a load/store which faults], in which case we'll
effectively longjump out of the middle of it.

If you can rearrange your design to only require your hooks
to be called at the *start* of a TB, not the end, that is
much easier -- the existing icount machinery does that already.

thanks
-- PMM

Re: [Qemu-devel] Question about gen_jmp_tb

[Jack Biggs]

Hi Peter,

This is not a problem for now, the main reason we wanted to have this at 
the end is to potentially trace load / stores in the future. How would 
you recommend integrating this into icount? Just wanting to make sure I 
don't run into anything unexpected.

Regards,

Jack


On 06/02/2014 12:47 PM, Peter Maydell wrote:
> If you can rearrange your design to only require your hooks to be 
> called at the *start* of a TB, not the end, that is much easier -- the 
> existing icount machinery does that already. thanks -- PMM 

Re: [Qemu-devel] Question about gen_jmp_tb

[Peter Maydell]

On 2 June 2014 11:53, Jack Biggs <john.biggs@epfl.ch> wrote:
> This is not a problem for now, the main reason we wanted to have this at the
> end is to potentially trace load / stores in the future. How would you
> recommend integrating this into icount? Just wanting to make sure I don't
> run into anything unexpected.

The icount hooks are in gen-icount.h.

thanks
-- PMM