[Qemu-devel] Detecting an assembly instruction in QEMU

[Qemu-devel] Detecting an assembly instruction in QEMU

[Atif Hashmi]

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

Hi All,

I am inserting

movl %eax, %eax

instruction within the assembly code of a program and I am running the code
on QEMU which is configured for i386 and is running linux-0.2.img.

I want to detect this assembly instruction within the QEMU code in order to
perform a specific operation e.g. when ever QEMU finds this instruction a
specific function is called. Could anyone please tell me which QEMU files
should I modify in order to add this functionality. I looked through almost
all the C files but was unable to figure it out.

I will really appreciate any help.

Thanks,
Atif

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

[Qemu-devel] Re: Detecting an assembly instruction in QEMU

[Atif Hashmi]

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

Hi All,

Adding another note to my previous email. Is this even possible to do what I
am mentioned in my last email? (See Below)

Regards,
Atif

On 4/3/07, Atif Hashmi <atifhashmi@gmail.com> wrote:
>
> Hi All,
>
> I am inserting
>
> movl %eax, %eax
>
> instruction within the assembly code of a program and I am running the
> code on QEMU which is configured for i386 and is running linux-0.2.img.
>
> I want to detect this assembly instruction within the QEMU code in order
> to perform a specific operation e.g. when ever QEMU finds this instruction
> a specific function is called. Could anyone please tell me which QEMU files
> should I modify in order to add this functionality. I looked through almost
> all the C files but was unable to figure it out.
>
> I will really appreciate any help.
>
> Thanks,
> Atif
>

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

Re: [Qemu-devel] Re: Detecting an assembly instruction in QEMU

[Eduardo Felipe]

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

Hi,

Your should create a new helper function in \target-i386\helper.c to perform
whatever you want QEMU to do when movl %eax,%eax is found.

To invoke that function create a new opcode in \target-i386\op.c. That
opcode should only call your helper function.

Finally, modify \target-i386\translate.c to generate your opcode when movl
%eax,%eax is translated. Look for the string 0x89, you can find out target
and source registers of the move operation from variable modrm, so only %eax
is considered.

Regards,
Eduardo

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

Re: [Qemu-devel] Re: Detecting an assembly instruction in QEMU

[Atif Hashmi]

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

Hi Eduardo,

I really appreciate your help but there is a small think that I need to ask
you.

In target-i386/translate.c, there are many variants of mov i.e.
 case 0x89: /* mov Gv, Ev */
 case 0xc7: /* mov Ev, Iv */
 case 0x8b: /* mov Ev, Gv */
 case 0x8e: /* mov seg, Gv */

which one do you think will be called when "mov %eax, %eax" instruction is
translated.
I printed the value of modrm inside the case 0x89 but the value remains the
same whether I use %eax or %ebx.

Secondly, How can I extract the source and destination registers from modrm.

I will really appreciate your help.

Thanks,
Atif


On 4/6/07, Eduardo Felipe <edusaper@gmail.com> wrote:
>
> Hi,
>
> Your should create a new helper function in \target-i386\helper.c to
> perform whatever you want QEMU to do when movl %eax,%eax is found.
>
> To invoke that function create a new opcode in \target-i386\op.c. That
> opcode should only call your helper function.
>
> Finally, modify \target-i386\translate.c to generate your opcode when movl
> %eax,%eax is translated. Look for the string 0x89, you can find out target
> and source registers of the move operation from variable modrm, so only %eax
> is considered.
>
> Regards,
> Eduardo
>
>
>

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

Re: [Qemu-devel] Re: Detecting an assembly instruction in QEMU

[Eduardo Felipe]

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

Hi Atif,

In target-i386/translate.c, there are many variants of mov i.e.
>  case 0x89: /* mov Gv, Ev */
>  case 0xc7: /* mov Ev, Iv */
>  case 0x8b: /* mov Ev, Gv */
>  case 0x8e: /* mov seg, Gv */


