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.
