> > I was not talking about semantics of individual instructions but semantics > > of the whole multi-threaded program. Multi-threaded programs can lead to > > several different (most of which are unintended) states of the CPU. What > > states are possible is described in a mathematically rigorous definition of > > the ARM memory model. My task is to implement this memory model over TCG ops > > and then compare the results on several different (multi-threaded) litmus > > tests with the implementation of the memory model over ARM instructions. > > Some points to note: > * The current QEMU code has some known race conditions which can cause > crashes/hangs in heavily threaded programs in linux-user mode; see eg > https://bugs.launchpad.net/qemu/+bug/668799 > * We don't really make a serious attempt at implementing the ARM memory > model in QEMU; our load/store exclusive implementation is pretty hopeless, > for instance > * In linux-user mode we basically just pass loads/stores/etc through as > host-cpu loads/stores, so you get whatever the host's memory model semantics > are, not what the guest CPU is supposed to do > * a combination of the above plus the fact we don't implement caches in > system emulation mode means that our implementation of all the barrier > insns is a simple no-op; you'll never see barriers at the TCG op level
What's load/store exclusive implementation? And as a general emulator, QEMU shouldn't implement any architecture-specific memory model, right? 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. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
