[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PULL 07/17] ppc: Fix rfi/rfid/hrfi/... emulation

From: Mark Cave-Ayland
Subject: Re: [Qemu-devel] [PULL 07/17] ppc: Fix rfi/rfid/hrfi/... emulation
Date: Mon, 27 Jun 2016 07:43:40 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.1.0

On 27/06/16 05:42, Benjamin Herrenschmidt wrote:

> On Thu, 2016-06-23 at 15:48 +1000, David Gibson wrote:
>> From: Benjamin Herrenschmidt <address@hidden>
>> 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 __cpu_preinit_ppc970 which
> 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.

I know, and I do apologies as the OpenBIOS repository has been in freeze
for a month now trying to transition over to git. I'll send a follow-up
email ASAP.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]