From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38293) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKgmc-0004uh-66 for qemu-devel@nongnu.org; Wed, 06 Jul 2016 02:58:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bKgmX-0002FZ-4e for qemu-devel@nongnu.org; Wed, 06 Jul 2016 02:58:05 -0400 Received: from 12.mo5.mail-out.ovh.net ([46.105.39.65]:58729) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKgmW-0002Ev-UV for qemu-devel@nongnu.org; Wed, 06 Jul 2016 02:58:01 -0400 Received: from player794.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo5.mail-out.ovh.net (Postfix) with ESMTP id E6CE7100C0DD for ; Wed, 6 Jul 2016 08:57:59 +0200 (CEST) References: <1465267828-10326-1-git-send-email-benh@kernel.crashing.org> <1465267828-10326-8-git-send-email-benh@kernel.crashing.org> <66622434-90c8-0d15-f140-2ca1eaa8473d@kaod.org> <1467756609.13965.78.camel@kernel.crashing.org> From: =?UTF-8?Q?C=c3=a9dric_Le_Goater?= Message-ID: <3625f797-2c3b-16b7-e6ee-e6f8baeeb178@kaod.org> Date: Wed, 6 Jul 2016 08:57:47 +0200 MIME-Version: 1.0 In-Reply-To: <1467756609.13965.78.camel@kernel.crashing.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 8/9] ppc: Add missing slbfee. instruction on ppc64 BookS processors List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Herrenschmidt , qemu-ppc@nongnu.org Cc: qemu-devel@nongnu.org, David Gibson On 07/06/2016 12:10 AM, Benjamin Herrenschmidt wrote: > On Tue, 2016-07-05 at 19:23 +0200, C=C3=A9dric Le Goater wrote: >> >> >> So, I was trying today to reconciliate the powernv patchset with=20 >> the current HEAD of qemu when I bumped into the old version of this=20 >> patch. I checked the specs and when no slb are found, rt should=20 >> just be 0. The machine check is only generated when multiple >> matching=20 >> entries are found. So the above probably needs a fix, at least for=20 >> the NULL case ?=20 >=20 > Yes the old patch was broken but I wrote (and already merged) a better > one since then. Check upstream qemu :-) Yes much better :) I saw that when trying to apply the original powernv=20 patchset on top of current qemu. =20 > The -1 result is now handled in the JITed code to do the right thing > (well, afaik). well, no. It should be a 0 when the slb is not found, and thus no=20 machine check. That is how I understand :=20 The SLB is searched for an entry that matches the effective address specified by register RB. The search is performed as if it were being performed for purposes of address translation. That is, in order for a given entry to satisfy the search, the entry must be valid (V=3D1), (RB)0:63-s must equal SLBE[ESID0:63-s] (where 2s is the segment size selected by the B field in the entry), and RB39 must be equal to SLBTA. If exactly one matching entry is found, the contents of the B, VSID, Ks, Kp, N, L, C, TA, and LP fields of the entry are placed into register RT. If no matching entry is found, register RT is set to 0. If more than one matching entry is found, either one of the matching entries is used, as if it were the only matching entry, or a Machine Check occurs. If a Machine Check occurs, register RT, CR Field 0, and, in tags active mode, the FXCC are set to undefined values, and the description below of how this register and these fields are set does not apply. but do we care that much in qemu ? May be the machine check is=20 better to have. Cheers, C.