That's true. I forgot the fact that mov %eax,%eax can be both:

0x89 0xC0
0x8B 0xC0

It's up to the compiler to choose which one to use.

which one do you think will be called when "mov %eax, %eax" instruction is
> translated.
> I printed the value of modrm inside the case 0x89 but the value remains
> the same whether I use %eax or %ebx.
>
> Secondly, How can I extract the source and destination registers from
> modrm.


modrm is the byte following the 0x89 or 0x8B opcode. After

modrm = ldub_code(s->pc++);

you can decode it this way (in binary):
XXYYYZZZ

XX --> Indexing mode
YYY --> Destination register
ZZZ --> Source register

0xC0 is the value you are looking for 11 000 000 --> (no
indexing)(%eax)(%eax).

You can find more information here:
http://pdos.csail.mit.edu/6.828/2005/readings/i386/s17_02.htm

One more thing: you may want to check operand size. It's on "ot" variable,
and its meaning (from translate.c):
enum {
    OT_BYTE = 0,
    OT_WORD,
    OT_LONG,
    OT_QUAD,
};

being 8, 16, 32 and 64 bits respectively.

Regards,
Eduardo

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

Re: [Qemu-devel] Re: Detecting an assembly instruction in QEMU

[Atif Hashmi]

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

Hi Eduardo,

Thanks a lot for your help. I really appreciate it. I have added the
functionality that I wanted.

By the way, Is there any documentation that can help me better understand
the QEMU source code?

Regards,
Atif

On 4/8/07, Eduardo Felipe <edusaper@gmail.com> wrote:
>
> Hi Atif,
>
> In target-i386/translate.c, there are many variants of mov i.e.
> >  case 0x89: /* mov Gv, Ev */
> >  case 0xc7: /* mov Ev, Iv */
> >  case 0x8b: /* mov Ev, Gv */
> >  case 0x8e: /* mov seg, Gv */
>
>
> That's true. I forgot the fact that mov %eax,%eax can be both:
>
> 0x89 0xC0
> 0x8B 0xC0
>
> It's up to the compiler to choose which one to use.
>
> which one do you think will be called when "mov %eax, %eax" instruction is
> > translated.
> > I printed the value of modrm inside the case 0x89 but the value remains
> > the same whether I use %eax or %ebx.
> >
> > Secondly, How can I extract the source and destination registers from
> > modrm.
>
>
> modrm is the byte following the 0x89 or 0x8B opcode. After
>
> modrm = ldub_code(s->pc++);
>
> you can decode it this way (in binary):
> XXYYYZZZ
>
> XX --> Indexing mode
> YYY --> Destination register
> ZZZ --> Source register
>
> 0xC0 is the value you are looking for 11 000 000 --> (no
> indexing)(%eax)(%eax).
>
> You can find more information here:
> http://pdos.csail.mit.edu/6.828/2005/readings/i386/s17_02.htm
>
> One more thing: you may want to check operand size. It's on "ot" variable,
> and its meaning (from translate.c):
> enum {
>     OT_BYTE = 0,
>     OT_WORD,
>     OT_LONG,
>     OT_QUAD,
> };
>
> being 8, 16, 32 and 64 bits respectively.
>
> Regards,
> Eduardo
>
>

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

Re: [Qemu-devel] Re: Detecting an assembly instruction in QEMU

[Eduardo Felipe]

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

I recommend:

http://fabrice.bellard.free.fr/qemu/user-doc.html

Regards,
Eduardo

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

Re: [Qemu-devel] Re: Detecting an assembly instruction in QEMU

[Atif Hashmi]

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

Hi,

I have another small question. Actually, I am implementing hardware
transactional memory support in QEMU. I have implemented the following two
helper functions functions in targer-i386/helper.c

void helper_StartTransaction()
void helper_CommitTransaction();

