From: Daniel Henrique Barboza <danielhb413@gmail.com>
To: "Leandro Lupori" <leandro.lupori@eldorado.org.br>,
"Cédric Le Goater" <clg@kaod.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>
Cc: "groug@kaod.org" <groug@kaod.org>,
"david@gibson.dropbear.id.au" <david@gibson.dropbear.id.au>
Subject: Re: [PATCH] target/ppc: fix Hash64 MMU update of PTE bit R
Date: Wed, 24 Nov 2021 16:42:23 -0300 [thread overview]
Message-ID: <1d71936e-0ede-811d-fa72-ca70dcbae068@gmail.com> (raw)
In-Reply-To: <CP2PR80MB35865D04C82D81F7BCBA351CC6619@CP2PR80MB3586.lamprd80.prod.outlook.com>
On 11/24/21 16:17, Leandro Lupori wrote:
>
>
>
> On 11/24/21 14:40, Daniel Henrique Barboza wrote:
> >
> >
> > On 11/24/21 09:00, Leandro Lupori wrote:
> >> When updating the R bit of a PTE, the Hash64 MMU was using a wrong byte
> >> offset, causing the first byte of the adjacent PTE to be corrupted.
> >> This caused a panic when booting FreeBSD, using the Hash MMU.
>
> I wonder how we never hit this issue before. Are you testing PowerNV
> and/or pSeries ?
>
> Could you share a FreeBDS image with us ?
>
> I've hit this issue while testing PowerNV. With pSeries it doesn't happen.
>
> It can be reproduced by trying to boot this iso: https://download.freebsd.org/ftp/snapshots/powerpc/powerpc64/ISO-IMAGES/14.0/FreeBSD-14.0-CURRENT-powerpc-powerpc64-20211028-4827bf76bce-250301-disc1.iso.xz
>
> It is easier to reproduce it using power8/powernv8.
>
>
> > If you add a "Fixes:" tag with the commit that introduced the code you're
> > fixing, we can push it right away as a bug fix in 6.2 (assuming it doesn't
> > break anything else, of course).
> >
> > The commit to be fixed in the case seems to be a2dd4e83e76b ("ppc/hash64:
> > Rework R and C bit updates")
>
> Indeed.
>
> Right.
>
> > One more comment below:
> >
> >>
> >> Signed-off-by: Leandro Lupori <leandro.lupori@eldorado.org.br>
> >> ---
> >> target/ppc/mmu-hash64.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/target/ppc/mmu-hash64.c b/target/ppc/mmu-hash64.c
> >> index 19832c4b46..f165ac691a 100644
> >> --- a/target/ppc/mmu-hash64.c
> >> +++ b/target/ppc/mmu-hash64.c
> >> @@ -786,7 +786,7 @@ static void ppc_hash64_set_dsi(CPUState *cs, int mmu_idx, uint64_t dar, uint64_t
> >> static void ppc_hash64_set_r(PowerPCCPU *cpu, hwaddr ptex, uint64_t pte1)
> >> {
> >> - hwaddr base, offset = ptex * HASH_PTE_SIZE_64 + 16;
> >> + hwaddr base, offset = ptex * HASH_PTE_SIZE_64 + 14;
> >
> > Instead of adding a '14' you should add a new #define in mmu-hash64.h with this
> > value, something like "HPTE64_R_R_SHIFT". This will avoid hardcoding literals
> > around the code and forcing us to go to the ISA every time we wonder what's
> > an apparently random number represents. There's also a "HPTE64_R_R" defined
> > there but I'm not sure if it's usable here, so feel free to create a new
> > macro if needed.
> >
> > In that note, the original commit that added this code also added a lot of
> > hardcoded "15" values for the C bit update in spapr_hpte_set_c() and
> > ppc_hash64_set_c(), and a "14" value like you're changing here in spapr_hpte_set_r().
> > If you're feeling generous I believe that another patch replacing these hardcoded values
> > with bit shift macros is warranted as well.
>
> What about creating HPTE64_R_R_BYTEand HPTE64_R_C_BYTE, with the values 14 and 15, respectively,
> to make it clear that these are byte offsets within a PTE?
Looks good to me.
Daniel
>
> May be for 7.0 though ?
>
> Thanks,
>
> C.
>
next prev parent reply other threads:[~2021-11-24 20:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-24 12:00 [PATCH] target/ppc: fix Hash64 MMU update of PTE bit R Leandro Lupori
2021-11-24 13:40 ` Daniel Henrique Barboza
2021-11-24 18:42 ` Cédric Le Goater
2021-11-24 19:02 ` Daniel Henrique Barboza
2021-11-24 19:17 ` Leandro Lupori
2021-11-24 19:42 ` Daniel Henrique Barboza [this message]
2021-11-24 20:09 ` Cédric Le Goater
2021-11-24 19:52 ` Cédric Le Goater
2021-11-24 21:12 ` Leandro Lupori
2021-11-25 3:03 ` David Gibson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1d71936e-0ede-811d-fa72-ca70dcbae068@gmail.com \
--to=danielhb413@gmail.com \
--cc=clg@kaod.org \
--cc=david@gibson.dropbear.id.au \
--cc=groug@kaod.org \
--cc=leandro.lupori@eldorado.org.br \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).