All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Heiko Stübner" <heiko@sntech.de>
To: Palmer Dabbelt <palmer@rivosinc.com>, Evan Green <evan@rivosinc.com>
Cc: slewis@rivosinc.com, Conor Dooley <conor@kernel.org>,
	vineetg@rivosinc.com, Evan Green <evan@rivosinc.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Andrew Bresticker <abrestic@rivosinc.com>,
	Andrew Jones <ajones@ventanamicro.com>,
	Anup Patel <apatel@ventanamicro.com>,
	Arnd Bergmann <arnd@arndb.de>, Atish Patra <atishp@rivosinc.com>,
	Bagas Sanjaya <bagasdotme@gmail.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Celeste Liu <coelacanthus@outlook.com>,
	Conor Dooley <conor.dooley@microchip.com>,
	Dao Lu <daolu@rivosinc.com>, Davidlohr Bueso <dave@stgolabs.net>,
	Guo Ren <guoren@kernel.org>, Jann Horn <jannh@google.com>,
	Jisheng Zhang <jszhang@kernel.org>,
	Jonathan Corbet <corbet@lwn.net>,
	"Liam R. Howlett" <Liam.Howlett@oracle.com>,
	Mark Brown <broonie@kernel.org>,
	Mayuresh Chitale <mchitale@ventanamicro.com>,
	Nathan Chancellor <nathan@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Philipp Tomsich <philipp.tomsich@vrull.eu>,
	Randy Dunlap <rdunlap@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Sunil V L <sunilvl@ventanamicro.com>,
	Tobias Klauser <tklauser@distanz.ch>,
	Tsukasa OI <research_trasio@irq.a4lg.com>,
	Wei Fu <wefu@redhat.com>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-kselftest@vger.kernel.org, linux-riscv@lists.infradead.org
Subject: Re: [PATCH v4 0/6] RISC-V Hardware Probing User Interface
Date: Tue, 21 Mar 2023 21:32:49 +0100	[thread overview]
Message-ID: <6291488.MhkbZ0Pkbq@diego> (raw)
In-Reply-To: <20230314183220.513101-1-evan@rivosinc.com>

Am Dienstag, 14. März 2023, 19:32:14 CET schrieb Evan Green:
> 
> There's been a bunch of off-list discussions about this, including at
> Plumbers.  The original plan was to do something involving providing an
> ISA string to userspace, but ISA strings just aren't sufficient for a
> stable ABI any more: in order to parse an ISA string users need the
> version of the specifications that the string is written to, the version
> of each extension (sometimes at a finer granularity than the RISC-V
> releases/versions encode), and the expected use case for the ISA string
> (ie, is it a U-mode or M-mode string).  That's a lot of complexity to
> try and keep ABI compatible and it's probably going to continue to grow,
> as even if there's no more complexity in the specifications we'll have
> to deal with the various ISA string parsing oddities that end up all
> over userspace.
> 
> Instead this patch set takes a very different approach and provides a set
> of key/value pairs that encode various bits about the system.  The big
> advantage here is that we can clearly define what these mean so we can
> ensure ABI stability, but it also allows us to encode information that's
> unlikely to ever appear in an ISA string (see the misaligned access
> performance, for example).  The resulting interface looks a lot like
> what arm64 and x86 do, and will hopefully fit well into something like
> ACPI in the future.
> 
> The actual user interface is a syscall, with a vDSO function in front of
> it. The vDSO function can answer some queries without a syscall at all,
> and falls back to the syscall for cases it doesn't have answers to.
> Currently we prepopulate it with an array of answers for all keys and
> a CPU set of "all CPUs". This can be adjusted as necessary to provide
> fast answers to the most common queries.

I've built myself a small test-program [see below], to check the feature
on the d1-nezha board. Which is how I found the tiny c-extension issue.

Series works as expected there, so patches 1-4 on a d1-nezha:

Tested-by: Heiko Stuebner <heiko.stuebner@vrull.eu>



