From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NFqOr-0005cn-Ab for qemu-devel@nongnu.org; Wed, 02 Dec 2009 09:41:49 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NFqOk-0005bG-Qm for qemu-devel@nongnu.org; Wed, 02 Dec 2009 09:41:47 -0500 Received: from [199.232.76.173] (port=53733 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NFqOi-0005ay-FA for qemu-devel@nongnu.org; Wed, 02 Dec 2009 09:41:41 -0500 Received: from mx20.gnu.org ([199.232.41.8]:57645) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NFqOh-0000iL-Iu for qemu-devel@nongnu.org; Wed, 02 Dec 2009 09:41:40 -0500 Received: from mail.codesourcery.com ([38.113.113.100]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NFqOf-00077X-DZ for qemu-devel@nongnu.org; Wed, 02 Dec 2009 09:41:37 -0500 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH 01/11] S/390 CPU fake emulation Date: Wed, 2 Dec 2009 14:41:32 +0000 References: <1259241800-2810-1-git-send-email-agraf@suse.de> <4B14E5DD.9080504@de.ibm.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200912021441.33091.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Blue Swirl , Carsten Otte , Alexander Graf , Aurelien Jarno , Carsten Otte > > 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