From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MKGlp-0001G2-Rz for qemu-devel@nongnu.org; Fri, 26 Jun 2009 15:07:33 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MKGll-00014q-2W for qemu-devel@nongnu.org; Fri, 26 Jun 2009 15:07:33 -0400 Received: from [199.232.76.173] (port=40579 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MKGlk-00014e-VL for qemu-devel@nongnu.org; Fri, 26 Jun 2009 15:07:29 -0400 Received: from mtaout03-winn.ispmail.ntl.com ([81.103.221.49]:8758) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MKGlk-0003Zs-BR for qemu-devel@nongnu.org; Fri, 26 Jun 2009 15:07:28 -0400 Received: from aamtaout04-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20090626190717.SOFU5579.mtaout03-winn.ispmail.ntl.com@aamtaout04-winn.ispmail.ntl.com> for ; Fri, 26 Jun 2009 20:07:17 +0100 Received: from miranda.arrow ([213.107.24.213]) by aamtaout04-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20090626190717.RRKY22934.aamtaout04-winn.ispmail.ntl.com@miranda.arrow> for ; Fri, 26 Jun 2009 20:07:17 +0100 Received: from sdb by miranda.arrow with local (Exim 4.63) (envelope-from ) id 1MKGlW-0000CH-Ie for qemu-devel@nongnu.org; Fri, 26 Jun 2009 20:07:14 +0100 Date: Fri, 26 Jun 2009 20:07:14 +0100 From: Stuart Brady Subject: Re: [Qemu-devel] [RFC PATCH] s390x-linux-user Message-ID: <20090626190714.GA464@miranda.arrow> References: <200906261849.43746.uli@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Fri, Jun 26, 2009 at 08:17:42PM +0300, Blue Swirl wrote: > On 6/26/09, Ulrich Hecht wrote: > > There is a very peculiar S/390 instruction called "EXECUTE". What it does > > is to take another instruction stored somewhere in memory, logical-OR > > the second byte of the instruction with the LSB of R0 and then execute > > the result, without changing the instruction in memory or the program > > counter. Any idea how to implement this in QEMU? Currently, I'm > > interpreting the couple of instructions that GCC uses EXECUTE with, but > > in the long run that would amount to implementing a second emulator... > > Maybe something like this: Make a special TB of the EXECUTE > instruction and add LSB of R0 to TB flags for these TBs. Then you can > examine R0, OR and generate code at translation time. The TBs linking > to EXECUTE TB may need to be special too in order to track for R0. Stupid idea, I expect, but would it be possible to handle EXECUTE by 'branching' to the 'instruction stored somewhere in memory', using one bit to hold the state of R0, and another indicate that the TB is a special EXECUTE TB (i.e. only a single instruction should be decoded, the LSB of R0 should be ORed, and code must be generated to return to the 'caller'), and another bit for the state of the LSB of R0? Presumably, SMC handling would safely deal with the memory holding that instruction being written to. (If all variants of S/390 need precise SMC handling, I suppose that shouldn't be a problem?) My only real concern would be that it must not be possible to observe this behaviour. (I.e. an interrupt arriving at the 'wrong' moment or the EXECUTEd instruction faulting must be properly handled.) Also, if S/390 has separate read/execute page bits, would access to the memory location in question still count as 'execution'? I suppose this would also be possible to work around, though... I won't be totally surprised if someone tells me that this would be completely unworkable, but I'd be interested in learning why, if that is indeed the case. :-) Cheers, -- Stuart Brady