linux-riscv.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Tsukasa OI <research_trasio@irq.a4lg.com>
To: Anup Patel <anup@brainfault.org>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>
Cc: Tsukasa OI <research_trasio@irq.a4lg.com>,
	linux-riscv@lists.infradead.org
Subject: [RFC PATCH v2 0/4] riscv: cpufeature: Improvements for extended feature handling
Date: Thu, 25 Nov 2021 19:02:51 +0900	[thread overview]
Message-ID: <cover.1637834060.git.research_trasio@irq.a4lg.com> (raw)

I think this patchset should be CCed to Mr. Patel.

RFC PATCH v1 (0/3 through 3/3):
http://lists.infradead.org/pipermail/linux-riscv/2021-November/010252.html
http://lists.infradead.org/pipermail/linux-riscv/2021-November/010249.html
http://lists.infradead.org/pipermail/linux-riscv/2021-November/010251.html
http://lists.infradead.org/pipermail/linux-riscv/2021-November/010250.html

See 0/3 (v1) for full background.

First of all, I must repeat that this patchset breaks RISC-V KVM.

Because single-letter extension "H" is not valid in the current ISA Manual
(see Volume 1, Chapter 27 "ISA Naming Conventions" for details), either ISA
Manual or RISC-V KVM (or both, most likely) must be changed to resolve
the conflict.

Current patchset is compliant to the ISA Manual and not compatible with
RISC-V KVM (that checks single-letter "H"-extension).  However, it is easy
to work around this issue.  By removing "case 'h':" line, this parser loses
compliance with the ISA Manual but gets compatibility with RISC-V KVM.

I created an Issue on GitHub so see the details here:
<https://github.com/riscv/riscv-isa-manual/issues/781>

I understand that this is the worst timing to report this kind of issue.
Still, situation is already a problem so I thought sooner is better.



Changed in v2: Patch 1 now uses a macro (NUM_ALPHA_EXTS), not magic number
    Thanks to Ben Dooks for valuable feedback!

Changed in v2: Patch 3 (v1) is split to 3, 4 (v2)
    It's possible that we only need extension names but not version
    numbers.  To separate ugly parts, I split original Patch 3 (v1) to two:
    1. Extract only extension names (Patch 3 (v2))
    2. Parse extension names / version numbers (Patch 4 (v2))

Changed in v2: `ext_err` has different meanings
    0: No error
    1: Invalid format (invalid character exists)
    2: Major version is out of range
    3: Minor version is out of range

New in v2: Backward parser for relaxed extension name rule
    Invalid vector subextension names (Zvl*, Zve*) are correctly parsed now
    (e.g. Zvl64b, Zve64d).  New backward parser finds version number from
    the end of an extension token (because multi-letter extension must be
    delimited by '_' if not end, we can search the delimiter first).
    Note that there's a proposal to relax requirements to extension names
    that would make Zvl* and Zve* valid:
    <https://github.com/riscv/riscv-isa-manual/pull/718>
    and RFC PATCH v2 is compatible with this propsed rule.
    Valid ISA string as per current ISA Manual is not affected by this
    (for "H"-extension, implementing such relaxed parser is impossible).

Fix in v2: Parser bug 1 in v1
    Following sequence is now parsed correctly
      (that bug occurred from the nature of greedy matching):
    1. Valid extension name
    2. Major version
    3. "P"-extension without any version number
    4. Next extension (or end of the string)

Fix in v2: Parser bug 2 in v1
    Full parser in v1 breaks too early when version number causes an
    arithmetic overflow or conflict with magic number (UINT_MAX, handled as
    unversioned), that would make the parser v1 misunderstand that non-
    existent "P" extension exists.
    That also caused full and minimal parsers don't produce the same
    tokenization result.

Those changes will change the parser behavior as follows:

Legend:
    [] : Valid token (either prefix or an extension + optional delimiter)
         note that "valid" does not necessarily mean "correct".
    <> : Invalid token (ext_err != 0)

"rv32imafzvl64b_zve64f" (backward parser [new in v2] involved)
    v1 : [rv32][i][m][a][f][zvl64][b_][zve64][f]
    v2 : [rv32][i][m][a][f][zvl64b_][zve64f] (intended)
"rv64b1pv" (parser bug 1 in v1 involved):
    v1 : [rv64]<b1p>[v]
    v2 : [rv64][b1][p][v] (correct)
"rv64i2p1" (parser bug 2 in v1 involved):
    v1 : [rv64][i2p1]
    v2 : [rv64][i2p1] (same; as long as no overflow in major version)
"rv64i4294967296p1" (now major version causes overflow):
    v1 : [rv64]<i4294967296>[p1]
    v2 : [rv64]<i4294967296p1> (correct)


Tsukasa OI (4):
  riscv: cpufeature: Correctly print supported extensions
  riscv: cpufeature: Minimal parser for "riscv,isa" strings
  riscv: cpufeature: Extract extension names from "riscv,isa"
  riscv: cpufeature: Full parser for "riscv,isa" strings

 arch/riscv/kernel/cpufeature.c | 119 +++++++++++++++++++++++++++++----
 1 file changed, 105 insertions(+), 14 deletions(-)

-- 
2.32.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

             reply	other threads:[~2021-11-25 10:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-25 10:02 Tsukasa OI [this message]
2021-11-25 10:02 ` [RFC PATCH v2 1/4] riscv: cpufeature: Correctly print supported extensions Tsukasa OI
2021-11-25 10:02 ` [RFC PATCH v2 2/4] riscv: cpufeature: Minimal parser for "riscv, isa" strings Tsukasa OI
2021-11-25 10:02 ` [RFC PATCH v2 3/4] riscv: cpufeature: Extract extension names from "riscv, isa" Tsukasa OI
2021-11-25 10:02 ` [RFC PATCH v2 4/4] riscv: cpufeature: Full parser for "riscv, isa" strings Tsukasa OI

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=cover.1637834060.git.research_trasio@irq.a4lg.com \
    --to=research_trasio@irq.a4lg.com \
    --cc=anup@brainfault.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.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 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).