From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47065) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WTXuG-0003KI-Hk for qemu-devel@nongnu.org; Fri, 28 Mar 2014 10:37:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WTXuA-00018t-K0 for qemu-devel@nongnu.org; Fri, 28 Mar 2014 10:37:16 -0400 Message-ID: <533588FC.70807@gmail.com> Date: Fri, 28 Mar 2014 09:36:44 -0500 From: Tom Musta MIME-Version: 1.0 References: <20140328091659.399643e7@oc7435384737.ibm.com> <6CFA60A9-841A-401E-8A64-B3290F19A54D@suse.de> <20140328130233.2b6e8a3e@oc7435384737.ibm.com> In-Reply-To: <20140328130233.2b6e8a3e@oc7435384737.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-ppc] target-ppc: Problem with mtmsr emulation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Thomas Huth , Alexander Graf Cc: "qemu-ppc@nongnu.org" , "qemu-devel@nongnu.org" On 3/28/2014 7:02 AM, Thomas Huth wrote: > On Fri, 28 Mar 2014 18:25:02 +0800 > Alexander Graf wrote: > >> >> >>> Am 28.03.2014 um 16:16 schrieb Thomas Huth : >>> >>> An easy way to fix this for Book III-S is to change the mask to >>> 0x001EF801 (just like the mask for mtmsrd), but I am afraid that this >>> would break the Book III-E variant of mtmsr, since the embedded version >>> does not have this bit defined. Any suggestions how to fix this problem >>> in a proper way? >> >> Please check in the older isa versions whether that bit is declared reserved. >> >> If it is, we need to make sure we only match it on newer ISA conformance. > > The oldest ISA version that I've found (version 2.01, from 2003) already > contains the L bit, so I assume it's always been there. So it's likely > just a Book III-S vs. Book III-E issue. > The L bit was not part of the original PowerPC ISA. I checked both my 604 manual ((C) 1993) and the May, Silha, Simpson, Warren book ((C) 1994) ... neither contains the L bit. So the *actual* delineation is not as simple as Book III-S vs. Book III-E. I suspect the change was introduced in the mid-2000's. To make matters worse, the change was incompatible with the previous versions of the architecture -- The L=1 case is the old behavior (copy source register bits verbatim, execution synchronizing) whereas L=0 is the new behavior (force external interrupts and virtual address translation in user-state, context synchronizing). And, the L=1 case on Book-IIIS is more like the L=0 case in Book-IIIE. Also, I do not (yet) see the actual implementation of the Book-IIIS L=0 behavior in the QEMU code. This bug is probably masked by the fact that folks who use mtmsr probably know what they are doing -- i.e. who would try to enable user-mode and not enabled address translation? Egads, what a mess. I agree with Alex that a flags based approach could be used to support the L bit for Book III-S models and to ignore the L bit for Book III-E models. The question is which flag(s) can we use? Let me see if I can find out.