Re: [Qemu-discuss] Output many return values of some instruction

[EricSong]

Hi, Peter
    Please check my comments, Thank you very much!!

-----邮件原件-----
发件人: Peter Maydell [mailto:address@hidden 
发送时间: 2014年12月1日 19:41
收件人: Eric Song
抄送: qemu-discuss
主题: Re: Re: Re: [Qemu-discuss] Output many return values of some instruction

On 1 December 2014 at 10:25,  <address@hidden> wrote:
>     Firstly, I tell you about my instruction -- Getsec (opcode is 0f 37), it 
> is about the x86 arch safer mode . I want to emulate it by QEMU.
>     Then, the function of Getsec is so complicated. There are many jmp 
> or je/z opcode in this function. According to QEMU spirit, if jump 
> instruction occurs, it should be jump to next TB. But for me, this is 
> an atomic instruction.

You seem to be confused between:
 * conditions in the Intel architecture manual describing
   how the function performs
 * conditional jumps in x86 guest code
 * conditional jumps in TCG intermediate code
 * jumps between translation blocks

These are not all the same thing.

    My understandings is as followings:
       * According to the Intel arch manual, the conditions is including some 
input parameters like eax/ebx when Getsec is executed. And there are some jumps 
in Getsec implementation.
       * Conditional jumps in x86 guest code is means that opcodes like jmp/je 
and so on. When it is detected , QEMU will close current TB, and start to next 
TB building.
       * Conditional jumps in TCG intermediate code is means that jumps between 
TB.
       * Jumps between translation blocks is same as above.
    There must be some misunderstandings, please correct me!.

> I cannot separate this function to portions. And It is complicated to 
> modify the main sequence of QEMU. If no jump in my function, I think 
> it is simple to add some function in Getsec (in disas_insn()).

Complicated functions can be implemented by calling out to C code in the 
frontend at runtime, as I suggested.
Yes, some instructions are complicated -- in the end they all come down to 
modifying the state of the emulated CPU, and you can do this always by using 
TCG ops or by calling frontend functions.

You don't need to worry about atomicity -- TCG only runs one guest CPU at a 
time, so any sequence of TCG ops within one TCG TB will always execute 
atomically.

That said, given the "leaf" structure intel have used for the getsec 
instruction, you're probably best off just calling a helper function and 
figuring out which leaf op this is at runtime.

   I am very surprised and happy from your suggestion above. Before I checked 
the helper function, but not deeply. You means, the helper function is best for 
leaf op like Cpuid, maybe Getsec also? 
   This is my understanding about Cpuid execution:
       When QEMU detected Cpuid opcode, then generate the helper function to 
some a special place, not to intermediate code buffer. But how to insert this 
opcode into normal opcodes sequence?
   Anyway, when host cpu executes this Cpuid opcode, QEMU will directly call 
the helper function. So this is a runtime function.
       Because these opcodes is specific to X86 host, so they is not translated 
to intermediate code, but running directly, if target and host are all x86 
arch. 
       Is it right ? If so, I think my function can be implemented by the 
helper function as you suggested, I just use c code and embedded assembly code 
for it. Right?


>     Lastly, do our QEMU have a schedule for Getsec implemention?

No, we don't.

-- PMM

Many Thanks
Best wishes
Eric