Re: [Qemu-devel] [PATCH 01/11] S/390 CPU fake emulation

[Alexander Graf]

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