[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0e8cf563-345d-4fd4-b0ff-d80e0c7ac29c@roeck-us.net>
Date: Tue, 3 Sep 2024 07:13:20 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Helge Deller <deller@....de>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Richard Henderson <richard.henderson@...aro.org>,
Vlastimil Babka <vbabka@...e.cz>, linux-kernel@...r.kernel.org,
Linux-MM <linux-mm@...ck.org>, linux-parisc@...r.kernel.org,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 6.10 000/809] 6.10.3-rc3 review
On Tue, Sep 03, 2024 at 09:54:19AM +0200, Helge Deller wrote:
> On 8/8/24 20:19, Linus Torvalds wrote:
> > On Thu, 8 Aug 2024 at 10:48, Thomas Gleixner <tglx@...utronix.de> wrote:
> > >
> > > Here is the disassembly from my latest crashing debug kernel which
> > > shifts it up a couple of pages. Add 0x10 or sub 0x20 to make it work.
> >
> > Looks like I was off by an instruction, it's the 28th divide-step (not
> > 29) that does the page crosser:
> >
> > > 4121dffc: 0b 21 04 41 ds r1,r25,r1
> > > 4121e000: 0b bd 07 1d add,c ret1,ret1,ret1
> >
> > but my parisc knowledge is not good enough to even guess at what could go wrong.
> >
> > And I have no actual reason to believe this has *anything* to do with
> > an itlb miss, except for that whole "exact placement seems to matter,
> > and it crosses a page boundary" detail.
>
> Well, you were on the right track :-)
>
> Guenters kernel from
> http://server.roeck-us.net/qemu/parisc64-6.10.3/
> boots nicely on my physical C3700 machine, but crashes with Qemu.
>
> So, it's not some bug in the kernel ITLB miss handler or other
> Linux kernel code.
>
> Instead it's a Qemu bug, which gets triggered by the page
> boundary crossing of:
> 41218ffc: 0b 21 04 41 ds r1,r25,r1
> 41219000: 0b bd 07 1d add,c ret1,ret1,ret1
>
> During the ITLB miss, the carry bits and the PSW-V-bit
> (from the divide step) are saved in the IPSW register and restored
> upon irq return.
>
> During packaging the bits there is a qemu coding bug, where we missed
> to handle the PSW-V-bit as 32-bit value even on a 64-bit CPU.
> The (copy&pasted) patch below fixes the crash for me.
>
Yes, that works for me as well. Thanks a lot for the fix!
Guenter
> Helge
>
> diff --git a/target/hppa/helper.c b/target/hppa/helper.c
> index b79ddd8184..d4b1a3cd5a 100644
> --- a/target/hppa/helper.c
> +++ b/target/hppa/helper.c
> @@ -53,7 +53,7 @@ target_ulong cpu_hppa_get_psw(CPUHPPAState *env)
> }
>
> psw |= env->psw_n * PSW_N;
> - psw |= (env->psw_v < 0) * PSW_V;
> + psw |= ((env->psw_v >> 31) & 1) * PSW_V;
> psw |= env->psw | env->psw_xb;
>
> return psw;
>
Powered by blists - more mailing lists