On 26 March 2015 at 21:24, Patrick wrote:
> "That affects the fine detail of exactly how we translate the guest code..."
>
> I see that the list of x86 cpus includes Nehalem, Westmere, Penryn, and many
> others. I was somewhat interested in what QEMU is doing differently when
> emulating, for exam
"That affects the fine detail of exactly how we translate the guest code..."
I see that the list of x86 cpus includes Nehalem, Westmere, Penryn, and
many others. I was somewhat interested in what QEMU is doing differently
when emulating, for example, a Nehalem versus a Westmere. From looking at
ta
On 26 March 2015 at 20:44, Patrick wrote:
> 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
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
chang
On 26 March 2015 at 19:01, Patrick 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 rewri
Hello,
I am new to QEMU, and I am trying to get a basic understanding of QEMU's
internal operations​​. There are two statements I've come across in the
documentation that I am trying to figure out how they fit together.
At the beginning of section 2 of the "QEMU Internals" page linked from the
QE
