2019-09-27 00:12:52

by Atish Patra

[permalink] [raw]
Subject: [PATCH v2 3/3] RISC-V: Move SBI related macros under uapi.

All SBI related macros can be reused by KVM RISC-V and userspace tools
such as kvmtool, qemu-kvm. SBI calls can also be emulated by userspace
if required. Any future vendor extensions can leverage this to emulate
the specific extension in userspace instead of kernel.

Signed-off-by: Atish Patra <[email protected]>
---
arch/riscv/include/asm/sbi.h | 37 +-----------------------
arch/riscv/include/uapi/asm/sbi.h | 48 +++++++++++++++++++++++++++++++
2 files changed, 49 insertions(+), 36 deletions(-)
create mode 100644 arch/riscv/include/uapi/asm/sbi.h

diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
index 279b7f10b3c2..902b83041111 100644
--- a/arch/riscv/include/asm/sbi.h
+++ b/arch/riscv/include/asm/sbi.h
@@ -7,42 +7,7 @@
#define _ASM_RISCV_SBI_H

#include <linux/types.h>
-
-enum sbi_ext_id {
- SBI_EXT_0_1_SET_TIMER = 0x0,
- SBI_EXT_0_1_CONSOLE_PUTCHAR = 0x1,
- SBI_EXT_0_1_CONSOLE_GETCHAR = 0x2,
- SBI_EXT_0_1_CLEAR_IPI = 0x3,
- SBI_EXT_0_1_SEND_IPI = 0x4,
- SBI_EXT_0_1_REMOTE_FENCE_I = 0x5,
- SBI_EXT_0_1_REMOTE_SFENCE_VMA = 0x6,
- SBI_EXT_0_1_REMOTE_SFENCE_VMA_ASID = 0x7,
- SBI_EXT_0_1_SHUTDOWN = 0x8,
- SBI_EXT_BASE = 0x10,
-};
-
-enum sbi_ext_base_fid {
- SBI_BASE_GET_SPEC_VERSION = 0,
- SBI_BASE_GET_IMP_ID,
- SBI_BASE_GET_IMP_VERSION,
- SBI_BASE_PROBE_EXT,
- SBI_BASE_GET_MVENDORID,
- SBI_BASE_GET_MARCHID,
- SBI_BASE_GET_MIMPID,
-};
-
-#define SBI_SPEC_VERSION_DEFAULT 0x1
-#define SBI_SPEC_VERSION_MAJOR_OFFSET 24
-#define SBI_SPEC_VERSION_MAJOR_MASK 0x7f
-#define SBI_SPEC_VERSION_MINOR_MASK 0xffffff
-
-/* SBI return error codes */
-#define SBI_SUCCESS 0
-#define SBI_ERR_FAILURE -1
-#define SBI_ERR_NOT_SUPPORTED -2
-#define SBI_ERR_INVALID_PARAM -3
-#define SBI_ERR_DENIED -4
-#define SBI_ERR_INVALID_ADDRESS -5
+#include <uapi/asm/sbi.h>