hwprobe.c:
----------------
#include <linux/types.h>
#include <sys/syscall.h>
#include <stdio.h>
#include <unistd.h>

#define __NR_riscv_hwprobe 258

struct riscv_hwprobe {
        __s64 key;
        __u64 value;
};

#define RISCV_HWPROBE_KEY_MVENDORID     0
#define RISCV_HWPROBE_KEY_MARCHID       1
#define RISCV_HWPROBE_KEY_MIMPID        2
#define RISCV_HWPROBE_KEY_BASE_BEHAVIOR 3
#define         RISCV_HWPROBE_BASE_BEHAVIOR_IMA (1 << 0)
#define RISCV_HWPROBE_KEY_IMA_EXT_0     4
#define         RISCV_HWPROBE_IMA_FD            (1 << 0)
#define         RISCV_HWPROBE_IMA_C             (1 << 1)
#define RISCV_HWPROBE_KEY_CPUPERF_0     5
#define         RISCV_HWPROBE_MISALIGNED_UNKNOWN        (0 << 0)
#define         RISCV_HWPROBE_MISALIGNED_EMULATED       (1 << 0)
#define         RISCV_HWPROBE_MISALIGNED_SLOW           (2 << 0)
#define         RISCV_HWPROBE_MISALIGNED_FAST           (3 << 0)
#define         RISCV_HWPROBE_MISALIGNED_UNSUPPORTED    (4 << 0)
#define         RISCV_HWPROBE_MISALIGNED_MASK           (7 << 0)

int __riscv_hwprobe (struct riscv_hwprobe *pairs, long pair_count,
  long cpu_count, unsigned long *cpus, unsigned long flags)
{

        return syscall(__NR_riscv_hwprobe, pairs, pair_count, cpu_count, cpus, flags);
}

