On 5/26/25 4:13 AM, Andrew Jones wrote:
On Mon, May 26, 2025 at 11:00:30AM +0200, Radim Krčmář wrote:
2025-05-23T10:16:11-07:00, Atish Patra <atish.patra@xxxxxxxxx>:
On 5/23/25 6:31 AM, Radim Krčmář wrote:
2025-05-22T12:03:43-07:00, Atish Patra <atishp@xxxxxxxxxxxx>:
Upgrade the SBI version to v3.0 so that corresponding features
can be enabled in the guest.
Signed-off-by: Atish Patra <atishp@xxxxxxxxxxxx>
---
diff --git a/arch/riscv/include/asm/kvm_vcpu_sbi.h b/arch/riscv/include/asm/kvm_vcpu_sbi.h
-#define KVM_SBI_VERSION_MAJOR 2
+#define KVM_SBI_VERSION_MAJOR 3
I think it's time to add versioning to KVM SBI implementation.
Userspace should be able to select the desired SBI version and KVM would
tell the guest that newer features are not supported.
We need new code for this, but it's a good idea.
We can achieve that through onereg interface by disabling individual SBI
extensions.
We can extend the existing onereg interface to disable a specific SBI
version directly
instead of individual ones to save those IOCTL as well.
Yes, I am all in favor of letting userspace provide all values in the
BASE extension.
We already support vendorid/archid/impid through one reg. I think we
just need to add the SBI version support to that so that user space can
set it.
This is covered by your recent patch that provides userspace_sbi.
Why do we need to invent new IOCTL for this ? Once the user space sets
the SBI version, KVM can enforce it.
With that, userspace can disable all extensions that aren't
supported by a given spec version, disable BASE and then provide
a BASE that advertises the version it wants. The new code is needed
for extensions that userspace still wants KVM to accelerate, but then
KVM needs to be informed it should deny all functions not included in
the selected spec version.
Thanks,
drew
_______________________________________________
linux-riscv mailing list
linux-riscv@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-riscv