My application looks as follows.
int main()
{
       __asm_volatile("mov %al %al"); //is detected in translation.c and
helper_StartTransaction is called

}
In case a transaction fails, I detect it inside the code for
helper_CommitTransaction(), now I need to jump back to the place where

On 4/8/07, Eduardo Felipe <edusaper@gmail.com> wrote:
>
>
> I recommend:
>
> http://fabrice.bellard.free.fr/qemu/user-doc.html
>
> Regards,
> Eduardo
>

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

Re: [Qemu-devel] Re: Detecting an assembly instruction in QEMU

[Atif Hashmi]

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

Sorry for my previous incomplete email

Hi,

I have another small question. Actually, I am implementing hardware
transactional memory support in QEMU. I have implemented the following two
helper functions functions in targer-i386/helper.c

void helper_StartTransaction()
void helper_CommitTransaction();

My application looks as follows.
int main()
{
       __asm_volatile("mov %al %al"); //is detected in translation.c and
helper_StartTransaction is called
       //add the code here
      __asm_volatile("mov %bl %bl"); //is detected in translation.c and
helper_CommitTransaction is called
}

In case a transaction fails, I detect it inside the code for
helper_CommitTransaction(), now I need to jump back to the start of
transaction. I do it by using setjmp inside helper_StartTransaction and
calling longjmp inside CommitTransaction, Code for the two helper functions
is as follows

