Re: [Qemu-devel] Get only TCG code without execution

[Peter Maydell]

On 20 January 2012 06:12, 陳韋任 <address@hidden> wrote:
>  Out of curiosity. What's ARM memory model? From the Wikipedia [1], it seems
> ARMv7 has the same memory model as IA64.

The ARM memory model is the set of semantics for memory
accesses as defined in the ARM Architecture Reference
Manual (covering not just reordering but also exclusive
accesses, alignment, barriers, etc). The manual devotes
50 pages to it so I'm not about to try to summarise it here :-)

> What's load/store exclusive implementation?

How we implement the ARM instructions LDREX/STREX/LDREXD/STREXD/etc.
These have documented (complicated!) semantics which our
implementation doesn't provide.

> And as a general emulator, QEMU shouldn't implement any
> architecture-specific memory model, right?

Wrong, at least in theory. Ideally QEMU should implement exactly
the semantics required by the guest architecture memory model
(it's allowed to be stricter than the architecture requires, of
course), in the same way it should implement the semantics required
by the guest architecture instruction set. A guest binary for ARM
can rely on the memory ordering constraints imposed by the memory
model just as much as it can rely on the fact that the ADD instruction
adds two registers together. In practice, of course (a) this is an
enormous amount of work and also slows the emulator down drastically
and (b) guest binaries don't actually rely that much on the memory
model. And the fairly strict memory model provided by x86 means that
for x86 hosts we actually get most of the important bits of the guest
memory model right anyway.

> What comes into my mind is QEMU only need to follow guest memory
> operations when translates guest binary to TCG ops. When translate
> TCG ops to host binary, it also has to be careful not to mess up
> the memory ordering.

This might be doable if TCG provided a set of ops which allowed
you to implement the guest memory model; it doesn't. If we ever
move to emulating guest SMP in multiple host threads this will
become more important, I suspect.

>From a pragmatic "we just want to run guests" point of view, what
QEMU does now is entirely sufficient; I'm just saying that for
a strictly correct emulation of the guest architecture we're a
bit lacking.

-- PMM