On 20 January 2012 06:12, 陳韋任 <che...@iis.sinica.edu.tw> 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