On 01.12.2009, at 10:46, Carsten Otte wrote: > Alexander Graf wrote: >>> I don't know what psw.mask represent, but it may be wrong. It should be >>> a way to identify which TB can be reused, that is they have been >>> generated in the same CPU mode. >> psw.mask is rougly the same as RFLAGS, cr0 and cr4 on x86_64 combined. So >> IMHO it looked like a pretty good identifier for TB uniqueness. > I am not familar with qemu at all here, therefore the following explanation > may not fit here. I assume the translation block refers to guest virtual to > guest physical memory translations. In that case this is not the right > indicator on it's own. The right indicator which translation the cpu would do > would be pretty complex: > Our cpu keeps multiple seperate address spaces open at the same time (similar > to x86 with a bunch of cr0s), defined by address space control elements in > various control registers. Linux uses primary, secondary and home space to > address user space and kernel space. The third one is user space once again > for exec-type access (to implement stack execute protection). PSW.mask > selects which one is to be used for address translation by _default_. Even > worse, the cpu may load instructions and data from different adddress spaces > (secondary space mdoe). Yet more worse some instructions use "access register > mode" where a general purpose register points to yet another address space. A > detailed documentation can be found here: > http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/dz9zr002/3.0?DT=20030424140649 > > That said, I think it's best to keep out softmmu for now. It's not needed for > kvm operation and very complex to do right.
Ah ok, so we're missing the asce register information for softmmu uniqueness. Well - I guess I should put a comment there that tells anyone who feels like implementing a softmmu target that this is a pitfall. Alex