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

[Paul Brook <paul@codesourcery.com>]

> > 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=200
> >30424140649
> 
> 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.

It sounds like there's some confusion between virtual address translation and 
state that effects instruction semantics. The TB flags should include the 
latter. The former isn't particularly well supported in qemu. If you have more 
than a couple of different address spaces (i.e. kernel and userspace) then you 
basically have to flush the TLB every time the current address space changes. 
If the address space an be selected per-instruction then you're pretty much 
screwed.

Paul