From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56342) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bHONt-0003F9-2q for qemu-devel@nongnu.org; Mon, 27 Jun 2016 00:42:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bHONp-0001H4-Ta for qemu-devel@nongnu.org; Mon, 27 Jun 2016 00:42:57 -0400 Message-ID: <1467002528.20278.37.camel@kernel.crashing.org> From: Benjamin Herrenschmidt Date: Mon, 27 Jun 2016 14:42:08 +1000 In-Reply-To: <1466660926-1544-8-git-send-email-david@gibson.dropbear.id.au> References: <1466660926-1544-1-git-send-email-david@gibson.dropbear.id.au> <1466660926-1544-8-git-send-email-david@gibson.dropbear.id.au> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PULL 07/17] ppc: Fix rfi/rfid/hrfi/... emulation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson , peter.maydell@linaro.org Cc: agraf@suse.de, qemu-ppc@nongnu.org, pbonzini@redhat.com, qemu-devel@nongnu.org, =?ISO-8859-1?Q?C=E9dric?= Le Goater , Mark Cave-Ayland On Thu, 2016-06-23 at 15:48 +1000, David Gibson wrote: > From: Benjamin Herrenschmidt >=20 > This reworks emulation of the various "rfi" variants. I removed > some masking bits that I couldn't make sense of, the only bit that > I am aware we should mask here is POW, the CPU's MSR mask should > take care of the rest. See I'd rather we didn't boot at all. I just spent hours trying to figure out why my kernel wouldn't boot in qemu on a mac99 model with 970, weird weird things happening inside the device-tree parsing... Until I figured we were losing the 64-bit mode in the MSR. Why ? Because OpenBIOS isn't bolting the hash entries or SLBs for the entire kernel ! So we are taking some exceptions right during the early assembly, precisely between enable_64b_mode and __mmu_off. Now this is really fishy to begin with, there is code in there that will use SRR0/SRR1 and won't expect a fault of any sort... such as __mmu_off itself. The problem in our case was that OpenBIOS using rfi, it only restores 32-bits of the MSR, so we lose the 64-bit flag. Typically that was happening on the call to=C2=A0__cpu_preinit_ppc970 whi= ch happens to reside far enough away that it needs a new translation. I wonder if prom_init should "touch" the entire kernel for safety, but in any case, OpenBIOS need that fix urgently. Cheers, Ben.