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

[Blue Swirl <blauwirbel@gmail.com>]

2009/12/1 Carsten Otte <carsteno@de.ibm.com>:
> 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:

The translation block (TB) refers to a block of host instructions,
translated from some block of target instructions under some
assumptions. The assumptions used when translating (for example, user
vs supervisor mode in the CPU state) are recorded to TB flags. If the
CPU state changes, the old TBs with different flags will not be used
and new TBs will be generated.

> 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

Actually Sparc64 address spaces and ASIs are very similar. There are
nucleus, primary and secondary address spaces (not fully implemented
yet in QEMU). Instructions can encode the ASI or %asi register can be
used. Some ASIs are restricted for supervisor or hypervisor modes.
Sparc32 ASIs are simpler (physical address space extension to 36 bits,
basically) and for supervisor only.

For S/390, I think the TB flags do not need to contain the address
space control registers if the generated instructions fetch the state
from CPU state and do not rely on translation time information. If the
address spaces do not change very often, it may alternatively be
possible to rely on the CPU state during translation, but then it must
be ensured that all generated TBs are always flushed when the
registers change.