Re: [Qemu-discuss] Basic Question on QEMU Internals

[Patrick]

Thank you for the response. This makes sense, but I am not seeing how the "cpu" or "machine" command-line arguments fit into the "flow." It appears that the "cpu" flag is changing the x86 microarchitecture that is being emulated. If the x86 code is getting translated to TCG ops, then how does changing the microarchitecture change the flow?

Patrick

On Thu, Mar 26, 2015 at 1:38 PM, Peter Maydell <address@hidden> wrote:

On 26 March 2015 at 19:01, Patrick <address@hidden> wrote:
> Like bochs [3], QEMU emulates an x86 CPU.

This is true but somewhat incomplete -- we also emulate
many other guest CPU types including ARM, MIPS and PPC.

> The whole translation task thus consists of two parts: blocks of target code
> (TBs) being rewritten in TCG ops - a kind of machine-independent
> intermediate notation, and subsequently this notation being compiled for the
> host's architecture by TCG.

This is all correct.

> Since the target code is getting translated to TCG ops, and QEMU is
> emulating an x86 CPU, then wouldn't the TCG ops need to get translated to
> x86 to run on the emulated x86 CPU? Why would TCG ops get compiled into the
> host's architecture?

The flow goes:

 guest CPU instructions -> TCG intermediate code -> host CPU instructions

(and then we execute the host instructions, obviously).

The aim here is to execute the guest instructions, which
we can't typically do since the host is probably a different
CPU architecture. So we transform them (via an intermediate
representation) into host instructions which we can execute.

[The intermediate representation is a common piece of
compiler design which makes implementation simpler:
if we want to support (say) 6 different guest CPU types
and 4 host CPU types, we need only write 6 guest->TCG
translators and 4 TCG->host backends. Without an IR
we would need 6*4 == 24 different translators.]

If this is confusing you might want to look up some
basic introductions to compiler and JIT design.

-- PMM