Hi, Peter Please check my comments, Thank you very much!! -----邮件原件----- 发件人: Peter Maydell [mailto:peter.mayd...@linaro.org] 发送时间: 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, <erics...@via-alliance.com> 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