extern unsigned long sbi_spec_version;
struct sbiret {
diff --git a/arch/riscv/include/uapi/asm/sbi.h b/arch/riscv/include/uapi/asm/sbi.h
new file mode 100644
index 000000000000..2e09ee52c346
--- /dev/null
+++ b/arch/riscv/include/uapi/asm/sbi.h
@@ -0,0 +1,48 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Common SBI related defines and macros to be used by RISC-V kernel,
+ * RISC-V KVM and userspace.
+ *
+ * Copyright (c) 2019 Western Digital Corporation or its affiliates.
+ */
+
+#ifndef _UAPI_ASM_RISCV_SBI_H
+#define _UAPI_ASM_RISCV_SBI_H
+
+enum sbi_ext_id {
+ SBI_EXT_0_1_SET_TIMER = 0x0,
+ SBI_EXT_0_1_CONSOLE_PUTCHAR = 0x1,
+ SBI_EXT_0_1_CONSOLE_GETCHAR = 0x2,
+ SBI_EXT_0_1_CLEAR_IPI = 0x3,
+ SBI_EXT_0_1_SEND_IPI = 0x4,
+ SBI_EXT_0_1_REMOTE_FENCE_I = 0x5,
+ SBI_EXT_0_1_REMOTE_SFENCE_VMA = 0x6,
+ SBI_EXT_0_1_REMOTE_SFENCE_VMA_ASID = 0x7,
+ SBI_EXT_0_1_SHUTDOWN = 0x8,
+ SBI_EXT_BASE = 0x10,
+};
+
+enum sbi_ext_base_fid {
+ SBI_BASE_GET_SPEC_VERSION = 0,
+ SBI_BASE_GET_IMP_ID,
+ SBI_BASE_GET_IMP_VERSION,
+ SBI_BASE_PROBE_EXT,
+ SBI_BASE_GET_MVENDORID,
+ SBI_BASE_GET_MARCHID,
+ SBI_BASE_GET_MIMPID,
+};
+
+#define SBI_SPEC_VERSION_DEFAULT 0x1
+#define SBI_SPEC_VERSION_MAJOR_OFFSET 24
+#define SBI_SPEC_VERSION_MAJOR_MASK 0x7f
+#define SBI_SPEC_VERSION_MINOR_MASK 0xffffff
+
+/* SBI return error codes */
+#define SBI_SUCCESS 0
+#define SBI_ERR_FAILURE -1
+#define SBI_ERR_NOT_SUPPORTED -2
+#define SBI_ERR_INVALID_PARAM -3
+#define SBI_ERR_DENIED -4
+#define SBI_ERR_INVALID_ADDRESS -5
+
+#endif
--
2.21.0


2019-09-27 05:53:54

by Anup Patel

[permalink] [raw]
Subject: Re: [PATCH v2 3/3] RISC-V: Move SBI related macros under uapi.

On Fri, Sep 27, 2019 at 5:39 AM Atish Patra <[email protected]> wrote:
>
> All SBI related macros can be reused by KVM RISC-V and userspace tools
> such as kvmtool, qemu-kvm. SBI calls can also be emulated by userspace
> if required. Any future vendor extensions can leverage this to emulate
> the specific extension in userspace instead of kernel.
>
> Signed-off-by: Atish Patra <[email protected]>
> ---
> arch/riscv/include/asm/sbi.h | 37 +-----------------------
> arch/riscv/include/uapi/asm/sbi.h | 48 +++++++++++++++++++++++++++++++
> 2 files changed, 49 insertions(+), 36 deletions(-)
> create mode 100644 arch/riscv/include/uapi/asm/sbi.h
>
> diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
> index 279b7f10b3c2..902b83041111 100644
> --- a/arch/riscv/include/asm/sbi.h
> +++ b/arch/riscv/include/asm/sbi.h
> @@ -7,42 +7,7 @@
> #define _ASM_RISCV_SBI_H
>
> #include <linux/types.h>
> -
> -enum sbi_ext_id {
> - SBI_EXT_0_1_SET_TIMER = 0x0,
> - SBI_EXT_0_1_CONSOLE_PUTCHAR = 0x1,
> - SBI_EXT_0_1_CONSOLE_GETCHAR = 0x2,
> - SBI_EXT_0_1_CLEAR_IPI = 0x3,
> - SBI_EXT_0_1_SEND_IPI = 0x4,
> - SBI_EXT_0_1_REMOTE_FENCE_I = 0x5,
> - SBI_EXT_0_1_REMOTE_SFENCE_VMA = 0x6,
> - SBI_EXT_0_1_REMOTE_SFENCE_VMA_ASID = 0x7,
> - SBI_EXT_0_1_SHUTDOWN = 0x8,
> - SBI_EXT_BASE = 0x10,
> -};
> -
> -enum sbi_ext_base_fid {
> - SBI_BASE_GET_SPEC_VERSION = 0,
> - SBI_BASE_GET_IMP_ID,
> - SBI_BASE_GET_IMP_VERSION,
> - SBI_BASE_PROBE_EXT,
> - SBI_BASE_GET_MVENDORID,
> - SBI_BASE_GET_MARCHID,
> - SBI_BASE_GET_MIMPID,
> -};
> -
> -#define SBI_SPEC_VERSION_DEFAULT 0x1
> -#define SBI_SPEC_VERSION_MAJOR_OFFSET 24
> -#define SBI_SPEC_VERSION_MAJOR_MASK 0x7f
> -#define SBI_SPEC_VERSION_MINOR_MASK 0xffffff
> -
> -/* SBI return error codes */
> -#define SBI_SUCCESS 0
> -#define SBI_ERR_FAILURE -1
> -#define SBI_ERR_NOT_SUPPORTED -2
> -#define SBI_ERR_INVALID_PARAM -3
> -#define SBI_ERR_DENIED -4
> -#define SBI_ERR_INVALID_ADDRESS -5
> +#include <uapi/asm/sbi.h>
>
> extern unsigned long sbi_spec_version;
> struct sbiret {
> diff --git a/arch/riscv/include/uapi/asm/sbi.h b/arch/riscv/include/uapi/asm/sbi.h
> new file mode 100644
> index 000000000000..2e09ee52c346
> --- /dev/null
> +++ b/arch/riscv/include/uapi/asm/sbi.h
> @@ -0,0 +1,48 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Common SBI related defines and macros to be used by RISC-V kernel,
> + * RISC-V KVM and userspace.
> + *
> + * Copyright (c) 2019 Western Digital Corporation or its affiliates.
> + */
> +
> +#ifndef _UAPI_ASM_RISCV_SBI_H
> +#define _UAPI_ASM_RISCV_SBI_H
> +
> +enum sbi_ext_id {
> + SBI_EXT_0_1_SET_TIMER = 0x0,
> + SBI_EXT_0_1_CONSOLE_PUTCHAR = 0x1,
> + SBI_EXT_0_1_CONSOLE_GETCHAR = 0x2,
> + SBI_EXT_0_1_CLEAR_IPI = 0x3,
> + SBI_EXT_0_1_SEND_IPI = 0x4,
> + SBI_EXT_0_1_REMOTE_FENCE_I = 0x5,
> + SBI_EXT_0_1_REMOTE_SFENCE_VMA = 0x6,
> + SBI_EXT_0_1_REMOTE_SFENCE_VMA_ASID = 0x7,
> + SBI_EXT_0_1_SHUTDOWN = 0x8,
> + SBI_EXT_BASE = 0x10,
> +};
> +
> +enum sbi_ext_base_fid {
> + SBI_BASE_GET_SPEC_VERSION = 0,
> + SBI_BASE_GET_IMP_ID,
> + SBI_BASE_GET_IMP_VERSION,
> + SBI_BASE_PROBE_EXT,
> + SBI_BASE_GET_MVENDORID,
> + SBI_BASE_GET_MARCHID,
> + SBI_BASE_GET_MIMPID,
> +};
> +
> +#define SBI_SPEC_VERSION_DEFAULT 0x1
> +#define SBI_SPEC_VERSION_MAJOR_OFFSET 24
> +#define SBI_SPEC_VERSION_MAJOR_MASK 0x7f
> +#define SBI_SPEC_VERSION_MINOR_MASK 0xffffff
> +
> +/* SBI return error codes */
> +#define SBI_SUCCESS 0
> +#define SBI_ERR_FAILURE -1
> +#define SBI_ERR_NOT_SUPPORTED -2
> +#define SBI_ERR_INVALID_PARAM -3
> +#define SBI_ERR_DENIED -4
> +#define SBI_ERR_INVALID_ADDRESS -5
> +
> +#endif
> --
> 2.21.0
>

Thanks for considering KVM user-space SBI emulation.

Reviewed-by: Anup Patel <[email protected]>

Regards,
Anup

2019-09-27 22:24:30

by Christoph Hellwig

[permalink] [raw]
Subject: Re: [PATCH v2 3/3] RISC-V: Move SBI related macros under uapi.

On Thu, Sep 26, 2019 at 05:09:15PM -0700, Atish Patra wrote:
> All SBI related macros can be reused by KVM RISC-V and userspace tools
> such as kvmtool, qemu-kvm. SBI calls can also be emulated by userspace
> if required. Any future vendor extensions can leverage this to emulate
> the specific extension in userspace instead of kernel.

Just because userspace can use them that doesn't mean they are a
userspace API. Please don't do this as this limits how we can ever
remove previously existing symbols. Just copy over the current
version of the file into the other project of your choice instead
of creating and API we need to maintain.

2019-10-03 06:18:33

by Anup Patel

[permalink] [raw]
Subject: Re: [PATCH v2 3/3] RISC-V: Move SBI related macros under uapi.

On Sat, Sep 28, 2019 at 3:51 AM Christoph Hellwig <[email protected]> wrote:
>
> On Thu, Sep 26, 2019 at 05:09:15PM -0700, Atish Patra wrote:
> > All SBI related macros can be reused by KVM RISC-V and userspace tools
> > such as kvmtool, qemu-kvm. SBI calls can also be emulated by userspace
> > if required. Any future vendor extensions can leverage this to emulate
> > the specific extension in userspace instead of kernel.
>
> Just because userspace can use them that doesn't mean they are a
> userspace API. Please don't do this as this limits how we can ever
> remove previously existing symbols. Just copy over the current
> version of the file into the other project of your choice instead
> of creating and API we need to maintain.

These defines are indeed part of KVM userspace API because we will
be forwarding SBI calls not handled by KVM RISC-V kernel module to
KVM userspace (QEMU/KVMTOOL). The forwarded SBI call details
are passed to userspace via "struct kvm_run" of KVM_RUN ioctl.

Please refer PATCH17 and PATCH18 of KVM RISC-V v8 series.

Currently, we implement SBI v0.1 for KVM Guest hence we end-up
forwarding CONSOLE_GETCHAR and CONSOLE_PUTCHART to
KVM userspace.

In future we will implement SBI v0.2 for KVM Guest where we will be
forwarding the SBI v0.2 experimental and vendor extension calls
to KVM userspace.

Eventually, we will stop emulating SBI v0.1 for Guest once we have
all required calls in SBI v0.2. At that time, all SBI v0.1 calls will be
always forwarded to KVM userspace.

Regards,
Anup

2019-10-08 15:40:48

by Christoph Hellwig

[permalink] [raw]
Subject: Re: [PATCH v2 3/3] RISC-V: Move SBI related macros under uapi.

On Thu, Oct 03, 2019 at 11:00:05AM +0530, Anup Patel wrote:
> These defines are indeed part of KVM userspace API because we will
> be forwarding SBI calls not handled by KVM RISC-V kernel module to
> KVM userspace (QEMU/KVMTOOL). The forwarded SBI call details
> are passed to userspace via "struct kvm_run" of KVM_RUN ioctl.

At best your are passing through a hardware interface. We don't expose
e.g. the nvme headers to userspace either. We keep the headers clean
enough that userspace can copy them (and a few projects do), but they
really are not a kernel interface in any classic way.