int main(void)
{
        struct riscv_hwprobe pairs[3];

        pairs[0].key = RISCV_HWPROBE_KEY_MVENDORID;
        pairs[1].key = RISCV_HWPROBE_KEY_MARCHID;
        pairs[2].key = RISCV_HWPROBE_KEY_MIMPID;
        if (__riscv_hwprobe(pairs, 3, 0, NULL, 0) != 0) {
                printf("syscall failed");
                return -1;
        }

        printf("vendorid 0x%x, archid 0x%x, impid 0x%x\n",
               pairs[0].value, pairs[1].value, pairs[2].value);


        pairs[0].key = RISCV_HWPROBE_KEY_CPUPERF_0;
        pairs[1].key = RISCV_HWPROBE_KEY_BASE_BEHAVIOR;
        pairs[2].key = RISCV_HWPROBE_KEY_IMA_EXT_0;
        if (__riscv_hwprobe(&pairs[0], 3, 0, NULL, 0) != 0) {
                printf("syscall failed");
                return -1;
        }

        printf("ima-behavior %d, f+d %d, c %d, misaligned access: %s\n",
        ((pairs[1].value & RISCV_HWPROBE_BASE_BEHAVIOR_IMA) == RISCV_HWPROBE_BASE_BEHAVIOR_IMA),
        ((pairs[2].value & RISCV_HWPROBE_IMA_FD) == RISCV_HWPROBE_IMA_FD),
        ((pairs[2].value & RISCV_HWPROBE_IMA_C) == RISCV_HWPROBE_IMA_C),
        ((pairs[0].value & RISCV_HWPROBE_MISALIGNED_FAST) == RISCV_HWPROBE_MISALIGNED_FAST) ? "fast" : "not-fast"
        );

        return 0;
}




      parent reply	other threads:[~2023-03-21 20:33 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-14 18:32 [PATCH v4 0/6] RISC-V Hardware Probing User Interface Evan Green
2023-03-14 18:32 ` [PATCH v4 1/6] RISC-V: Move struct riscv_cpuinfo to new header Evan Green
2023-03-14 18:32   ` Evan Green
2023-03-21 20:22   ` Heiko Stübner
2023-03-21 20:22     ` Heiko Stübner
2023-03-14 18:32 ` [PATCH v4 2/6] RISC-V: Add a syscall for HW probing Evan Green
2023-03-14 18:32   ` Evan Green
2023-03-21 20:23   ` Heiko Stübner
2023-03-21 20:23     ` Heiko Stübner
2023-03-14 18:32 ` [PATCH v4 3/6] RISC-V: hwprobe: Add support for RISCV_HWPROBE_BASE_BEHAVIOR_IMA Evan Green
2023-03-14 18:32   ` Evan Green
2023-03-21 16:41   ` Heiko Stübner
2023-03-21 16:41     ` Heiko Stübner
2023-03-22 16:17     ` Evan Green
2023-03-22 16:17       ` Evan Green
2023-03-21 20:25   ` Heiko Stübner
2023-03-21 20:25     ` Heiko Stübner
2023-03-22 15:35   ` Conor Dooley
2023-03-22 15:35     ` Conor Dooley
2023-03-22 16:04     ` Evan Green
2023-03-22 16:04       ` Evan Green
2023-03-14 18:32 ` [PATCH v4 4/6] RISC-V: hwprobe: Support probing of misaligned access performance Evan Green
2023-03-14 18:32   ` Evan Green
2023-03-17 10:08   ` Heiko Stübner
2023-03-17 10:08     ` Heiko Stübner
2023-03-21 15:35     ` Evan Green
2023-03-21 15:35       ` Evan Green
2023-03-18 12:02   ` Conor Dooley
2023-03-18 12:02     ` Conor Dooley
2023-03-21 20:27   ` Heiko Stübner
2023-03-21 20:27     ` Heiko Stübner
2023-03-14 18:32 ` [PATCH v4 5/6] selftests: Test the new RISC-V hwprobe interface Evan Green
2023-03-14 18:32   ` Evan Green
2023-03-14 18:32 ` [PATCH v4 6/6] RISC-V: Add hwprobe vDSO function and data Evan Green
2023-03-14 18:32   ` Evan Green
2023-03-17 11:08   ` kernel test robot
2023-03-17 11:08     ` kernel test robot
2023-03-17 12:10   ` kernel test robot
2023-03-17 12:10     ` kernel test robot
2023-03-21 20:32 ` Heiko Stübner [this message]

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=6291488.MhkbZ0Pkbq@diego \
    --to=heiko@sntech.de \
    --cc=Liam.Howlett@oracle.com \
    --cc=abrestic@rivosinc.com \
    --cc=ajones@ventanamicro.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=apatel@ventanamicro.com \
    --cc=arnd@arndb.de \
    --cc=atishp@rivosinc.com \
    --cc=bagasdotme@gmail.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=coelacanthus@outlook.com \
    --cc=conor.dooley@microchip.com \
    --cc=conor@kernel.org \
    --cc=corbet@lwn.net \
    --cc=daolu@rivosinc.com \
    --cc=dave@stgolabs.net \
    --cc=evan@rivosinc.com \
    --cc=guoren@kernel.org \
    --cc=jannh@google.com \
    --cc=jszhang@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=mchitale@ventanamicro.com \
    --cc=nathan@kernel.org \
    --cc=palmer@dabbelt.com \
    --cc=palmer@rivosinc.com \
    --cc=paul.walmsley@sifive.com \
    --cc=philipp.tomsich@vrull.eu \
    --cc=rdunlap@infradead.org \
    --cc=research_trasio@irq.a4lg.com \
    --cc=shuah@kernel.org \
    --cc=slewis@rivosinc.com \
    --cc=sudeep.holla@arm.com \
    --cc=sunilvl@ventanamicro.com \
    --cc=tklauser@distanz.ch \
    --cc=vineetg@rivosinc.com \
    --cc=wefu@redhat.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.