KVM RISC-V Conditional Operations
Subsystems (5)
v2 cover KVM RISC-V Conditional Operations
This series extends KVM RISC-V to allow Guest/VM discover and use conditional operations related ISA extensions (namely XVentanaCondOps and Zicond).
To try these patches, use KVMTOOL from riscv_zbx_zicntr_smstateen_condops_v1 branch at: https://github.com/avpatel/kvmtool.git
These patches are based upon the latest riscv_kvm_queue and can also be found in the riscv_kvm_condops_v2 branch at:
https://github.com/avpatel/linux.git
Changes since v1:
- Rebased the series on riscv_kvm_queue
- Split PATCH1 and PATCH2 of v1 series into two patches
- Added separate test configs for XVentanaCondOps and Zicond in PATCH7 of v1 series.
Anup Patel (9):
dt-bindings: riscv: Add XVentanaCondOps extension entry
RISC-V: Detect XVentanaCondOps from ISA string
dt-bindings: riscv: Add Zicond extension entry
RISC-V: Detect Zicond from ISA string
RISC-V: KVM: Allow XVentanaCondOps extension for Guest/VM
RISC-V: KVM: Allow Zicond extension for Guest/VM
KVM: riscv: selftests: Add senvcfg register to get-reg-list test
KVM: riscv: selftests: Add smstateen registers to get-reg-list test
KVM: riscv: selftests: Add condops extensions to get-reg-list test
.../devicetree/bindings/riscv/extensions.yaml | 13 ++++ arch/riscv/include/asm/hwcap.h | 2 + arch/riscv/include/uapi/asm/kvm.h | 2 + arch/riscv/kernel/cpufeature.c | 2 + arch/riscv/kvm/vcpu_onereg.c | 4 ++ .../selftests/kvm/riscv/get-reg-list.c | 71 +++++++++++++++++++ 6 files changed, 94 insertions(+)
Signature · 1 line
2.34.1
PATCH v2 1/9 dt-bindings: riscv: Add XVentanaCondOps extension entry
Add an entry for the XVentanaCondOps extension to the riscv,isa-extensions property.
--- Documentation/devicetree/bindings/riscv/extensions.yaml | 7 +++++++ 1 file changed, 7 insertions(+)
Documentation/devicetree/bindings/riscv/extensions.yaml +7 -0
@@ -171,6 +171,13 @@ properties: memory types as ratified in the 20191213 version of the privileged ISA specification. + - const: xventanacondops + description: | + The Ventana specific XVentanaCondOps extension for conditional + arithmetic and conditional-select/move operations defined by the + Ventana custom extensions specification v1.0.1 (or higher) at + https://github.com/ventanamicro/ventana-custom-extensions/releases. + - const: zba description: | The standard Zba bit-manipulation extension for address generation
Signature · 1 line
2.34.1
Re: [PATCH v2 1/9] dt-bindings: riscv: Add XVentanaCondOps extension entry
Quoted 29 lines · Anup Patel
Add an entry for the XVentanaCondOps extension to the riscv,isa-extensions property.
Signed-off-by Anup Patel <[email protected]>--- Documentation/devicetree/bindings/riscv/extensions.yaml | 7 +++++++ 1 file changed, 7 insertions(+)Documentation/devicetree/bindings/riscv/extensions.yaml +7
-0@@ -171,6 +171,13 @@ properties: memory types as ratified in the 20191213 version of the privileged ISA specification. + - const: xventanacondops + description: | + The Ventana specific XVentanaCondOps extension for conditional + arithmetic and conditional-select/move operations defined by the + Ventana custom extensions specification v1.0.1 (or higher) at + https://github.com/ventanamicro/ventana-custom-extensions/releases. + - const: zba description: | The standard Zba bit-manipulation extension for address generationSignature · 1 line
2.34.1
PATCH v2 2/9 RISC-V: Detect XVentanaCondOps from ISA string
In reply to Anup PatelThe Veyron-V1 CPU supports custom conditional arithmetic and conditional-select/move operations referred to as XVentanaCondOps extension. In fact, QEMU RISC-V also has support for emulating XVentanaCondOps extension.
Let us detect XVentanaCondOps extension from ISA string available through DT or ACPI.
--- arch/riscv/include/asm/hwcap.h | 1 + arch/riscv/kernel/cpufeature.c | 1 + 2 files changed, 2 insertions(+)
arch/riscv/include/asm/hwcap.h +1 -0
@@ -59,6 +59,7 @@#define RISCV_ISA_EXT_ZIFENCEI 41#define RISCV_ISA_EXT_ZIHPM 42#define RISCV_ISA_EXT_SMSTATEEN 43 +#define RISCV_ISA_EXT_XVENTANACONDOPS 44#define RISCV_ISA_EXT_MAX 64
arch/riscv/kernel/cpufeature.c +1 -0
@@ -182,6 +182,7 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {__RISCV_ISA_EXT_DATA (svinval,RISCV_ISA_EXT_SVINVAL ),__RISCV_ISA_EXT_DATA (svnapot,RISCV_ISA_EXT_SVNAPOT ),__RISCV_ISA_EXT_DATA (svpbmt,RISCV_ISA_EXT_SVPBMT ), + __RISCV_ISA_EXT_DATA(xventanacondops, RISCV_ISA_EXT_XVENTANACONDOPS), };const size_t riscv_isa_ext_count =ARRAY_SIZE (riscv_isa_ext);
Signature · 1 line
2.34.1
Re: [PATCH v2 2/9] RISC-V: Detect XVentanaCondOps from ISA string
Quoted 47 lines · Anup Patel
The Veyron-V1 CPU supports custom conditional arithmetic and conditional-select/move operations referred to as XVentanaCondOps extension. In fact, QEMU RISC-V also has support for emulating XVentanaCondOps extension.
Let us detect XVentanaCondOps extension from ISA string available through DT or ACPI.
Signed-off-by Anup Patel <[email protected]>Reviewed-by Andrew Jones <[email protected]>--- arch/riscv/include/asm/hwcap.h | 1 + arch/riscv/kernel/cpufeature.c | 1 + 2 files changed, 2 insertions(+)arch/riscv/include/asm/hwcap.h +1
-0@@ -59,6 +59,7 @@#define RISCV_ISA_EXT_ZIFENCEI 41#define RISCV_ISA_EXT_ZIHPM 42#define RISCV_ISA_EXT_SMSTATEEN 43 +#define RISCV_ISA_EXT_XVENTANACONDOPS 44#define RISCV_ISA_EXT_MAX 64arch/riscv/kernel/cpufeature.c +1
-0@@ -182,6 +182,7 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {__RISCV_ISA_EXT_DATA (svinval,RISCV_ISA_EXT_SVINVAL ),__RISCV_ISA_EXT_DATA (svnapot,RISCV_ISA_EXT_SVNAPOT ),__RISCV_ISA_EXT_DATA (svpbmt,RISCV_ISA_EXT_SVPBMT ), + __RISCV_ISA_EXT_DATA(xventanacondops, RISCV_ISA_EXT_XVENTANACONDOPS), };const size_t riscv_isa_ext_count =ARRAY_SIZE (riscv_isa_ext);Signature · 7 lines
2.34.1 _______________________________________________ linux-riscv mailing list linux-riscv at lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
I worry about storing vendor extensions in this file. Because vendor extensions are not standardized, they can only be expected to have the desired behavior on hardware with the appropriate vendor id. A couple months ago I sent a patch to address this by handling vector extensions independently for each vendor [1]. I dropped the patch because it relied upon Heiko's T-Head vector extension support that he stopped working on. However, I can revive this patch so you can build off of it.
This scheme has the added benefit that vendors do not have to worry about conficting extensions, and the kernel does not have to act as a key registry for vendors.
What are your thoughts?
- Charlie
[1] https://lore.kernel.org/lkml/20230705-thead_vendor_extensions-v1-2-ad6915349c4d at rivosinc.com/
Re: [PATCH v2 2/9] RISC-V: Detect XVentanaCondOps from ISA string
Quoted 61 lines · Charlie Jenkins
Quoted 47 lines · Anup Patel
The Veyron-V1 CPU supports custom conditional arithmetic and conditional-select/move operations referred to as XVentanaCondOps extension. In fact, QEMU RISC-V also has support for emulating XVentanaCondOps extension.
Let us detect XVentanaCondOps extension from ISA string available through DT or ACPI.
Signed-off-by Anup Patel <[email protected]>Reviewed-by Andrew Jones <[email protected]>--- arch/riscv/include/asm/hwcap.h | 1 + arch/riscv/kernel/cpufeature.c | 1 + 2 files changed, 2 insertions(+)arch/riscv/include/asm/hwcap.h +1
-0@@ -59,6 +59,7 @@#define RISCV_ISA_EXT_ZIFENCEI 41#define RISCV_ISA_EXT_ZIHPM 42#define RISCV_ISA_EXT_SMSTATEEN 43 +#define RISCV_ISA_EXT_XVENTANACONDOPS 44#define RISCV_ISA_EXT_MAX 64arch/riscv/kernel/cpufeature.c +1
-0@@ -182,6 +182,7 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {__RISCV_ISA_EXT_DATA (svinval,RISCV_ISA_EXT_SVINVAL ),__RISCV_ISA_EXT_DATA (svnapot,RISCV_ISA_EXT_SVNAPOT ),__RISCV_ISA_EXT_DATA (svpbmt,RISCV_ISA_EXT_SVPBMT ), + __RISCV_ISA_EXT_DATA(xventanacondops, RISCV_ISA_EXT_XVENTANACONDOPS), };const size_t riscv_isa_ext_count =ARRAY_SIZE (riscv_isa_ext);Signature · 7 lines
2.34.1 _______________________________________________ linux-riscv mailing list linux-riscv at lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscvI worry about storing vendor extensions in this file. Because vendor extensions are not standardized, they can only be expected to have the desired behavior on hardware with the appropriate vendor id. A couple months ago I sent a patch to address this by handling vector extensions independently for each vendor [1]. I dropped the patch because it relied upon Heiko's T-Head vector extension support that he stopped working on. However, I can revive this patch so you can build off of it.
This scheme has the added benefit that vendors do not have to worry about conficting extensions, and the kernel does not have to act as a key registry for vendors.
Quoted 6 lines
What are your thoughts?
- Charlie
[1] https://lore.kernel.org/lkml/20230705-thead_vendor_extensions-v1-2-ad6915349c4d at rivosinc.com/
I guess I don't need to revive the patch, you could just take the code and update it for xventanacondops.
- Charlie
Re: [PATCH v2 2/9] RISC-V: Detect XVentanaCondOps from ISA string
In reply to Charlie JenkinsQuoted 45 lines · On Mon, Sep 25, 2023 at 11:18?PM Charlie Jenkins <[email protected]> wrote:
Quoted 43 lines · Anup Patel
The Veyron-V1 CPU supports custom conditional arithmetic and conditional-select/move operations referred to as XVentanaCondOps extension. In fact, QEMU RISC-V also has support for emulating XVentanaCondOps extension.
Let us detect XVentanaCondOps extension from ISA string available through DT or ACPI.
Signed-off-by Anup Patel <[email protected]>Reviewed-by Andrew Jones <[email protected]>--- arch/riscv/include/asm/hwcap.h | 1 + arch/riscv/kernel/cpufeature.c | 1 + 2 files changed, 2 insertions(+)arch/riscv/include/asm/hwcap.h +1
-0@@ -59,6 +59,7 @@#define RISCV_ISA_EXT_ZIFENCEI 41#define RISCV_ISA_EXT_ZIHPM 42#define RISCV_ISA_EXT_SMSTATEEN 43 +#define RISCV_ISA_EXT_XVENTANACONDOPS 44#define RISCV_ISA_EXT_MAX 64arch/riscv/kernel/cpufeature.c +1
-1@@ -182,6 +182,7 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {__RISCV_ISA_EXT_DATA (svinval,RISCV_ISA_EXT_SVINVAL ),__RISCV_ISA_EXT_DATA (svnapot,RISCV_ISA_EXT_SVNAPOT ),__RISCV_ISA_EXT_DATA (svpbmt,RISCV_ISA_EXT_SVPBMT ), + __RISCV_ISA_EXT_DATA(xventanacondops, RISCV_ISA_EXT_XVENTANACONDOPS), };const size_t riscv_isa_ext_count =ARRAY_SIZE (riscv_isa_ext); --2.34.1
Quoted 8 lines
Quoted 4 lines
_______________________________________________
linux-riscv mailing list
linux-riscv at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscvI worry about storing vendor extensions in this file. Because vendor extensions are not standardized, they can only be expected to have the desired behavior on hardware with the appropriate vendor id. A couple
Assuming that a vendor extension is only available on hardware with appropriate vendor id is not correct because:
1) vendor A can allow vendor B to implement a custom extension defined by vendor B
2) vendor A and vendor B can jointly develop a RISC-V CPU where both vendors integrate their custom extensions.
It is best to identify a vendor extension independently with a "X<vendor_name><extension_name>" string to keep it simple and scalable.
Along these lines, each T-Head custom extension should have a "XThead<xyz>" name associated with it.
Quoted 4 lines
months ago I sent a patch to address this by handling vector extensions independently for each vendor [1]. I dropped the patch because it relied upon Heiko's T-Head vector extension support that he stopped working on. However, I can revive this patch so you can build off of it.
At least, the conditional operations don't need a hwprobe interface because an application is either compiled with or without conditional operations. In other words, effective use of conditional operation is only possible if compiler generates these instructions based on code patterns.
Quoted 4 lines
This scheme has the added benefit that vendors do not have to worry about conficting extensions, and the kernel does not have to act as a key registry for vendors.
How can vendor extensions conflict if they all follow the "X<vendor_name><extension_name>" naming scheme ?
Quoted 7 lines
What are your thoughts?
- Charlie
[1] https://lore.kernel.org/lkml/20230705-thead_vendor_extensions-v1-2-ad6915349c4d at rivosinc.com/
Regards,
Anup
Re: [PATCH v2 2/9] RISC-V: Detect XVentanaCondOps from ISA string
Quoted 56 lines · On Tue, Sep 26, 2023 at 9:38?AM Anup Patel <[email protected]> wrote:
Quoted 45 lines · On Mon, Sep 25, 2023 at 11:18?PM Charlie Jenkins <[email protected]> wrote:
Quoted 43 lines · Anup Patel
The Veyron-V1 CPU supports custom conditional arithmetic and conditional-select/move operations referred to as XVentanaCondOps extension. In fact, QEMU RISC-V also has support for emulating XVentanaCondOps extension.
Let us detect XVentanaCondOps extension from ISA string available through DT or ACPI.
Signed-off-by Anup Patel <[email protected]>Reviewed-by Andrew Jones <[email protected]>--- arch/riscv/include/asm/hwcap.h | 1 + arch/riscv/kernel/cpufeature.c | 1 + 2 files changed, 2 insertions(+)arch/riscv/include/asm/hwcap.h +1
-0@@ -59,6 +59,7 @@#define RISCV_ISA_EXT_ZIFENCEI 41#define RISCV_ISA_EXT_ZIHPM 42#define RISCV_ISA_EXT_SMSTATEEN 43 +#define RISCV_ISA_EXT_XVENTANACONDOPS 44#define RISCV_ISA_EXT_MAX 64arch/riscv/kernel/cpufeature.c +1
-1@@ -182,6 +182,7 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {__RISCV_ISA_EXT_DATA (svinval,RISCV_ISA_EXT_SVINVAL ),__RISCV_ISA_EXT_DATA (svnapot,RISCV_ISA_EXT_SVNAPOT ),__RISCV_ISA_EXT_DATA (svpbmt,RISCV_ISA_EXT_SVPBMT ), + __RISCV_ISA_EXT_DATA(xventanacondops, RISCV_ISA_EXT_XVENTANACONDOPS), };const size_t riscv_isa_ext_count =ARRAY_SIZE (riscv_isa_ext); --2.34.1
Quoted 8 lines
Quoted 4 lines
_______________________________________________
linux-riscv mailing list
linux-riscv at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscvI worry about storing vendor extensions in this file. Because vendor extensions are not standardized, they can only be expected to have the desired behavior on hardware with the appropriate vendor id. A couple
Quoted 4 lines
Assuming that a vendor extension is only available on hardware with appropriate vendor id is not correct because:
1) vendor A can allow vendor B to implement a custom extension defined by vendor B
Typo correction: "vendor A can allow vendor B to implement a custom extension defined by vendor A"
Quoted 32 lines
2) vendor A and vendor B can jointly develop a RISC-V CPU where both vendors integrate their custom extensions.
It is best to identify a vendor extension independently with a "X<vendor_name><extension_name>" string to keep it simple and scalable.
Along these lines, each T-Head custom extension should have a "XThead<xyz>" name associated with it.
Quoted 4 lines
months ago I sent a patch to address this by handling vector extensions independently for each vendor [1]. I dropped the patch because it relied upon Heiko's T-Head vector extension support that he stopped working on. However, I can revive this patch so you can build off of it.
At least, the conditional operations don't need a hwprobe interface because an application is either compiled with or without conditional operations. In other words, effective use of conditional operation is only possible if compiler generates these instructions based on code patterns.
Quoted 4 lines
This scheme has the added benefit that vendors do not have to worry about conficting extensions, and the kernel does not have to act as a key registry for vendors.
How can vendor extensions conflict if they all follow the "X<vendor_name><extension_name>" naming scheme ?
Quoted 3 lines
What are your thoughts?
Quoted 7 lines
Quoted 4 lines
- Charlie
[1] https://lore.kernel.org/lkml/20230705-thead_vendor_extensions-v1-2-ad6915349c4d at rivosinc.com/
Regards,
Anup
Regards,
Anup
Re: [PATCH v2 2/9] RISC-V: Detect XVentanaCondOps from ISA string
Quoted 57 lines · Anup Patel
Quoted 56 lines · On Tue, Sep 26, 2023 at 9:38?AM Anup Patel <[email protected]> wrote:
Quoted 53 lines · On Mon, Sep 25, 2023 at 11:18?PM Charlie Jenkins <[email protected]> wrote:
Quoted 43 lines · Anup Patel
The Veyron-V1 CPU supports custom conditional arithmetic and conditional-select/move operations referred to as XVentanaCondOps extension. In fact, QEMU RISC-V also has support for emulating XVentanaCondOps extension.
Let us detect XVentanaCondOps extension from ISA string available through DT or ACPI.
Signed-off-by Anup Patel <[email protected]>Reviewed-by Andrew Jones <[email protected]>--- arch/riscv/include/asm/hwcap.h | 1 + arch/riscv/kernel/cpufeature.c | 1 + 2 files changed, 2 insertions(+)arch/riscv/include/asm/hwcap.h +1
-0@@ -59,6 +59,7 @@#define RISCV_ISA_EXT_ZIFENCEI 41#define RISCV_ISA_EXT_ZIHPM 42#define RISCV_ISA_EXT_SMSTATEEN 43 +#define RISCV_ISA_EXT_XVENTANACONDOPS 44#define RISCV_ISA_EXT_MAX 64arch/riscv/kernel/cpufeature.c +1
-1@@ -182,6 +182,7 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {__RISCV_ISA_EXT_DATA (svinval,RISCV_ISA_EXT_SVINVAL ),__RISCV_ISA_EXT_DATA (svnapot,RISCV_ISA_EXT_SVNAPOT ),__RISCV_ISA_EXT_DATA (svpbmt,RISCV_ISA_EXT_SVPBMT ), + __RISCV_ISA_EXT_DATA(xventanacondops, RISCV_ISA_EXT_XVENTANACONDOPS), };const size_t riscv_isa_ext_count =ARRAY_SIZE (riscv_isa_ext); --2.34.1
Quoted 4 lines
_______________________________________________
linux-riscv mailing list
linux-riscv at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscvI worry about storing vendor extensions in this file. Because vendor extensions are not standardized, they can only be expected to have the desired behavior on hardware with the appropriate vendor id. A couple
Quoted 29 lines
Quoted 4 lines
Assuming that a vendor extension is only available on hardware with appropriate vendor id is not correct because:
1) vendor A can allow vendor B to implement a custom extension defined by vendor BTypo correction: "vendor A can allow vendor B to implement a custom extension defined by vendor A"
Quoted 21 lines
2) vendor A and vendor B can jointly develop a RISC-V CPU where both vendors integrate their custom extensions.
It is best to identify a vendor extension independently with a "X<vendor_name><extension_name>" string to keep it simple and scalable.
Along these lines, each T-Head custom extension should have a "XThead<xyz>" name associated with it.
Quoted 4 lines
months ago I sent a patch to address this by handling vector extensions independently for each vendor [1]. I dropped the patch because it relied upon Heiko's T-Head vector extension support that he stopped working on. However, I can revive this patch so you can build off of it.
At least, the conditional operations don't need a hwprobe interface because an application is either compiled with or without conditional operations. In other words, effective use of conditional operation is only possible if compiler generates these instructions based on code patterns.
I was conflating hwprobe with hwcap when I was thinking about this. However, I think it might still be beneficial to split out the vendor extensions. It is possible for vendors to implement each other's extensions but I don't expect that to be the average case. Because I do not expect this to be the average case, riscv_isa_ext becomes needlessly large as it has to contain the extensions of every vendor.
Quoted 13 lines
Quoted 13 lines
Quoted 4 lines
This scheme has the added benefit that vendors do not have to worry about conficting extensions, and the kernel does not have to act as a key registry for vendors.
How can vendor extensions conflict if they all follow the "X<vendor_name><extension_name>" naming scheme ?
Quoted 5 lines
What are your thoughts?
- Charlie
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
[1] https://lore.kernel.org/lkml/20230705-thead_vendor_extensions-v1-2-ad6915349c4d at rivosinc.com/
Regards,
AnupRegards,
Anup
- Charlie
PATCH v2 3/9 dt-bindings: riscv: Add Zicond extension entry
In reply to Anup PatelAdd an entry for the Zicond extension to the riscv,isa-extensions property.
--- Documentation/devicetree/bindings/riscv/extensions.yaml | 6 ++++++ 1 file changed, 6 insertions(+)
Documentation/devicetree/bindings/riscv/extensions.yaml +6 -0
@@ -225,6 +225,12 @@ properties: ratified in the 20191213 version of the unprivileged ISA specification. + - const: zicond + description: + The standard Zicond extension for conditional arithmetic and + conditional-select/move operations as ratified in commit 95cf1f9 + ("Add changes requested by Ved during signoff") of riscv-zicond. + - const: zicsr description: | The standard Zicsr extension for control and status register
Signature · 1 line
2.34.1
Re: [PATCH v2 3/9] dt-bindings: riscv: Add Zicond extension entry
Quoted 27 lines · Anup Patel
Add an entry for the Zicond extension to the riscv,isa-extensions property.
Signed-off-by Anup Patel <[email protected]>--- Documentation/devicetree/bindings/riscv/extensions.yaml | 6 ++++++ 1 file changed, 6 insertions(+)Documentation/devicetree/bindings/riscv/extensions.yaml +6
-0@@ -225,6 +225,12 @@ properties: ratified in the 20191213 version of the unprivileged ISA specification. + - const: zicond + description: + The standard Zicond extension for conditional arithmetic and + conditional-select/move operations as ratified in commit 95cf1f9 + ("Add changes requested by Ved during signoff") of riscv-zicond. + - const: zicsr description: | The standard Zicsr extension for control and status registerSignature · 1 line
2.34.1
PATCH v2 4/9 RISC-V: Detect Zicond from ISA string
In reply to Anup PatelThe RISC-V integer conditional (Zicond) operation extension defines standard conditional arithmetic and conditional-select/move operations which are inspired from the XVentanaCondOps extension. In fact, QEMU RISC-V also has support for emulating Zicond extension.
Let us detect Zicond extension from ISA string available through DT or ACPI.
--- arch/riscv/include/asm/hwcap.h | 1 + arch/riscv/kernel/cpufeature.c | 1 + 2 files changed, 2 insertions(+)
arch/riscv/include/asm/hwcap.h +1 -0
@@ -60,6 +60,7 @@#define RISCV_ISA_EXT_ZIHPM 42#define RISCV_ISA_EXT_SMSTATEEN 43#define RISCV_ISA_EXT_XVENTANACONDOPS 44 +#define RISCV_ISA_EXT_ZICOND 45#define RISCV_ISA_EXT_MAX 64
arch/riscv/kernel/cpufeature.c +1 -0
@@ -167,6 +167,7 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {__RISCV_ISA_EXT_DATA (zicbom,RISCV_ISA_EXT_ZICBOM ),__RISCV_ISA_EXT_DATA (zicboz,RISCV_ISA_EXT_ZICBOZ ),__RISCV_ISA_EXT_DATA (zicntr,RISCV_ISA_EXT_ZICNTR ), +__RISCV_ISA_EXT_DATA (zicond,RISCV_ISA_EXT_ZICOND ),__RISCV_ISA_EXT_DATA (zicsr,RISCV_ISA_EXT_ZICSR ),__RISCV_ISA_EXT_DATA (zifencei,RISCV_ISA_EXT_ZIFENCEI ), __RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
Signature · 1 line
2.34.1
Re: [PATCH v2 4/9] RISC-V: Detect Zicond from ISA string
Quoted 41 lines · Anup Patel
The RISC-V integer conditional (Zicond) operation extension defines standard conditional arithmetic and conditional-select/move operations which are inspired from the XVentanaCondOps extension. In fact, QEMU RISC-V also has support for emulating Zicond extension.
Let us detect Zicond extension from ISA string available through DT or ACPI.
Signed-off-by Anup Patel <[email protected]>--- arch/riscv/include/asm/hwcap.h | 1 + arch/riscv/kernel/cpufeature.c | 1 + 2 files changed, 2 insertions(+)arch/riscv/include/asm/hwcap.h +1
-0@@ -60,6 +60,7 @@#define RISCV_ISA_EXT_ZIHPM 42#define RISCV_ISA_EXT_SMSTATEEN 43#define RISCV_ISA_EXT_XVENTANACONDOPS 44 +#define RISCV_ISA_EXT_ZICOND 45#define RISCV_ISA_EXT_MAX 64arch/riscv/kernel/cpufeature.c +1
-0@@ -167,6 +167,7 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {__RISCV_ISA_EXT_DATA (zicbom,RISCV_ISA_EXT_ZICBOM ),__RISCV_ISA_EXT_DATA (zicboz,RISCV_ISA_EXT_ZICBOZ ),__RISCV_ISA_EXT_DATA (zicntr,RISCV_ISA_EXT_ZICNTR ), +__RISCV_ISA_EXT_DATA (zicond,RISCV_ISA_EXT_ZICOND ),__RISCV_ISA_EXT_DATA (zicsr,RISCV_ISA_EXT_ZICSR ),__RISCV_ISA_EXT_DATA (zifencei,RISCV_ISA_EXT_ZIFENCEI ), __RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),Signature · 1 line
2.34.1
PATCH v2 5/9 RISC-V: KVM: Allow XVentanaCondOps extension for Guest/VM
In reply to Anup PatelWe extend the KVM ISA extension ONE_REG interface to allow KVM user space to detect and enable XVentanaCondOps extension for Guest/VM.
--- arch/riscv/include/uapi/asm/kvm.h | 1 + arch/riscv/kvm/vcpu_onereg.c | 2 ++ 2 files changed, 3 insertions(+)
arch/riscv/include/uapi/asm/kvm.h +1 -0
@@ -138,6 +138,7 @@ enum KVM_RISCV_ISA_EXT_ID {KVM_RISCV_ISA_EXT_ZIFENCEI ,KVM_RISCV_ISA_EXT_ZIHPM ,KVM_RISCV_ISA_EXT_SMSTATEEN , +KVM_RISCV_ISA_EXT_XVENTANACONDOPS , KVM_RISCV_ISA_EXT_MAX, };
arch/riscv/kvm/vcpu_onereg.c +2 -0
@@ -40,6 +40,7 @@ static const unsigned long kvm_isa_ext_arr[] = {KVM_ISA_EXT_ARR (SVINVAL ),KVM_ISA_EXT_ARR (SVNAPOT ),KVM_ISA_EXT_ARR (SVPBMT ), +KVM_ISA_EXT_ARR (XVENTANACONDOPS ),KVM_ISA_EXT_ARR (ZBA ),KVM_ISA_EXT_ARR (ZBB ), KVM_ISA_EXT_ARR(ZBS),
@@ -89,6 +90,7 @@ static bool kvm_riscv_vcpu_isa_disable_allowed(unsigned long ext)case KVM_RISCV_ISA_EXT_SSTC :case KVM_RISCV_ISA_EXT_SVINVAL :case KVM_RISCV_ISA_EXT_SVNAPOT : +case KVM_RISCV_ISA_EXT_XVENTANACONDOPS :case KVM_RISCV_ISA_EXT_ZBA :case KVM_RISCV_ISA_EXT_ZBB :case KVM_RISCV_ISA_EXT_ZBS :
Signature · 1 line
2.34.1
PATCH v2 6/9 RISC-V: KVM: Allow Zicond extension for Guest/VM
In reply to Anup PatelWe extend the KVM ISA extension ONE_REG interface to allow KVM user space to detect and enable Zicond extension for Guest/VM.
--- arch/riscv/include/uapi/asm/kvm.h | 1 + arch/riscv/kvm/vcpu_onereg.c | 2 ++ 2 files changed, 3 insertions(+)
arch/riscv/include/uapi/asm/kvm.h +1 -0
@@ -139,6 +139,7 @@ enum KVM_RISCV_ISA_EXT_ID {KVM_RISCV_ISA_EXT_ZIHPM ,KVM_RISCV_ISA_EXT_SMSTATEEN ,KVM_RISCV_ISA_EXT_XVENTANACONDOPS , +KVM_RISCV_ISA_EXT_ZICOND , KVM_RISCV_ISA_EXT_MAX, };
arch/riscv/kvm/vcpu_onereg.c +2 -0
@@ -47,6 +47,7 @@ static const unsigned long kvm_isa_ext_arr[] = {KVM_ISA_EXT_ARR (ZICBOM ),KVM_ISA_EXT_ARR (ZICBOZ ),KVM_ISA_EXT_ARR (ZICNTR ), +KVM_ISA_EXT_ARR (ZICOND ),KVM_ISA_EXT_ARR (ZICSR ),KVM_ISA_EXT_ARR (ZIFENCEI ), KVM_ISA_EXT_ARR(ZIHINTPAUSE),
@@ -95,6 +96,7 @@ static bool kvm_riscv_vcpu_isa_disable_allowed(unsigned long ext)case KVM_RISCV_ISA_EXT_ZBB :case KVM_RISCV_ISA_EXT_ZBS :case KVM_RISCV_ISA_EXT_ZICNTR : +case KVM_RISCV_ISA_EXT_ZICOND :case KVM_RISCV_ISA_EXT_ZICSR :case KVM_RISCV_ISA_EXT_ZIFENCEI :case KVM_RISCV_ISA_EXT_ZIHINTPAUSE :
Signature · 1 line
2.34.1
PATCH v2 7/9 KVM: riscv: selftests: Add senvcfg register to get-reg-list test
In reply to Anup PatelWe have a new senvcfg register in the general CSR ONE_REG interface so let us add it to get-reg-list test.
--- tools/testing/selftests/kvm/riscv/get-reg-list.c | 3 +++ 1 file changed, 3 insertions(+)
tools/testing/selftests/kvm/riscv/get-reg-list.c +3 -0
@@ -211,6 +211,8 @@ static const char *general_csr_id_to_str(__u64 reg_off)return RISCV_CSR_GENERAL (satp);case KVM_REG_RISCV_CSR_REG (scounteren):return RISCV_CSR_GENERAL (scounteren); +case KVM_REG_RISCV_CSR_REG (senvcfg): +return RISCV_CSR_GENERAL (senvcfg); }TEST_FAIL ("Unknown general csr reg: 0x%llx" , reg_off);
@@ -540,6 +542,7 @@ static __u64 base_regs[] = {KVM_REG_RISCV |KVM_REG_SIZE_ULONG |KVM_REG_RISCV_CSR |KVM_REG_RISCV_CSR_GENERAL |KVM_REG_RISCV_CSR_REG (sip),KVM_REG_RISCV |KVM_REG_SIZE_ULONG |KVM_REG_RISCV_CSR |KVM_REG_RISCV_CSR_GENERAL |KVM_REG_RISCV_CSR_REG (satp),KVM_REG_RISCV |KVM_REG_SIZE_ULONG |KVM_REG_RISCV_CSR |KVM_REG_RISCV_CSR_GENERAL |KVM_REG_RISCV_CSR_REG (scounteren), +KVM_REG_RISCV |KVM_REG_SIZE_ULONG |KVM_REG_RISCV_CSR |KVM_REG_RISCV_CSR_GENERAL |KVM_REG_RISCV_CSR_REG (senvcfg),KVM_REG_RISCV |KVM_REG_SIZE_U64 |KVM_REG_RISCV_TIMER |KVM_REG_RISCV_TIMER_REG (frequency),KVM_REG_RISCV |KVM_REG_SIZE_U64 |KVM_REG_RISCV_TIMER |KVM_REG_RISCV_TIMER_REG (time), KVM_REG_RISCV | KVM_REG_SIZE_U64 | KVM_REG_RISCV_TIMER | KVM_REG_RISCV_TIMER_REG(compare),
Signature · 1 line
2.34.1
PATCH v2 8/9 KVM: riscv: selftests: Add smstateen registers to get-reg-list test
In reply to Anup PatelWe have a new smstateen registers as separate sub-type of CSR ONE_REG interface so let us add these registers to get-reg-list test.
--- .../selftests/kvm/riscv/get-reg-list.c | 34 +++++++++++++++++++ 1 file changed, 34 insertions(+)
tools/testing/selftests/kvm/riscv/get-reg-list.c +34 -0
@@ -36,6 +36,7 @@ bool filter_reg(__u64 reg)case KVM_REG_RISCV_ISA_EXT |KVM_RISCV_ISA_EXT_I :case KVM_REG_RISCV_ISA_EXT |KVM_RISCV_ISA_EXT_M :case KVM_REG_RISCV_ISA_EXT |KVM_RISCV_ISA_EXT_V : +case KVM_REG_RISCV_ISA_EXT |KVM_RISCV_ISA_EXT_SMSTATEEN :case KVM_REG_RISCV_ISA_EXT |KVM_RISCV_ISA_EXT_SSAIA :case KVM_REG_RISCV_ISA_EXT |KVM_RISCV_ISA_EXT_SSTC :case KVM_REG_RISCV_ISA_EXT |KVM_RISCV_ISA_EXT_SVINVAL :
@@ -186,6 +187,8 @@ static const char *core_id_to_str(const char *prefix, __u64 id) "KVM_REG_RISCV_CSR_GENERAL | KVM_REG_RISCV_CSR_REG(" #csr ")"#define RISCV_CSR_AIA (csr) \ "KVM_REG_RISCV_CSR_AIA | KVM_REG_RISCV_CSR_REG(" #csr ")" +#define RISCV_CSR_SMSTATEEN (csr) \ + "KVM_REG_RISCV_CSR_SMSTATEEN | KVM_REG_RISCV_CSR_REG(" #csr ")"static const char *general_csr_id_to_str (__u64 reg_off) {
@@ -243,6 +246,18 @@ static const char *aia_csr_id_to_str(__u64 reg_off)return NULL ; } +static const char *smstateen_csr_id_to_str (__u64 reg_off) +{ +/* reg_off is the offset into struct kvm_riscv_smstateen_csr */ +switch (reg_off) { +case KVM_REG_RISCV_CSR_SMSTATEEN_REG (sstateen0): +return RISCV_CSR_SMSTATEEN (sstateen0); + } + +TEST_FAIL ("Unknown smstateen csr reg: 0x%llx" , reg_off); +return NULL ; +} +static const char *csr_id_to_str (const char *prefix,__u64 id) {__u64 reg_off = id & ~(REG_MASK |KVM_REG_RISCV_CSR );
@@ -255,6 +270,8 @@ static const char *csr_id_to_str(const char *prefix, __u64 id)return general_csr_id_to_str (reg_off);case KVM_REG_RISCV_CSR_AIA :return aia_csr_id_to_str (reg_off); +case KVM_REG_RISCV_CSR_SMSTATEEN : +return smstateen_csr_id_to_str (reg_off); }TEST_FAIL ("%s: Unknown csr subtype: 0x%llx" , prefix, reg_subtype);
@@ -332,6 +349,7 @@ static const char *isa_ext_id_to_str(__u64 id)KVM_ISA_EXT_ARR (I ),KVM_ISA_EXT_ARR (M ),KVM_ISA_EXT_ARR (V ), +KVM_ISA_EXT_ARR (SMSTATEEN ),KVM_ISA_EXT_ARR (SSAIA ),KVM_ISA_EXT_ARR (SSTC ), KVM_ISA_EXT_ARR(SVINVAL),
@@ -637,6 +655,11 @@ static __u64 aia_regs[] = { KVM_REG_RISCV | KVM_REG_SIZE_ULONG | KVM_REG_RISCV_ISA_EXT | KVM_RISCV_ISA_EXT_SSAIA, }; +static __u64 smstateen_regs[] = { +KVM_REG_RISCV |KVM_REG_SIZE_ULONG |KVM_REG_RISCV_CSR |KVM_REG_RISCV_CSR_SMSTATEEN |KVM_REG_RISCV_CSR_SMSTATEEN_REG (sstateen0), +KVM_REG_RISCV |KVM_REG_SIZE_ULONG |KVM_REG_RISCV_ISA_EXT |KVM_RISCV_ISA_EXT_SMSTATEEN , +}; +static __u64 fp_f_regs[] = {KVM_REG_RISCV |KVM_REG_SIZE_U32 |KVM_REG_RISCV_FP_F |KVM_REG_RISCV_FP_F_REG (f[0 ]),KVM_REG_RISCV |KVM_REG_SIZE_U32 |KVM_REG_RISCV_FP_F |KVM_REG_RISCV_FP_F_REG (f[1 ]),
@@ -744,6 +767,8 @@ static __u64 fp_d_regs[] = { {"zihpm", .feature = KVM_RISCV_ISA_EXT_ZIHPM, .regs = zihpm_regs, .regs_n = ARRAY_SIZE(zihpm_regs),}#define AIA_REGS_SUBLIST \ {"aia", .feature = KVM_RISCV_ISA_EXT_SSAIA, .regs = aia_regs, .regs_n = ARRAY_SIZE(aia_regs),} +#define SMSTATEEN_REGS_SUBLIST \ + {"smstateen", .feature = KVM_RISCV_ISA_EXT_SMSTATEEN, .regs = smstateen_regs, .regs_n = ARRAY_SIZE(smstateen_regs),}#define FP_F_REGS_SUBLIST \ {"fp_f", .feature = KVM_RISCV_ISA_EXT_F, .regs = fp_f_regs, \ .regs_n = ARRAY_SIZE(fp_f_regs),}
@@ -871,6 +896,14 @@ static struct vcpu_reg_list aia_config = { }, }; +static struct vcpu_reg_list smstateen_config = { + .sublists = { +BASE_SUBLIST , +SMSTATEEN_REGS_SUBLIST , + {0 }, + }, +}; +static struct vcpu_reg_list fp_f_config = { .sublists = {BASE_SUBLIST ,
@@ -903,6 +936,7 @@ struct vcpu_reg_list *vcpu_configs[] = { &zifencei_config, &zihpm_config, &aia_config, + &smstateen_config, &fp_f_config, &fp_d_config, };
Signature · 1 line
2.34.1
PATCH v2 9/9 KVM: riscv: selftests: Add condops extensions to get-reg-list test
In reply to Anup PatelWe have a new conditional operations related ISA extensions so let us add these extensions to get-reg-list test.
--- .../selftests/kvm/riscv/get-reg-list.c | 34 +++++++++++++++++++ 1 file changed, 34 insertions(+)
tools/testing/selftests/kvm/riscv/get-reg-list.c +34 -0
@@ -42,12 +42,14 @@ bool filter_reg(__u64 reg)case KVM_REG_RISCV_ISA_EXT |KVM_RISCV_ISA_EXT_SVINVAL :case KVM_REG_RISCV_ISA_EXT |KVM_RISCV_ISA_EXT_SVNAPOT :case KVM_REG_RISCV_ISA_EXT |KVM_RISCV_ISA_EXT_SVPBMT : +case KVM_REG_RISCV_ISA_EXT |KVM_RISCV_ISA_EXT_XVENTANACONDOPS :case KVM_REG_RISCV_ISA_EXT |KVM_RISCV_ISA_EXT_ZBA :case KVM_REG_RISCV_ISA_EXT |KVM_RISCV_ISA_EXT_ZBB :case KVM_REG_RISCV_ISA_EXT |KVM_RISCV_ISA_EXT_ZBS :case KVM_REG_RISCV_ISA_EXT |KVM_RISCV_ISA_EXT_ZICBOM :case KVM_REG_RISCV_ISA_EXT |KVM_RISCV_ISA_EXT_ZICBOZ :case KVM_REG_RISCV_ISA_EXT |KVM_RISCV_ISA_EXT_ZICNTR : +case KVM_REG_RISCV_ISA_EXT |KVM_RISCV_ISA_EXT_ZICOND :case KVM_REG_RISCV_ISA_EXT |KVM_RISCV_ISA_EXT_ZICSR :case KVM_REG_RISCV_ISA_EXT |KVM_RISCV_ISA_EXT_ZIFENCEI :case KVM_REG_RISCV_ISA_EXT |KVM_RISCV_ISA_EXT_ZIHINTPAUSE :
@@ -355,12 +357,14 @@ static const char *isa_ext_id_to_str(__u64 id)KVM_ISA_EXT_ARR (SVINVAL ),KVM_ISA_EXT_ARR (SVNAPOT ),KVM_ISA_EXT_ARR (SVPBMT ), +KVM_ISA_EXT_ARR (XVENTANACONDOPS ),KVM_ISA_EXT_ARR (ZBA ),KVM_ISA_EXT_ARR (ZBB ),KVM_ISA_EXT_ARR (ZBS ),KVM_ISA_EXT_ARR (ZICBOM ),KVM_ISA_EXT_ARR (ZICBOZ ),KVM_ISA_EXT_ARR (ZICNTR ), +KVM_ISA_EXT_ARR (ZICOND ),KVM_ISA_EXT_ARR (ZICSR ),KVM_ISA_EXT_ARR (ZIFENCEI ), KVM_ISA_EXT_ARR(ZIHINTPAUSE),
@@ -632,6 +636,10 @@ static __u64 zicntr_regs[] = { KVM_REG_RISCV | KVM_REG_SIZE_ULONG | KVM_REG_RISCV_ISA_EXT | KVM_RISCV_ISA_EXT_ZICNTR, }; +static __u64 zicond_regs[] = { +KVM_REG_RISCV |KVM_REG_SIZE_ULONG |KVM_REG_RISCV_ISA_EXT |KVM_RISCV_ISA_EXT_ZICOND , +}; +static __u64 zicsr_regs[] = {KVM_REG_RISCV |KVM_REG_SIZE_ULONG |KVM_REG_RISCV_ISA_EXT |KVM_RISCV_ISA_EXT_ZICSR , };
@@ -644,6 +652,10 @@ static __u64 zihpm_regs[] = { KVM_REG_RISCV | KVM_REG_SIZE_ULONG | KVM_REG_RISCV_ISA_EXT | KVM_RISCV_ISA_EXT_ZIHPM, }; +static __u64 xventanacondops_regs[] = { +KVM_REG_RISCV |KVM_REG_SIZE_ULONG |KVM_REG_RISCV_ISA_EXT |KVM_RISCV_ISA_EXT_XVENTANACONDOPS , +}; +static __u64 aia_regs[] = {KVM_REG_RISCV |KVM_REG_SIZE_ULONG |KVM_REG_RISCV_CSR |KVM_REG_RISCV_CSR_AIA |KVM_REG_RISCV_CSR_AIA_REG (siselect),KVM_REG_RISCV |KVM_REG_SIZE_ULONG |KVM_REG_RISCV_CSR |KVM_REG_RISCV_CSR_AIA |KVM_REG_RISCV_CSR_AIA_REG (iprio1),
@@ -759,12 +771,16 @@ static __u64 fp_d_regs[] = { {"zbs", .feature = KVM_RISCV_ISA_EXT_ZBS, .regs = zbs_regs, .regs_n = ARRAY_SIZE(zbs_regs),}#define ZICNTR_REGS_SUBLIST \ {"zicntr", .feature = KVM_RISCV_ISA_EXT_ZICNTR, .regs = zicntr_regs, .regs_n = ARRAY_SIZE(zicntr_regs),} +#define ZICOND_REGS_SUBLIST \ + {"zicond", .feature = KVM_RISCV_ISA_EXT_ZICOND, .regs = zicond_regs, .regs_n = ARRAY_SIZE(zicond_regs),}#define ZICSR_REGS_SUBLIST \ {"zicsr", .feature = KVM_RISCV_ISA_EXT_ZICSR, .regs = zicsr_regs, .regs_n = ARRAY_SIZE(zicsr_regs),}#define ZIFENCEI_REGS_SUBLIST \ {"zifencei", .feature = KVM_RISCV_ISA_EXT_ZIFENCEI, .regs = zifencei_regs, .regs_n = ARRAY_SIZE(zifencei_regs),}#define ZIHPM_REGS_SUBLIST \ {"zihpm", .feature = KVM_RISCV_ISA_EXT_ZIHPM, .regs = zihpm_regs, .regs_n = ARRAY_SIZE(zihpm_regs),} +#define XVENTANACONDOPS_REGS_SUBLIST \ + {"xventanacondops", .feature = KVM_RISCV_ISA_EXT_XVENTANACONDOPS, .regs = xventanacondops_regs, .regs_n = ARRAY_SIZE(xventanacondops_regs),}#define AIA_REGS_SUBLIST \ {"aia", .feature = KVM_RISCV_ISA_EXT_SSAIA, .regs = aia_regs, .regs_n = ARRAY_SIZE(aia_regs),}#define SMSTATEEN_REGS_SUBLIST \
@@ -864,6 +880,14 @@ static struct vcpu_reg_list zicntr_config = { }, }; +static struct vcpu_reg_list zicond_config = { + .sublists = { +BASE_SUBLIST , +ZICOND_REGS_SUBLIST , + {0 }, + }, +}; +static struct vcpu_reg_list zicsr_config = { .sublists = {BASE_SUBLIST ,
@@ -888,6 +912,14 @@ static struct vcpu_reg_list zihpm_config = { }, }; +static struct vcpu_reg_list xventanacondops_config = { + .sublists = { +BASE_SUBLIST , +XVENTANACONDOPS_REGS_SUBLIST , + {0 }, + }, +}; +static struct vcpu_reg_list aia_config = { .sublists = {BASE_SUBLIST ,
@@ -932,9 +964,11 @@ struct vcpu_reg_list *vcpu_configs[] = { &zbb_config, &zbs_config, &zicntr_config, + &zicond_config, &zicsr_config, &zifencei_config, &zihpm_config, + &xventanacondops_config, &aia_config, &smstateen_config, &fp_f_config,
Signature · 1 line
2.34.1
Re: [PATCH v2 9/9] KVM: riscv: selftests: Add condops extensions to get-reg-list test
Quoted 8 lines · Anup Patel
We have a new conditional operations related ISA extensions so let us add these extensions to get-reg-list test.
Signed-off-by Anup Patel <[email protected]>--- .../selftests/kvm/riscv/get-reg-list.c | 34 +++++++++++++++++++ 1 file changed, 34 insertions(+)
Quoted 17 lines · Anup Patel
This series extends KVM RISC-V to allow Guest/VM discover and use conditional operations related ISA extensions (namely XVentanaCondOps and Zicond).
To try these patches, use KVMTOOL from
riscv_zbx_zicntr_smstateen_condops_v1branch at: https://github.com/avpatel/kvmtool.gitThese patches are based upon the latest
riscv_kvm_queueand can also be found in theriscv_kvm_condops_v2branch at:
https://github.com/avpatel/linux.gitChanges since v1:
- Rebased the series onriscv_kvm_queue
- Split PATCH1 and PATCH2 of v1 series into two patches
- Added separate test configs for XVentanaCondOps and Zicond in PATCH7 of v1 series.
Quoted 5 lines
Anup Patel (9):
dt-bindings: riscv: Add XVentanaCondOps extension entry
RISC-V: Detect XVentanaCondOps from ISA string
dt-bindings: riscv: Add Zicond extension entry
RISC-V: Detect Zicond from ISA string
For these 4:
Thanks for splitting it out,
Conor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/kvm-riscv/attachments/20230925/44474702/attachment.sig>
Quoted 18 lines · Conor Dooley
Quoted 17 lines · Anup Patel
This series extends KVM RISC-V to allow Guest/VM discover and use conditional operations related ISA extensions (namely XVentanaCondOps and Zicond).
To try these patches, use KVMTOOL from
riscv_zbx_zicntr_smstateen_condops_v1branch at: https://github.com/avpatel/kvmtool.gitThese patches are based upon the latest
riscv_kvm_queueand can also be found in theriscv_kvm_condops_v2branch at:
https://github.com/avpatel/linux.gitChanges since v1:
- Rebased the series onriscv_kvm_queue
- Split PATCH1 and PATCH2 of v1 series into two patches
- Added separate test configs for XVentanaCondOps and Zicond in PATCH7 of v1 series.
Quoted 8 lines
Quoted 5 lines
Anup Patel (9):
dt-bindings: riscv: Add XVentanaCondOps extension entry
RISC-V: Detect XVentanaCondOps from ISA string
dt-bindings: riscv: Add Zicond extension entry
RISC-V: Detect Zicond from ISA stringFor these 4:
Reviewed-by Conor Dooley <[email protected]>
Actually, now that I think of it, I'm going to temporarily un-review this. From patch-acceptance.rst:
| Additionally, the RISC-V specification allows implementers to create | their own custom extensions. These custom extensions aren't required | to go through any review or ratification process by the RISC-V | Foundation. To avoid the maintenance complexity and potential | performance impact of adding kernel code for implementor-specific | RISC-V extensions, we'll only consider patches for extensions that either: | | - Have been officially frozen or ratified by the RISC-V Foundation, or | - Have been implemented in hardware that is widely available, per standard | Linux practice.
The xventanacondops bits don't qualify under the first entry, and I
don't think they qualify under the second yet. Am I wrong?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/kvm-riscv/attachments/20230925/6a3609a7/attachment.sig>
Quoted 42 lines · On Mon, Sep 25, 2023 at 9:07?PM Conor Dooley <[email protected]> wrote:
Quoted 18 lines · Conor Dooley
Quoted 17 lines · Anup Patel
This series extends KVM RISC-V to allow Guest/VM discover and use conditional operations related ISA extensions (namely XVentanaCondOps and Zicond).
To try these patches, use KVMTOOL from
riscv_zbx_zicntr_smstateen_condops_v1branch at: https://github.com/avpatel/kvmtool.gitThese patches are based upon the latest
riscv_kvm_queueand can also be found in theriscv_kvm_condops_v2branch at:
https://github.com/avpatel/linux.gitChanges since v1:
- Rebased the series onriscv_kvm_queue
- Split PATCH1 and PATCH2 of v1 series into two patches
- Added separate test configs for XVentanaCondOps and Zicond in PATCH7 of v1 series.Quoted 8 lines
Quoted 5 lines
Anup Patel (9):
dt-bindings: riscv: Add XVentanaCondOps extension entry
RISC-V: Detect XVentanaCondOps from ISA string
dt-bindings: riscv: Add Zicond extension entry
RISC-V: Detect Zicond from ISA stringFor these 4:
Reviewed-by Conor Dooley <[email protected]>Actually, now that I think of it, I'm going to temporarily un-review this. From
patch-acceptance.rst:| Additionally, the RISC-V specification allows implementers to create | their own custom extensions. These custom extensions aren't required | to go through any review or ratification process by the RISC-V | Foundation. To avoid the maintenance complexity and potential | performance impact of adding kernel code for implementor-specific | RISC-V extensions, we'll only consider patches for extensions that either: | | - Have been officially frozen or ratified by the RISC-V Foundation, or | - Have been implemented in hardware that is widely available, per standard | Linux practice.
Quoted 2 lines
The xventanacondops bits don't qualify under the first entry, and I don't think they qualify under the second yet. Am I wrong?
The Ventana Veyron V1 was announced in Dec 2022 at RISC-V summit followed by press releases:
https://www.ventanamicro.com/ventana-introduces-veyron-worlds-first-data-center-class-risc-v-cpu-product-family/
https://www.embedded.com/ventana-reveals-risc-v-cpu-compute-chiplet-for-data-center/
https://www.prnewswire.com/news-releases/ventana-introduces-veyron-worlds-first-data-center-class-risc-v-cpu-product-family-301700985.html
@Palmer if the above looks good to you then please ack PATCH1-to-4
Thanks,
Anup
Quoted 46 lines · Anup Patel
Quoted 42 lines · On Mon, Sep 25, 2023 at 9:07?PM Conor Dooley <[email protected]> wrote:
Quoted 18 lines · Conor Dooley
Quoted 17 lines · Anup Patel
This series extends KVM RISC-V to allow Guest/VM discover and use conditional operations related ISA extensions (namely XVentanaCondOps and Zicond).
To try these patches, use KVMTOOL from
riscv_zbx_zicntr_smstateen_condops_v1branch at: https://github.com/avpatel/kvmtool.gitThese patches are based upon the latest
riscv_kvm_queueand can also be found in theriscv_kvm_condops_v2branch at:
https://github.com/avpatel/linux.gitChanges since v1:
- Rebased the series onriscv_kvm_queue
- Split PATCH1 and PATCH2 of v1 series into two patches
- Added separate test configs for XVentanaCondOps and Zicond in PATCH7 of v1 series.Quoted 8 lines
Quoted 5 lines
Anup Patel (9):
dt-bindings: riscv: Add XVentanaCondOps extension entry
RISC-V: Detect XVentanaCondOps from ISA string
dt-bindings: riscv: Add Zicond extension entry
RISC-V: Detect Zicond from ISA stringFor these 4:
Reviewed-by Conor Dooley <[email protected]>Actually, now that I think of it, I'm going to temporarily un-review this. From
patch-acceptance.rst:| Additionally, the RISC-V specification allows implementers to create | their own custom extensions. These custom extensions aren't required | to go through any review or ratification process by the RISC-V | Foundation. To avoid the maintenance complexity and potential | performance impact of adding kernel code for implementor-specific | RISC-V extensions, we'll only consider patches for extensions that either: | | - Have been officially frozen or ratified by the RISC-V Foundation, or | - Have been implemented in hardware that is widely available, per standard | Linux practice.Quoted 2 lines
The xventanacondops bits don't qualify under the first entry, and I don't think they qualify under the second yet. Am I wrong?
Quoted 7 lines
The Ventana Veyron V1 was announced in Dec 2022 at RISC-V summit followed by press releases:
https://www.ventanamicro.com/ventana-introduces-veyron-worlds-first-data-center-class-risc-v-cpu-product-family/
https://www.embedded.com/ventana-reveals-risc-v-cpu-compute-chiplet-for-data-center/
https://www.prnewswire.com/news-releases/ventana-introduces-veyron-worlds-first-data-center-class-risc-v-cpu-product-family-301700985.html@Palmer if the above looks good to you then please ack PATCH1-to-4
These are announcements AFAICT & not an indication of "being implemented
in hardware that is widely available".
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/kvm-riscv/attachments/20230927/f738d33b/attachment-0001.sig>
Palmer Dabbelt
maintainerQuoted 53 lines · Conor Dooley
Quoted 52 lines · Anup Patel
Quoted 42 lines · On Mon, Sep 25, 2023 at 9:07?PM Conor Dooley <[email protected]> wrote:
Quoted 18 lines · Conor Dooley
Quoted 17 lines · Anup Patel
This series extends KVM RISC-V to allow Guest/VM discover and use conditional operations related ISA extensions (namely XVentanaCondOps and Zicond).
To try these patches, use KVMTOOL from
riscv_zbx_zicntr_smstateen_condops_v1branch at: https://github.com/avpatel/kvmtool.gitThese patches are based upon the latest
riscv_kvm_queueand can also be found in theriscv_kvm_condops_v2branch at:
https://github.com/avpatel/linux.gitChanges since v1:
- Rebased the series onriscv_kvm_queue
- Split PATCH1 and PATCH2 of v1 series into two patches
- Added separate test configs for XVentanaCondOps and Zicond in PATCH7 of v1 series.Quoted 8 lines
Quoted 5 lines
Anup Patel (9):
dt-bindings: riscv: Add XVentanaCondOps extension entry
RISC-V: Detect XVentanaCondOps from ISA string
dt-bindings: riscv: Add Zicond extension entry
RISC-V: Detect Zicond from ISA stringFor these 4:
Reviewed-by Conor Dooley <[email protected]>Actually, now that I think of it, I'm going to temporarily un-review this. From
patch-acceptance.rst:| Additionally, the RISC-V specification allows implementers to create | their own custom extensions. These custom extensions aren't required | to go through any review or ratification process by the RISC-V | Foundation. To avoid the maintenance complexity and potential | performance impact of adding kernel code for implementor-specific | RISC-V extensions, we'll only consider patches for extensions that either: | | - Have been officially frozen or ratified by the RISC-V Foundation, or | - Have been implemented in hardware that is widely available, per standard | Linux practice.Quoted 2 lines
The xventanacondops bits don't qualify under the first entry, and I don't think they qualify under the second yet. Am I wrong?
The Ventana Veyron V1 was announced in Dec 2022 at RISC-V summit followed by press releases:
https://www.ventanamicro.com/ventana-introduces-veyron-worlds-first-data-center-class-risc-v-cpu-product-family/
https://www.embedded.com/ventana-reveals-risc-v-cpu-compute-chiplet-for-data-center/
https://www.prnewswire.com/news-releases/ventana-introduces-veyron-worlds-first-data-center-class-risc-v-cpu-product-family-301700985.html
Quoted 4 lines
Quoted 1 line
@Palmer if the above looks good to you then please ack PATCH1-to-4
These are announcements AFAICT & not an indication of "being implemented in hardware that is widely available".
The second two look to just be news articles quoting the first without any real new information, at least just from skimming them -- sorry if I missed something, though.
The article says "SDK released with necessary software already ported to Veyron" and "Veyron V1 Development Platform available", but aside from quotes of the press release I can't find information on either of those (or anything VT1 related, as there were some naming ambiguities).
Anup said during the call that they're still bringing up the chip and haven't started sampling yet, which usually means things are far from publicly availiable. I thought I heard him say that these press releases would say the chip is sampling 2H23, but I can't find anything in them about sampling.
Anup also said it's availiable as IP and I remember something at Hot Chips talking about an example place and route for a VT1, which also sounds very much like a chip that's not availiable yet -- usually if there's a chip folks are a lot more concrete about that sort of thing.
So is there you can point to about this chip actually being publicly availiable?
Quoted 75 lines · On Wed, Sep 27, 2023 at 8:31?PM Palmer Dabbelt <[email protected]> wrote:
Quoted 53 lines · Conor Dooley
Quoted 52 lines · Anup Patel
Quoted 42 lines · On Mon, Sep 25, 2023 at 9:07?PM Conor Dooley <[email protected]> wrote:
Quoted 18 lines · Conor Dooley
Quoted 17 lines · Anup Patel
This series extends KVM RISC-V to allow Guest/VM discover and use conditional operations related ISA extensions (namely XVentanaCondOps and Zicond).
To try these patches, use KVMTOOL from
riscv_zbx_zicntr_smstateen_condops_v1branch at: https://github.com/avpatel/kvmtool.gitThese patches are based upon the latest
riscv_kvm_queueand can also be found in theriscv_kvm_condops_v2branch at:
https://github.com/avpatel/linux.gitChanges since v1:
- Rebased the series onriscv_kvm_queue
- Split PATCH1 and PATCH2 of v1 series into two patches
- Added separate test configs for XVentanaCondOps and Zicond in PATCH7 of v1 series.Quoted 8 lines
Quoted 5 lines
Anup Patel (9):
dt-bindings: riscv: Add XVentanaCondOps extension entry
RISC-V: Detect XVentanaCondOps from ISA string
dt-bindings: riscv: Add Zicond extension entry
RISC-V: Detect Zicond from ISA stringFor these 4:
Reviewed-by Conor Dooley <[email protected]>Actually, now that I think of it, I'm going to temporarily un-review this. From
patch-acceptance.rst:| Additionally, the RISC-V specification allows implementers to create | their own custom extensions. These custom extensions aren't required | to go through any review or ratification process by the RISC-V | Foundation. To avoid the maintenance complexity and potential | performance impact of adding kernel code for implementor-specific | RISC-V extensions, we'll only consider patches for extensions that either: | | - Have been officially frozen or ratified by the RISC-V Foundation, or | - Have been implemented in hardware that is widely available, per standard | Linux practice.Quoted 2 lines
The xventanacondops bits don't qualify under the first entry, and I don't think they qualify under the second yet. Am I wrong?
The Ventana Veyron V1 was announced in Dec 2022 at RISC-V summit followed by press releases:
https://www.ventanamicro.com/ventana-introduces-veyron-worlds-first-data-center-class-risc-v-cpu-product-family/
https://www.embedded.com/ventana-reveals-risc-v-cpu-compute-chiplet-for-data-center/
https://www.prnewswire.com/news-releases/ventana-introduces-veyron-worlds-first-data-center-class-risc-v-cpu-product-family-301700985.htmlQuoted 4 lines
Quoted 1 line
@Palmer if the above looks good to you then please ack PATCH1-to-4
These are announcements AFAICT & not an indication of "being implemented in hardware that is widely available".
The second two look to just be news articles quoting the first without any real new information, at least just from skimming them -- sorry if I missed something, though.
The article says "SDK released with necessary software already ported to Veyron" and "Veyron V1 Development Platform available", but aside from quotes of the press release I can't find information on either of those (or anything VT1 related, as there were some naming ambiguities).
Anup said during the call that they're still bringing up the chip and haven't started sampling yet, which usually means things are far from publicly availiable. I thought I heard him say that these press releases would say the chip is sampling 2H23, but I can't find anything in them about sampling.
Quoted 7 lines
Anup also said it's availiable as IP and I remember something at Hot Chips talking about an example place and route for a VT1, which also sounds very much like a chip that's not availiable yet -- usually if there's a chip folks are a lot more concrete about that sort of thing.
So is there you can point to about this chip actually being publicly availiable?
The Veyron V1 chiplet samples are not available publicly at the moment. Being available as an IP is not the same as chiplet samples being available.
If this does not satisfy patch acceptance criteria then I will defer/drop the XVentanaCondOps related patches for now.
Can you ack PATCH2 and PATCH3 which deals with Zicond ?
Regards,
Anup