void helper_StartTransaction()
{
    printf("StartTransaction Called\n");
    if(setjmp(env->tm_jmp))
    {
      printf("Transaction restart\");
    }

}

void helper_CommitTransaction()
{
    printf("CommitTransaction Called\n");
    longjmp(env->tm_jmp, 0);
}

But this prints "Transaction restart" once and then the program finishes.
This means that commit transaction is not called the second time. Could you
please tell me what am I doing wrong?

Regards,
Atif
On 4/16/07, Atif Hashmi <atifhashmi@gmail.com> wrote:
>
>
>
> On 4/8/07, Eduardo Felipe <edusaper@gmail.com> wrote:
> >
> >
> > I recommend:
> >
> > http://fabrice.bellard.free.fr/qemu/user-doc.html
> >
> > Regards,
> > Eduardo
> >
>
>

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

Re: [Qemu-devel] Re: Detecting an assembly instruction in QEMU

[Eduardo Felipe]

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

Hi

2007/4/17, Atif Hashmi <atifhashmi@gmail.com>:
>
>
> But this prints "Transaction restart" once and then the program finishes.
> This means that commit transaction is not called the second time. Could you
> please tell me what am I doing wrong?


Helper functions are outside the translated opcode stream and are invoked by
call/ret:

.------.
|      |
|   ---+-->  helper_StartTransaction()
|   <--+-------------------/
|      |
|      |
|   ---+-->  helper_CommitTransaction()
|   <--+-------------------/
|      |
'------'

When you longjmp from helper_CommitTransaction to helper_StartTransaction
it's probable that you return back to the point where
helper_CommitTransaction should have returned to, as it is the last address
stored in the stack.

Anyway, guest code between the start and the end of the transaction should
not be rerun without updating guest machine state (eip, flags, etc.).

You should better forget about using setjmp/longjmp. Maybe something like
this could do the trick:

when translating mov %al,%al:
{
  ...
  ...
  store the address (eip) of mov %al,%al instruction somewhere
  gen_op_start_transaction();
}

when translating mov %bl, %bl:
{
  ...
  ...
  gen_op_commit_transaction(stored_eip);
  gen_eob(s);  // Stop translation to force guest state updating
}

op_commit_transaction should look like:
{
  if ( helper_CommitTransaction() ) // helper should return !=0 on error
     EIP = PARAM1;
}

Regards,
Eduardo

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

Re: [Qemu-devel] Re: Detecting an assembly instruction in QEMU

[Atif Hashmi]

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

HI Eduardo,

Thanks for you reply. I have update target-i386/translate.c as follows

if(modrm==0xC0)
    {
        stored_eip = pc_start - s->cs_base;
        gen_op_movl_AL_AL();
    }
    else if(modrm==0xDB)
    {
        gen_op_movl_BL_BL(stored_eip);
        gen_eob(s);
    }

target-i386/op.c contains the following.
void OPPROTO op_movl_AL_AL()
{
    helper_StartTransaction();
}
void OPPROTO op_movl_BL_BL()
{
    if(helper_CommitTransaction())
    {
        EIP = PARAM1;
    }
}

and helper.c looks like
void helper_StartTransaction()
{
    printf("StartTransaction Called\n");
}

unsigned char helper_CommitTransaction()
{
    static int i=0;
    printf("CommitTransaction Called\n");
    return 1;
}

Essentially, if we have a program like

int main()
{
       __asm_volatile("mov %al %al"); //is detected in translation.c and
helper_StartTransaction is called
       printf("middle");
      __asm_volatile("mov %bl %bl"); //is detected in translation.c and
helper_CommitTransaction is called
}

We should continuously print "middle" on the QEMU screen while
"StartTransaction Called" and "End Transaction Called" for infinite amount
of time.

But I get the following behaviour.
On QEMU screen, "middle" is printed once, and I get the following on the
xterm
StartTransaction Called
CommitTransaction Called
StartTransaction Called

After that I get the QEMU prompt back and the program finishes. I still have
not been able to figure it out why after calling helper_StartTransaction()
for the seconds time the program does not continue? Is their anything else
that we have not considered.

I will really appreciate your help.

Regards,
Atif


On 4/17/07, Eduardo Felipe <edusaper@gmail.com> wrote:
>
> Hi
>
> 2007/4/17, Atif Hashmi <atifhashmi@gmail.com>:
> >
> >
> > But this prints "Transaction restart" once and then the program
> > finishes. This means that commit transaction is not called the second time.
> > Could you please tell me what am I doing wrong?
>
>
> Helper functions are outside the translated opcode stream and are invoked
> by call/ret:
>
> .------.
> |      |
> |   ---+-->  helper_StartTransaction()
> |   <--+-------------------/
> |      |
> |      |
> |   ---+-->  helper_CommitTransaction()
> |   <--+-------------------/
> |      |
> '------'
>
> When you longjmp from helper_CommitTransaction to helper_StartTransaction
> it's probable that you return back to the point where
> helper_CommitTransaction should have returned to, as it is the last address
> stored in the stack.
>
> Anyway, guest code between the start and the end of the transaction should
> not be rerun without updating guest machine state (eip, flags, etc.).
>
> You should better forget about using setjmp/longjmp. Maybe something like
> this could do the trick:
>
> when translating mov %al,%al:
> {
>   ...
>   ...
>   store the address (eip) of mov %al,%al instruction somewhere
>   gen_op_start_transaction();
> }
>
> when translating mov %bl, %bl:
> {
>   ...
>   ...
>   gen_op_commit_transaction(stored_eip);
>   gen_eob(s);  // Stop translation to force guest state updating
> }
>
> op_commit_transaction should look like:
> {
>   if ( helper_CommitTransaction() ) // helper should return !=0 on error
>      EIP = PARAM1;
> }
>
> Regards,
> Eduardo
>

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

Re: [Qemu-devel] Re: Detecting an assembly instruction in QEMU

[Eduardo Felipe]

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

Hi Atif,

Your code seems quite ok to me. Just try including stored_eip inside the
DisasContext, otherwise you'll lose its value between calls to disas_insn
function.

Also make sure that the instructions you are using as markers are not
executed elsewhere, as your compiler could generate them inside regular code
or they could already exist in your OS.

Regards,
Eduardo

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

Re: [Qemu-devel] Re: Detecting an assembly instruction in QEMU

[Atif Hashmi]

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

Hi Eduardo,

I have finished implementing the implementing the roll-back functionality
for transactional memory. There is one thing that I wanted to ask you. In
order to roll-back, I need to log all the memory references. So that in that
case when a transaction fails and roll-back occurs, memory state can also be
rolled back.

I will really apprecaite if you could direct me to the piece of code in QEMU
for i386, where I can intercept the memory references.

Thanks,
Atif

On 4/22/07, Eduardo Felipe <edusaper@gmail.com> wrote:
>
> Hi Atif,
>
> Your code seems quite ok to me. Just try including stored_eip inside the
> DisasContext, otherwise you'll lose its value between calls to disas_insn
> function.
>
> Also make sure that the instructions you are using as markers are not
> executed elsewhere, as your compiler could generate them inside regular code
> or they could already exist in your OS.
>
> Regards,
> Eduardo
>
>

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

Re: [Qemu-devel] Re: Detecting an assembly instruction in QEMU

[Eduardo Felipe]

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

Hi,

You have a description of memory access instruction format in cpu-all.h,
under
/* CPU memory access without any memory or io remapping */

These instructions are defined in softmmu_header.h. If you don't care too
much about performance it will be easier to modify the code written in C
(undef ASM_SOFTMMU in op.c).

Regards,
Eduardo

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

Re: [Qemu-devel] Re: Detecting an assembly instruction in QEMU

[Atif Hashmi]

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

Hi Eduardo,

Thanks for pointing me to the file. Could you please clarify one more thing.

Instructions like addl %ebx, (%eax) are also considered to be assembly
instructions. Do these type of instructions also refer to the functions that
you mentioned.

Thanks,
Atif

On 4/24/07, Eduardo Felipe <edusaper@gmail.com> wrote:
>
> Hi,
>
> You have a description of memory access instruction format in cpu-all.h,
> under
> /* CPU memory access without any memory or io remapping */
>
> These instructions are defined in softmmu_header.h. If you don't care too
> much about performance it will be easier to modify the code written in C
> (undef ASM_SOFTMMU in op.c).
>
> Regards,
> Eduardo

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

Re: [Qemu-devel] Re: Detecting an assembly instruction in QEMU

[Atif Hashmi]

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

Hi Eduardo,

Thanks for pointing me to the file. Could you please clarify one more thing.

Instructions like addl %ebx, (%eax) are also considered to be memory
refernce instructions. Do these type of instructions also refer to the
functions that you mentioned.

Secondly, what is the purpose of undef ASM_SOFTMMU

Thanks,
Atif

On 4/25/07, Atif Hashmi <atifhashmi@gmail.com> wrote:
>
> Hi Eduardo,
>
> Thanks for pointing me to the file. Could you please clarify one more
> thing.
>
> Instructions like addl %ebx, (%eax) are also considered to be assembly
> instructions. Do these type of instructions also refer to the functions that
> you mentioned.
>
> Thanks,
> Atif
>
> On 4/24/07, Eduardo Felipe <edusaper@gmail.com> wrote:
> >
> > Hi,
> >
> > You have a description of memory access instruction format in cpu-all.h,
> > under
> > /* CPU memory access without any memory or io remapping */
> >
> > These instructions are defined in softmmu_header.h. If you don't care
> > too much about performance it will be easier to modify the code written in C
> > (undef ASM_SOFTMMU in op.c).
> >
> > Regards,
> > Eduardo
>
>
>

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

Re: [Qemu-devel] Re: Detecting an assembly instruction in QEMU

[Eduardo Felipe]

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

2007/4/25, Atif Hashmi <atifhashmi@gmail.com>:
>
> Instructions like addl %ebx, (%eax) are also considered to be memory
> refernce instructions. Do these type of instructions also refer to the
> functions that you mentioned.


No. You are using __asm_volatile("mov %al %al") to mark the start of your
transaction and __asm_volatile("mov %bl %bl") to mark the end. What I meant
is that your compiler could generate mov %al,%al or mov %bl,%bl in any other
place for whatever reason when it compiles C code. Also your guest OS or any
other program running in it can use these two instructions too. Both cases
would affect in what you intend to do.

Secondly, what is the purpose of undef ASM_SOFTMMU


If ASM_SOFTMMU is defined, pure assembly memory access routines are used
(faster). If it is not defined, alternative C routines are used, which are
slower but easier to modify.

Regards,
Eduardo

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

Re: [Qemu-devel] Re: Detecting an assembly instruction in QEMU

[Atif Hashmi]

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

Hi Eduardo,

I think I could not explain my question regarding "addl %ebx, (%eax)". What
I wanted to ask was that this instruction also accesses the memory and I
also need to intercept it within a transaction. Incase of "addl %ebx,
(%eax)", Are the functions under "/* CPU memory access without any memory or
io remapping */" called in case of this instruction.

Secondly, there is a function in "exec.c" called "cpu_physical_memory_rw".
Is it easier to hack into this fuction to intercept the memory references.

Thanks,
Atif

On 4/26/07, Eduardo Felipe <edusaper@gmail.com> wrote:
>
>
>
> 2007/4/25, Atif Hashmi <atifhashmi@gmail.com>:
> >
> > Instructions like addl %ebx, (%eax) are also considered to be memory
> > refernce instructions. Do these type of instructions also refer to the
> > functions that you mentioned.
>
>
> No. You are using __asm_volatile("mov %al %al") to mark the start of your
> transaction and __asm_volatile("mov %bl %bl") to mark the end. What I
> meant is that your compiler could generate mov %al,%al or mov %bl,%bl in any
> other place for whatever reason when it compiles C code. Also your guest OS
> or any other program running in it can use these two instructions too. Both
> cases would affect in what you intend to do.
>
> Secondly, what is the purpose of undef ASM_SOFTMMU
>
>
> If ASM_SOFTMMU is defined, pure assembly memory access routines are used
> (faster). If it is not defined, alternative C routines are used, which are
> slower but easier to modify.
>
> Regards,
> Eduardo
>
>
>
>

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

Re: [Qemu-devel] Re: Detecting an assembly instruction in QEMU

[Eduardo Felipe]

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

>
>
> I think I could not explain my question regarding "addl %ebx, (%eax)".
> What I wanted to ask was that this instruction also accesses the memory and
> I also need to intercept it within a transaction. Incase of "addl %ebx,
> (%eax)", Are the functions under "/* CPU memory access without any memory or
> io remapping */" called in case of this instruction.


Yes. Just look how the instruction is translated into opcodes and you'll see
how it works. You can use the -d switch for this.

Secondly, there is a function in "exec.c" called "cpu_physical_memory_rw".
> Is it easier to hack into this fuction to intercept the memory references.


That function is used by emulated hardware devices to interact with memory (
e.g. DMA to write and read memory chunks). Translated guest code does not
use it.

Regards,
Eduardo

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

Re: [Qemu-devel] Re: Detecting an assembly instruction in QEMU

[Atif Hashmi]

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

Hi Eduardo,

Is it possible to identify context switches inside QEMU. In order to support
transactional memory in QEMU, we have added

target_ulong tm_abort_eip;
int inTransaction;

to CPUX86State structure.

tm_abort_eip is the EIP to jump to when a transaction fails i.e. start of
the Transactional Block while inTransaction tells us whether a transaction
has started so that we can log the memory references. As far as I
understand, env variable will be modified at a context switch. At a context
switch, we need to update tm_abort_eip as well as inTransaction based on the
status of the new thread being loaded. We can store these two variables
inside DisasContext which I believe is unique for each translated block. But
when and where should we modify the env variable so that for each thread it
contains the correct values for tm_abort_eip and inTransaction.

I will appreciate your help.

Thanks,
Atif

On 4/27/07, Eduardo Felipe <edusaper@gmail.com> wrote:
>
>
> > I think I could not explain my question regarding "addl %ebx, (%eax)".
> > What I wanted to ask was that this instruction also accesses the memory and
> > I also need to intercept it within a transaction. Incase of "addl %ebx,
> > (%eax)", Are the functions under "/* CPU memory access without any memory or
> > io remapping */" called in case of this instruction.
>
>
> Yes. Just look how the instruction is translated into opcodes and you'll
> see how it works. You can use the -d switch for this.
>
> Secondly, there is a function in "exec.c" called "cpu_physical_memory_rw".
> > Is it easier to hack into this fuction to intercept the memory references.
>
>
> That function is used by emulated hardware devices to interact with memory
> ( e.g. DMA to write and read memory chunks). Translated guest code does
> not use it.
>
> Regards,
> Eduardo
>
>

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

Re: [Qemu-devel] Re: Detecting an assembly instruction in QEMU

[Thiemo Seufer]

Atif Hashmi wrote:
> Hi Eduardo,
> 
> Thanks a lot for your help. I really appreciate it. I have added the
> functionality that I wanted.

Just in case it might help somebody reading this list, I use the appended
patch to detect a special instruction pattern as pass/fail condition and
shut down qemu with the appropriate message.


Thiemo


Index: qemu-cvs/target-mips/exec.h
===================================================================
--- qemu-cvs.orig/target-mips/exec.h
+++ qemu-cvs/target-mips/exec.h
@@ -140,6 +140,9 @@
 uint64_t do_sdr_kernel (uint64_t);
 #endif
 #endif
+void do_avp_ok (void);
+void do_avp_fail (void);
+
 void do_pmon (int function);
 
 void dump_sc (void);
Index: qemu-cvs/target-mips/op.c
===================================================================
--- qemu-cvs.orig/target-mips/op.c
+++ qemu-cvs/target-mips/op.c
@@ -954,6 +954,16 @@
 OP_COND(lez, (int32_t)T0 <= 0);
 OP_COND(ltz, (int32_t)T0 < 0);
 
+//
+void op_avp_ok (void) {
+    CALL_FROM_TB0(do_avp_ok);
+    RETURN();
+}
+void op_avp_fail (void) {
+    CALL_FROM_TB0(do_avp_fail);
+    RETURN();
+}
+
 /* Branches */
 //#undef USE_DIRECT_JUMP
 
Index: qemu-cvs/target-mips/op_helper.c
===================================================================
--- qemu-cvs.orig/target-mips/op_helper.c
+++ qemu-cvs/target-mips/op_helper.c
@@ -535,6 +535,18 @@
         fputs("\n", logfile);
 }
 
+void do_avp_ok (void)
+{
+    puts("ok");
+    qemu_system_shutdown_request();
+}
+
+void do_avp_fail (void)
+{
+    puts("fail");
+    qemu_system_shutdown_request();
+}
+
 void do_pmon (int function)
 {
     function /= 2;
Index: qemu-cvs/target-mips/translate.c
===================================================================
--- qemu-cvs.orig/target-mips/translate.c
+++ qemu-cvs/target-mips/translate.c
@@ -881,6 +881,14 @@
     uint32_t uimm;
     const char *opn = "unk";
 
+if (opc == OPC_SLTIU && rs == 0 && rt == 0 && (((uint16_t)imm == 0xabc2) | ((uint16_t)imm == 0xabc1))) {
+    if ((uint16_t)imm == 0xabc2)
+        gen_op_avp_ok();
+    else
+        gen_op_avp_fail();
+    ctx->bstate = BS_STOP;
+    return;
+}
     if (rt == 0 && opc != OPC_ADDI && opc != OPC_DADDI) {
         /* if no destination, treat it as a NOP 
          * For addi, we must generate the overflow exception when needed.