From: Yu-Chien Peter Lin <peterlin@andestech.com>
To: Alexandre Ghiti <alex@ghiti.fr>
Cc: <paul.walmsley@sifive.com>, <palmer@dabbelt.com>,
<aou@eecs.berkeley.edu>, <david@redhat.com>,
<akpm@linux-foundation.org>, <alexghiti@rivosinc.com>,
<bjorn@rivosinc.com>, <linux-riscv@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <ycliang@andestech.com>
Subject: Re: [PATCH v2 1/3] riscv: Improve PTDUMP to show RSW with non-zero value
Date: Sat, 16 Sep 2023 15:22:51 +0800 [thread overview]
Message-ID: <ZQVXy6I42HJM4XLM@APC323> (raw)
In-Reply-To: <51f5c170-2659-d76a-afbb-632b7a55586c@ghiti.fr>
Hi Alexandre,
On Fri, Sep 15, 2023 at 01:07:04PM +0200, Alexandre Ghiti wrote:
> On 14/09/2023 03:40, Yu Chien Peter Lin wrote:
> > RSW field can be used to encode 2 bits of software defined
> > information, currently PTDUMP only prints RSW when its value
> > is 1 or 3.
> >
> > To fix this issue and enhance the debug experience with PTDUMP,
> > we use _PAGE_SOFT as the RSW mask and redefine _PAGE_SPECIAL to
> > (1 << 8), allow it to print the RSW with any non-zero value,
> > otherwise, it will print an empty string for each row.
> >
> > This patch also removes the val from the struct prot_bits as
> > it is no longer needed.
> >
> > Signed-off-by: Yu Chien Peter Lin <peterlin@andestech.com>
> > ---
> > arch/riscv/include/asm/pgtable-bits.h | 4 +--
> > arch/riscv/mm/ptdump.c | 36 +++++++++++----------------
> > 2 files changed, 17 insertions(+), 23 deletions(-)
> >
> > diff --git a/arch/riscv/include/asm/pgtable-bits.h b/arch/riscv/include/asm/pgtable-bits.h
> > index f896708e8331..99e60fd3eb72 100644
> > --- a/arch/riscv/include/asm/pgtable-bits.h
> > +++ b/arch/riscv/include/asm/pgtable-bits.h
> > @@ -16,9 +16,9 @@
> > #define _PAGE_GLOBAL (1 << 5) /* Global */
> > #define _PAGE_ACCESSED (1 << 6) /* Set by hardware on any access */
> > #define _PAGE_DIRTY (1 << 7) /* Set by hardware on any write */
> > -#define _PAGE_SOFT (1 << 8) /* Reserved for software */
> > +#define _PAGE_SOFT (3 << 8) /* Reserved for software */
> > -#define _PAGE_SPECIAL _PAGE_SOFT
>
>
> That's nit, but maybe you could have introduced a _PAGE_SOFT_1 and
> _PAGE_SOFT_2
>
Thanks for the suggestion, maybe we just add a comment here?
#define _PAGE_SPECIAL (1 << 8) /* RSW: 0x1 */
> > +#define _PAGE_SPECIAL (1 << 8)
>
>
> instead of hardcoding (1<<8) here, but that can be done when we'll use the
> second bit :)
>
> > #define _PAGE_TABLE _PAGE_PRESENT
> > /*
> > diff --git a/arch/riscv/mm/ptdump.c b/arch/riscv/mm/ptdump.c
> > index 20a9f991a6d7..85686652f342 100644
> > --- a/arch/riscv/mm/ptdump.c
> > +++ b/arch/riscv/mm/ptdump.c
> > @@ -129,7 +129,6 @@ static struct ptd_mm_info efi_ptd_info = {
> > /* Page Table Entry */
> > struct prot_bits {
> > u64 mask;
> > - u64 val;
> > const char *set;
> > const char *clear;
> > };
> > @@ -137,47 +136,38 @@ struct prot_bits {
> > static const struct prot_bits pte_bits[] = {
> > {
> > .mask = _PAGE_SOFT,
> > - .val = _PAGE_SOFT,
> > - .set = "RSW",
> > - .clear = " ",
> > + .set = "RSW(%d)",
> > + .clear = " ",
> > }, {
> > .mask = _PAGE_DIRTY,
> > - .val = _PAGE_DIRTY,
> > .set = "D",
> > .clear = ".",
> > }, {
> > .mask = _PAGE_ACCESSED,
> > - .val = _PAGE_ACCESSED,
> > .set = "A",
> > .clear = ".",
> > }, {
> > .mask = _PAGE_GLOBAL,
> > - .val = _PAGE_GLOBAL,
> > .set = "G",
> > .clear = ".",
> > }, {
> > .mask = _PAGE_USER,
> > - .val = _PAGE_USER,
> > .set = "U",
> > .clear = ".",
> > }, {
> > .mask = _PAGE_EXEC,
> > - .val = _PAGE_EXEC,
> > .set = "X",
> > .clear = ".",
> > }, {
> > .mask = _PAGE_WRITE,
> > - .val = _PAGE_WRITE,
> > .set = "W",
> > .clear = ".",
> > }, {
> > .mask = _PAGE_READ,
> > - .val = _PAGE_READ,
> > .set = "R",
> > .clear = ".",
> > }, {
> > .mask = _PAGE_PRESENT,
> > - .val = _PAGE_PRESENT,
> > .set = "V",
> > .clear = ".",
> > }
> > @@ -208,15 +198,19 @@ static void dump_prot(struct pg_state *st)
> > unsigned int i;
> > for (i = 0; i < ARRAY_SIZE(pte_bits); i++) {
> > - const char *s;
> > -
> > - if ((st->current_prot & pte_bits[i].mask) == pte_bits[i].val)
> > - s = pte_bits[i].set;
> > - else
> > - s = pte_bits[i].clear;
> > -
> > - if (s)
> > - pt_dump_seq_printf(st->seq, " %s", s);
> > + char s[7];
> > + unsigned long val;
> > +
> > + val = st->current_prot & pte_bits[i].mask;
> > + if (val) {
> > + if (pte_bits[i].mask == _PAGE_SOFT)
> > + sprintf(s, pte_bits[i].set, val >> 8);
> > + else
> > + sprintf(s, "%s", pte_bits[i].set);
> > + } else
> > + sprintf(s, "%s", pte_bits[i].clear);
> > +
> > + pt_dump_seq_printf(st->seq, " %s", s);
> > }
> > }
>
>
> I don't see any issue in your patch, but just the output is a bit "weird"
> now as the there is a large "hole" between the PTE type and the PTE
> protection bits:
>
> Before:
>
> 0xffffffd800000000-0xffffffd800200000 0x0000000080000000 2M PMD
> D A G . . W R V
>
> After:
>
> 0xffffaf8000000000-0xffffaf8000200000 0x0000000080000000 2M PMD
> . D A G . . W R V
>
> Maybe you could add the PBMT/N bits after the protections bits to void this
> hole?
Agreed, PBMT and RSW fields are not commonly used. How about adding ".."
for 2-bit zero values instead of spaces? hopefully it will look better.
0xffffffc802088000-0xffffffc80208c000 0x0000000000d36000 16K PTE . .. .. D A G . . W R V
0xffffffc802090000-0xffffffc802094000 0x0000000000d4d000 16K PTE . MT(IO) .. D A G . . W R V
0xffffffc802095000-0xffffffc8020b5000 0x0000000100d80000 128K PTE . .. RSW(2) D A G . . W R V
0xffffffc8020b6000-0xffffffc8020d6000 0x0000000100da0000 128K PTE . .. RSW(2) D A G . . W R V
0xffffffc8020d8000-0xffffffc8020dc000 0x0000000000d7b000 16K PTE . .. .. D A G . . W R V
0xffffffc8020e0000-0xffffffc8020e4000 0x0000000000d7f000 16K PTE . .. .. D A G . . W R V
> Anyway, as a heavy user of this kernel page table dump, that's really
> appreciated, thanks :)
Thansk for the review :)
Best regards,
Peter Lin
> Alex
>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Yu-Chien Peter Lin <peterlin@andestech.com>
To: Alexandre Ghiti <alex@ghiti.fr>
Cc: <paul.walmsley@sifive.com>, <palmer@dabbelt.com>,
<aou@eecs.berkeley.edu>, <david@redhat.com>,
<akpm@linux-foundation.org>, <alexghiti@rivosinc.com>,
<bjorn@rivosinc.com>, <linux-riscv@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <ycliang@andestech.com>
Subject: Re: [PATCH v2 1/3] riscv: Improve PTDUMP to show RSW with non-zero value
Date: Sat, 16 Sep 2023 15:22:51 +0800 [thread overview]
Message-ID: <ZQVXy6I42HJM4XLM@APC323> (raw)
In-Reply-To: <51f5c170-2659-d76a-afbb-632b7a55586c@ghiti.fr>
Hi Alexandre,
On Fri, Sep 15, 2023 at 01:07:04PM +0200, Alexandre Ghiti wrote:
> On 14/09/2023 03:40, Yu Chien Peter Lin wrote:
> > RSW field can be used to encode 2 bits of software defined
> > information, currently PTDUMP only prints RSW when its value
> > is 1 or 3.
> >
> > To fix this issue and enhance the debug experience with PTDUMP,
> > we use _PAGE_SOFT as the RSW mask and redefine _PAGE_SPECIAL to
> > (1 << 8), allow it to print the RSW with any non-zero value,
> > otherwise, it will print an empty string for each row.
> >
> > This patch also removes the val from the struct prot_bits as
> > it is no longer needed.
> >
> > Signed-off-by: Yu Chien Peter Lin <peterlin@andestech.com>
> > ---
> > arch/riscv/include/asm/pgtable-bits.h | 4 +--
> > arch/riscv/mm/ptdump.c | 36 +++++++++++----------------
> > 2 files changed, 17 insertions(+), 23 deletions(-)
> >
> > diff --git a/arch/riscv/include/asm/pgtable-bits.h b/arch/riscv/include/asm/pgtable-bits.h
> > index f896708e8331..99e60fd3eb72 100644
> > --- a/arch/riscv/include/asm/pgtable-bits.h
> > +++ b/arch/riscv/include/asm/pgtable-bits.h
> > @@ -16,9 +16,9 @@
> > #define _PAGE_GLOBAL (1 << 5) /* Global */
> > #define _PAGE_ACCESSED (1 << 6) /* Set by hardware on any access */
> > #define _PAGE_DIRTY (1 << 7) /* Set by hardware on any write */
> > -#define _PAGE_SOFT (1 << 8) /* Reserved for software */
> > +#define _PAGE_SOFT (3 << 8) /* Reserved for software */
> > -#define _PAGE_SPECIAL _PAGE_SOFT
>
>
> That's nit, but maybe you could have introduced a _PAGE_SOFT_1 and
> _PAGE_SOFT_2
>
Thanks for the suggestion, maybe we just add a comment here?
#define _PAGE_SPECIAL (1 << 8) /* RSW: 0x1 */
> > +#define _PAGE_SPECIAL (1 << 8)
>
>
> instead of hardcoding (1<<8) here, but that can be done when we'll use the
> second bit :)
>
> > #define _PAGE_TABLE _PAGE_PRESENT
> > /*
> > diff --git a/arch/riscv/mm/ptdump.c b/arch/riscv/mm/ptdump.c
> > index 20a9f991a6d7..85686652f342 100644
> > --- a/arch/riscv/mm/ptdump.c
> > +++ b/arch/riscv/mm/ptdump.c
> > @@ -129,7 +129,6 @@ static struct ptd_mm_info efi_ptd_info = {
> > /* Page Table Entry */
> > struct prot_bits {
> > u64 mask;
> > - u64 val;
> > const char *set;
> > const char *clear;
> > };
> > @@ -137,47 +136,38 @@ struct prot_bits {
> > static const struct prot_bits pte_bits[] = {
> > {
> > .mask = _PAGE_SOFT,
> > - .val = _PAGE_SOFT,
> > - .set = "RSW",
> > - .clear = " ",
> > + .set = "RSW(%d)",
> > + .clear = " ",
> > }, {
> > .mask = _PAGE_DIRTY,
> > - .val = _PAGE_DIRTY,
> > .set = "D",
> > .clear = ".",
> > }, {
> > .mask = _PAGE_ACCESSED,
> > - .val = _PAGE_ACCESSED,
> > .set = "A",
> > .clear = ".",
> > }, {
> > .mask = _PAGE_GLOBAL,
> > - .val = _PAGE_GLOBAL,
> > .set = "G",
> > .clear = ".",
> > }, {
> > .mask = _PAGE_USER,
> > - .val = _PAGE_USER,
> > .set = "U",
> > .clear = ".",
> > }, {
> > .mask = _PAGE_EXEC,
> > - .val = _PAGE_EXEC,
> > .set = "X",
> > .clear = ".",
> > }, {
> > .mask = _PAGE_WRITE,
> > - .val = _PAGE_WRITE,
> > .set = "W",
> > .clear = ".",
> > }, {
> > .mask = _PAGE_READ,
> > - .val = _PAGE_READ,
> > .set = "R",
> > .clear = ".",
> > }, {
> > .mask = _PAGE_PRESENT,
> > - .val = _PAGE_PRESENT,
> > .set = "V",
> > .clear = ".",
> > }
> > @@ -208,15 +198,19 @@ static void dump_prot(struct pg_state *st)
> > unsigned int i;
> > for (i = 0; i < ARRAY_SIZE(pte_bits); i++) {
> > - const char *s;
> > -
> > - if ((st->current_prot & pte_bits[i].mask) == pte_bits[i].val)
> > - s = pte_bits[i].set;
> > - else
> > - s = pte_bits[i].clear;
> > -
> > - if (s)
> > - pt_dump_seq_printf(st->seq, " %s", s);
> > + char s[7];
> > + unsigned long val;
> > +
> > + val = st->current_prot & pte_bits[i].mask;
> > + if (val) {
> > + if (pte_bits[i].mask == _PAGE_SOFT)
> > + sprintf(s, pte_bits[i].set, val >> 8);
> > + else
> > + sprintf(s, "%s", pte_bits[i].set);
> > + } else
> > + sprintf(s, "%s", pte_bits[i].clear);
> > +
> > + pt_dump_seq_printf(st->seq, " %s", s);
> > }
> > }
>
>
> I don't see any issue in your patch, but just the output is a bit "weird"
> now as the there is a large "hole" between the PTE type and the PTE
> protection bits:
>
> Before:
>
> 0xffffffd800000000-0xffffffd800200000 0x0000000080000000 2M PMD
> D A G . . W R V
>
> After:
>
> 0xffffaf8000000000-0xffffaf8000200000 0x0000000080000000 2M PMD
> . D A G . . W R V
>
> Maybe you could add the PBMT/N bits after the protections bits to void this
> hole?
Agreed, PBMT and RSW fields are not commonly used. How about adding ".."
for 2-bit zero values instead of spaces? hopefully it will look better.
0xffffffc802088000-0xffffffc80208c000 0x0000000000d36000 16K PTE . .. .. D A G . . W R V
0xffffffc802090000-0xffffffc802094000 0x0000000000d4d000 16K PTE . MT(IO) .. D A G . . W R V
0xffffffc802095000-0xffffffc8020b5000 0x0000000100d80000 128K PTE . .. RSW(2) D A G . . W R V
0xffffffc8020b6000-0xffffffc8020d6000 0x0000000100da0000 128K PTE . .. RSW(2) D A G . . W R V
0xffffffc8020d8000-0xffffffc8020dc000 0x0000000000d7b000 16K PTE . .. .. D A G . . W R V
0xffffffc8020e0000-0xffffffc8020e4000 0x0000000000d7f000 16K PTE . .. .. D A G . . W R V
> Anyway, as a heavy user of this kernel page table dump, that's really
> appreciated, thanks :)
Thansk for the review :)
Best regards,
Peter Lin
> Alex
>
next prev parent reply other threads:[~2023-09-16 7:23 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-14 1:40 [PATCH v2 1/3] riscv: Improve PTDUMP to show RSW with non-zero value Yu Chien Peter Lin
2023-09-14 1:40 ` Yu Chien Peter Lin
2023-09-14 1:40 ` [PATCH v2 2/3] riscv: Introduce PBMT field to PTDUMP Yu Chien Peter Lin
2023-09-14 1:40 ` Yu Chien Peter Lin
2023-09-14 1:40 ` [PATCH v2 3/3] riscv: Introduce NAPOT " Yu Chien Peter Lin
2023-09-14 1:40 ` Yu Chien Peter Lin
2023-09-15 11:07 ` [PATCH v2 1/3] riscv: Improve PTDUMP to show RSW with non-zero value Alexandre Ghiti
2023-09-15 11:07 ` Alexandre Ghiti
2023-09-16 7:22 ` Yu-Chien Peter Lin [this message]
2023-09-16 7:22 ` Yu-Chien Peter Lin
2023-09-18 13:03 ` Alexandre Ghiti
2023-09-18 13:03 ` Alexandre Ghiti
2023-09-18 12:53 ` Conor Dooley
2023-09-18 12:53 ` Conor Dooley
2023-09-20 3:17 ` Yu-Chien Peter Lin
2023-09-20 3:17 ` Yu-Chien Peter Lin
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=ZQVXy6I42HJM4XLM@APC323 \
--to=peterlin@andestech.com \
--cc=akpm@linux-foundation.org \
--cc=alex@ghiti.fr \
--cc=alexghiti@rivosinc.com \
--cc=aou@eecs.berkeley.edu \
--cc=bjorn@rivosinc.com \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=ycliang@andestech.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.