* [PATCH v4 00/13] KVM: arm64: Add support for hypercall services selection
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: Paolo Bonzini, Catalin Marinas, Will Deacon, Peter Shier,
Ricardo Koller, Oliver Upton, Reiji Watanabe, Jing Zhang,
Raghavendra Rao Anata, linux-arm-kernel, kvmarm, linux-kernel,
kvm
Hello,
Continuing the discussion from [1], the series tries to add support
for the user-space to elect the hypercall services that it wishes
to expose to the guest, rather than the guest discovering them
unconditionally. The idea employed by the series was taken from
[1] as suggested by Marc Z.
In a broad sense, the idea is similar to the current implementation
of PSCI interface- create a 'firmware psuedo-register' to handle the
firmware revisions. The series extends this idea to all the other
hypercalls such as TRNG (True Random Number Generator), PV_TIME
(Paravirtualized Time), and PTP (Precision Time protocol).
For better categorization and future scaling, these firmware registers
are categorized based on the service call owners, but unlike the
existing firmware psuedo-registers, they hold the features supported
in the form of a bitmap.
During the VM initialization, the registers holds an upper-limit of
the features supported by each one of them. It's expected that the
userspace discover the features provided by each register via GET_ONE_REG,
and writeback the desired values using SET_ONE_REG. KVM allows this
modification only until the VM has started.
Older VMMs can simply ignore the capability and the hypercall services
will be exposed unconditionally to the guests, thus ensuring backward
compatibility.
Since these registers, including the old ones such as
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_[1|2] maintain its state per-VM. Thus
accessing them via KVM_[GET|SET]_ONE_REG for every vCPU is redundant.
To optimize this, the series also introduces the capability
KVM_CAP_ARM_REG_SCOPE. If enabled, KVM_GET_REG_LIST will advertise the
registers that are VM-scoped by dynamically modifying the register
encoding. KVM_REG_ARM_SCOPE_* helper macros are introduced to decode
the same. By learning this, userspace can access such registers only once.
The patches are based off of mainline kernel 5.17-rc5, with the selftest
patches from [2] applied.
Patch-1 factors out the non-PSCI related interface from psci.c to
hypercalls.c, as the series would extend the list in the upcoming
patches.
Patch-2 introduces the KVM_CAP_ARM_REG_SCOPE capability.
Patch-3 provides helpers to encode existing registers withe the scope
information. The only users in the patch would be the registers,
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_[1|2]
Patch-4 tracks if the VM has started running, which would be used in the
upcoming patches.
Patch-5 sets up the framework for the bitmap firmware psuedo-registers.
It includes read/write helpers for the registers, and a helper to check
if a particular hypercall service is supported for the guest.
It also adds the register KVM_REG_ARM_STD_HYP_BMAP to support ARM's
standard secure services.
Patch-6 introduces the firmware register, KVM_REG_ARM_STD_HYP_BMAP,
which holds the standard hypervisor services (such as PV_TIME).
Patch-7 introduces the firmware register, KVM_REG_ARM_VENDOR_HYP_BMAP,
which holds the vendor specific hypercall services.
Patch-8,9 Add the necessary documentation for the newly added firmware
registers.
Patch-10 imports the SMCCC definitions from linux/arm-smccc.h into tools/
for further use in selftests.
Patch-11,12 adds the selftest to test the guest (using 'hvc') and
userspace interfaces (SET/GET_ONE_REG).
Patch-13 adds these firmware registers into the get-reg-list selftest.
[1]: https://lore.kernel.org/kvmarm/874kbcpmlq.wl-maz@kernel.org/T/
[2]: https://lore.kernel.org/kvmarm/YUzgdbYk8BeCnHyW@google.com/
Regards,
Raghavendra
v3 -> v4
Addressed comments and took suggestions by Reiji, Oliver, Marc,
Sean and Jim:
- Renamed and moved the VM has run once check to arm64.
- Introduced the capability to dynamically modify the register
encodings to include the scope information.
- Replaced mutex_lock with READ_ONCE and WRITE_ONCE when the
bitmaps are accessed.
- The hypercalls selftest re-runs with KVM_CAP_ARM_REG_SCOPE
enabled.
v2 -> v3
Addressed comments by Marc and Andrew:
- Dropped kvm_vcpu_has_run_once() implementation.
- Redifined kvm_vm_has_run_once() as kvm_vm_has_started() in the core
KVM code that introduces a new field, 'vm_started', to track this.
- KVM_CAP_ARM_HVC_FW_REG_BMAP returns the number of psuedo-firmware
bitmap registers upon a 'read'. Support for 'write' removed.
- Removed redundant spinlock, 'fw_reg_bmap_enabled' fields from the
hypercall descriptor structure.
- A separate sub-struct to hold the bitmap info is removed. The bitmap
info is directly stored in the hypercall descriptor structure
(struct kvm_hvc_desc).
v1 -> v2
Addressed comments by Oliver (thanks!):
- Introduced kvm_vcpu_has_run_once() and kvm_vm_has_run_once() in the
core kvm code, rather than relying on ARM specific
vcpu->arch.has_run_once.
- Writing to KVM_REG_ARM_PSCI_VERSION is done in hypercalls.c itself,
rather than separating out to psci.c.
- Introduced KVM_CAP_ARM_HVC_FW_REG_BMAP to enable the extension.
- Tracks the register accesses from VMM to decide whether to sanitize
a register or not, as opposed to sanitizing upon the first 'write'
in v1.
- kvm_hvc_call_supported() is implemented using a direct switch-case
statement, instead of looping over all the registers to pick the
register for the function-id.
- Replaced the register bit definitions with #defines, instead of enums.
- Removed the patch v1-06/08 that imports the firmware register
definitions as it's not needed.
- Separated out the documentations in its own patch, and the renaming
of hypercalls.rst to psci.rst into another patch.
- Add the new firmware registers to get-reg-list KVM selftest.
v1: https://lore.kernel.org/kvmarm/20211102002203.1046069-1-rananta@google.com/
v2: https://lore.kernel.org/kvmarm/20211113012234.1443009-1-rananta@google.com/
v3: https://lore.kernel.org/linux-arm-kernel/20220104194918.373612-1-rananta@google.com/
Raghavendra Rao Ananta (13):
KVM: arm64: Factor out firmware register handling from psci.c
KVM: arm64: Introduce KVM_CAP_ARM_REG_SCOPE
KVM: arm64: Encode the scope for firmware registers
KVM: arm64: Capture VM's first run
KVM: arm64: Setup a framework for hypercall bitmap firmware registers
KVM: arm64: Add standard hypervisor firmware register
KVM: arm64: Add vendor hypervisor firmware register
Docs: KVM: Add doc for the bitmap firmware registers
Docs: KVM: Rename psci.rst to hypercalls.rst
tools: Import ARM SMCCC definitions
selftests: KVM: aarch64: Introduce hypercall ABI test
selftests: KVM: aarch64: hypercalls: Test with KVM_CAP_ARM_REG_SCOPE
selftests: KVM: aarch64: Add the bitmap firmware registers to
get-reg-list
Documentation/virt/kvm/api.rst | 16 +
Documentation/virt/kvm/arm/hypercalls.rst | 124 +++++
Documentation/virt/kvm/arm/psci.rst | 77 ---
arch/arm64/include/asm/kvm_host.h | 30 ++
arch/arm64/include/uapi/asm/kvm.h | 22 +
arch/arm64/kvm/arm.c | 23 +-
arch/arm64/kvm/guest.c | 82 +++-
arch/arm64/kvm/hypercalls.c | 301 +++++++++++-
arch/arm64/kvm/psci.c | 166 -------
include/kvm/arm_hypercalls.h | 17 +
include/kvm/arm_psci.h | 7 -
include/uapi/linux/kvm.h | 1 +
tools/include/linux/arm-smccc.h | 188 ++++++++
tools/testing/selftests/kvm/.gitignore | 1 +
tools/testing/selftests/kvm/Makefile | 1 +
.../selftests/kvm/aarch64/get-reg-list.c | 3 +
.../selftests/kvm/aarch64/hypercalls.c | 443 ++++++++++++++++++
17 files changed, 1243 insertions(+), 259 deletions(-)
create mode 100644 Documentation/virt/kvm/arm/hypercalls.rst
delete mode 100644 Documentation/virt/kvm/arm/psci.rst
create mode 100644 tools/include/linux/arm-smccc.h
create mode 100644 tools/testing/selftests/kvm/aarch64/hypercalls.c
--
2.35.1.473.g83b2b277ed-goog
^ permalink raw reply [flat|nested] 117+ messages in thread* [PATCH v4 00/13] KVM: arm64: Add support for hypercall services selection
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: Paolo Bonzini, Catalin Marinas, Will Deacon, Peter Shier,
Ricardo Koller, Oliver Upton, Reiji Watanabe, Jing Zhang,
Raghavendra Rao Anata, linux-arm-kernel, kvmarm, linux-kernel,
kvm
Hello,
Continuing the discussion from [1], the series tries to add support
for the user-space to elect the hypercall services that it wishes
to expose to the guest, rather than the guest discovering them
unconditionally. The idea employed by the series was taken from
[1] as suggested by Marc Z.
In a broad sense, the idea is similar to the current implementation
of PSCI interface- create a 'firmware psuedo-register' to handle the
firmware revisions. The series extends this idea to all the other
hypercalls such as TRNG (True Random Number Generator), PV_TIME
(Paravirtualized Time), and PTP (Precision Time protocol).
For better categorization and future scaling, these firmware registers
are categorized based on the service call owners, but unlike the
existing firmware psuedo-registers, they hold the features supported
in the form of a bitmap.
During the VM initialization, the registers holds an upper-limit of
the features supported by each one of them. It's expected that the
userspace discover the features provided by each register via GET_ONE_REG,
and writeback the desired values using SET_ONE_REG. KVM allows this
modification only until the VM has started.
Older VMMs can simply ignore the capability and the hypercall services
will be exposed unconditionally to the guests, thus ensuring backward
compatibility.
Since these registers, including the old ones such as
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_[1|2] maintain its state per-VM. Thus
accessing them via KVM_[GET|SET]_ONE_REG for every vCPU is redundant.
To optimize this, the series also introduces the capability
KVM_CAP_ARM_REG_SCOPE. If enabled, KVM_GET_REG_LIST will advertise the
registers that are VM-scoped by dynamically modifying the register
encoding. KVM_REG_ARM_SCOPE_* helper macros are introduced to decode
the same. By learning this, userspace can access such registers only once.
The patches are based off of mainline kernel 5.17-rc5, with the selftest
patches from [2] applied.
Patch-1 factors out the non-PSCI related interface from psci.c to
hypercalls.c, as the series would extend the list in the upcoming
patches.
Patch-2 introduces the KVM_CAP_ARM_REG_SCOPE capability.
Patch-3 provides helpers to encode existing registers withe the scope
information. The only users in the patch would be the registers,
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_[1|2]
Patch-4 tracks if the VM has started running, which would be used in the
upcoming patches.
Patch-5 sets up the framework for the bitmap firmware psuedo-registers.
It includes read/write helpers for the registers, and a helper to check
if a particular hypercall service is supported for the guest.
It also adds the register KVM_REG_ARM_STD_HYP_BMAP to support ARM's
standard secure services.
Patch-6 introduces the firmware register, KVM_REG_ARM_STD_HYP_BMAP,
which holds the standard hypervisor services (such as PV_TIME).
Patch-7 introduces the firmware register, KVM_REG_ARM_VENDOR_HYP_BMAP,
which holds the vendor specific hypercall services.
Patch-8,9 Add the necessary documentation for the newly added firmware
registers.
Patch-10 imports the SMCCC definitions from linux/arm-smccc.h into tools/
for further use in selftests.
Patch-11,12 adds the selftest to test the guest (using 'hvc') and
userspace interfaces (SET/GET_ONE_REG).
Patch-13 adds these firmware registers into the get-reg-list selftest.
[1]: https://lore.kernel.org/kvmarm/874kbcpmlq.wl-maz@kernel.org/T/
[2]: https://lore.kernel.org/kvmarm/YUzgdbYk8BeCnHyW@google.com/
Regards,
Raghavendra
v3 -> v4
Addressed comments and took suggestions by Reiji, Oliver, Marc,
Sean and Jim:
- Renamed and moved the VM has run once check to arm64.
- Introduced the capability to dynamically modify the register
encodings to include the scope information.
- Replaced mutex_lock with READ_ONCE and WRITE_ONCE when the
bitmaps are accessed.
- The hypercalls selftest re-runs with KVM_CAP_ARM_REG_SCOPE
enabled.
v2 -> v3
Addressed comments by Marc and Andrew:
- Dropped kvm_vcpu_has_run_once() implementation.
- Redifined kvm_vm_has_run_once() as kvm_vm_has_started() in the core
KVM code that introduces a new field, 'vm_started', to track this.
- KVM_CAP_ARM_HVC_FW_REG_BMAP returns the number of psuedo-firmware
bitmap registers upon a 'read'. Support for 'write' removed.
- Removed redundant spinlock, 'fw_reg_bmap_enabled' fields from the
hypercall descriptor structure.
- A separate sub-struct to hold the bitmap info is removed. The bitmap
info is directly stored in the hypercall descriptor structure
(struct kvm_hvc_desc).
v1 -> v2
Addressed comments by Oliver (thanks!):
- Introduced kvm_vcpu_has_run_once() and kvm_vm_has_run_once() in the
core kvm code, rather than relying on ARM specific
vcpu->arch.has_run_once.
- Writing to KVM_REG_ARM_PSCI_VERSION is done in hypercalls.c itself,
rather than separating out to psci.c.
- Introduced KVM_CAP_ARM_HVC_FW_REG_BMAP to enable the extension.
- Tracks the register accesses from VMM to decide whether to sanitize
a register or not, as opposed to sanitizing upon the first 'write'
in v1.
- kvm_hvc_call_supported() is implemented using a direct switch-case
statement, instead of looping over all the registers to pick the
register for the function-id.
- Replaced the register bit definitions with #defines, instead of enums.
- Removed the patch v1-06/08 that imports the firmware register
definitions as it's not needed.
- Separated out the documentations in its own patch, and the renaming
of hypercalls.rst to psci.rst into another patch.
- Add the new firmware registers to get-reg-list KVM selftest.
v1: https://lore.kernel.org/kvmarm/20211102002203.1046069-1-rananta@google.com/
v2: https://lore.kernel.org/kvmarm/20211113012234.1443009-1-rananta@google.com/
v3: https://lore.kernel.org/linux-arm-kernel/20220104194918.373612-1-rananta@google.com/
Raghavendra Rao Ananta (13):
KVM: arm64: Factor out firmware register handling from psci.c
KVM: arm64: Introduce KVM_CAP_ARM_REG_SCOPE
KVM: arm64: Encode the scope for firmware registers
KVM: arm64: Capture VM's first run
KVM: arm64: Setup a framework for hypercall bitmap firmware registers
KVM: arm64: Add standard hypervisor firmware register
KVM: arm64: Add vendor hypervisor firmware register
Docs: KVM: Add doc for the bitmap firmware registers
Docs: KVM: Rename psci.rst to hypercalls.rst
tools: Import ARM SMCCC definitions
selftests: KVM: aarch64: Introduce hypercall ABI test
selftests: KVM: aarch64: hypercalls: Test with KVM_CAP_ARM_REG_SCOPE
selftests: KVM: aarch64: Add the bitmap firmware registers to
get-reg-list
Documentation/virt/kvm/api.rst | 16 +
Documentation/virt/kvm/arm/hypercalls.rst | 124 +++++
Documentation/virt/kvm/arm/psci.rst | 77 ---
arch/arm64/include/asm/kvm_host.h | 30 ++
arch/arm64/include/uapi/asm/kvm.h | 22 +
arch/arm64/kvm/arm.c | 23 +-
arch/arm64/kvm/guest.c | 82 +++-
arch/arm64/kvm/hypercalls.c | 301 +++++++++++-
arch/arm64/kvm/psci.c | 166 -------
include/kvm/arm_hypercalls.h | 17 +
include/kvm/arm_psci.h | 7 -
include/uapi/linux/kvm.h | 1 +
tools/include/linux/arm-smccc.h | 188 ++++++++
tools/testing/selftests/kvm/.gitignore | 1 +
tools/testing/selftests/kvm/Makefile | 1 +
.../selftests/kvm/aarch64/get-reg-list.c | 3 +
.../selftests/kvm/aarch64/hypercalls.c | 443 ++++++++++++++++++
17 files changed, 1243 insertions(+), 259 deletions(-)
create mode 100644 Documentation/virt/kvm/arm/hypercalls.rst
delete mode 100644 Documentation/virt/kvm/arm/psci.rst
create mode 100644 tools/include/linux/arm-smccc.h
create mode 100644 tools/testing/selftests/kvm/aarch64/hypercalls.c
--
2.35.1.473.g83b2b277ed-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 117+ messages in thread* [PATCH v4 01/13] KVM: arm64: Factor out firmware register handling from psci.c
2022-02-24 17:25 ` Raghavendra Rao Ananta
(?)
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
-1 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: kvm, Catalin Marinas, Peter Shier, linux-kernel, Paolo Bonzini,
Will Deacon, kvmarm, linux-arm-kernel
Common hypercall firmware register handing is currently employed
by psci.c. Since the upcoming patches add more of these registers,
it's better to move the generic handling to hypercall.c for a
cleaner presentation.
While we are at it, collect all the firmware registers under
fw_reg_ids[] to help implement kvm_arm_get_fw_num_regs() and
kvm_arm_copy_fw_reg_indices() in a generic way.
No functional change intended.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
arch/arm64/kvm/guest.c | 2 +-
arch/arm64/kvm/hypercalls.c | 170 +++++++++++++++++++++++++++++++++++
arch/arm64/kvm/psci.c | 166 ----------------------------------
include/kvm/arm_hypercalls.h | 7 ++
include/kvm/arm_psci.h | 7 --
5 files changed, 178 insertions(+), 174 deletions(-)
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index e116c7767730..8238e52d890d 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -18,7 +18,7 @@
#include <linux/string.h>
#include <linux/vmalloc.h>
#include <linux/fs.h>
-#include <kvm/arm_psci.h>
+#include <kvm/arm_hypercalls.h>
#include <asm/cputype.h>
#include <linux/uaccess.h>
#include <asm/fpsimd.h>
diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
index 30da78f72b3b..3c2fcf31ad3d 100644
--- a/arch/arm64/kvm/hypercalls.c
+++ b/arch/arm64/kvm/hypercalls.c
@@ -146,3 +146,173 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
smccc_set_retval(vcpu, val[0], val[1], val[2], val[3]);
return 1;
}
+
+static const u64 kvm_arm_fw_reg_ids[] = {
+ KVM_REG_ARM_PSCI_VERSION,
+ KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
+ KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
+};
+
+int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
+{
+ return ARRAY_SIZE(kvm_arm_fw_reg_ids);
+}
+
+int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(kvm_arm_fw_reg_ids); i++) {
+ if (put_user(kvm_arm_fw_reg_ids[i], uindices++))
+ return -EFAULT;
+ }
+
+ return 0;
+}
+
+#define KVM_REG_FEATURE_LEVEL_WIDTH 4
+#define KVM_REG_FEATURE_LEVEL_MASK (BIT(KVM_REG_FEATURE_LEVEL_WIDTH) - 1)
+
+/*
+ * Convert the workaround level into an easy-to-compare number, where higher
+ * values mean better protection.
+ */
+static int get_kernel_wa_level(u64 regid)
+{
+ switch (regid) {
+ case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
+ switch (arm64_get_spectre_v2_state()) {
+ case SPECTRE_VULNERABLE:
+ return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
+ case SPECTRE_MITIGATED:
+ return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_AVAIL;
+ case SPECTRE_UNAFFECTED:
+ return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_REQUIRED;
+ }
+ return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
+ case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
+ switch (arm64_get_spectre_v4_state()) {
+ case SPECTRE_MITIGATED:
+ /*
+ * As for the hypercall discovery, we pretend we
+ * don't have any FW mitigation if SSBS is there at
+ * all times.
+ */
+ if (cpus_have_final_cap(ARM64_SSBS))
+ return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
+ fallthrough;
+ case SPECTRE_UNAFFECTED:
+ return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
+ case SPECTRE_VULNERABLE:
+ return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
+ }
+ }
+
+ return -EINVAL;
+}
+
+int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
+{
+ void __user *uaddr = (void __user *)(long)reg->addr;
+ u64 val;
+
+ switch (reg->id) {
+ case KVM_REG_ARM_PSCI_VERSION:
+ val = kvm_psci_version(vcpu, vcpu->kvm);
+ break;
+ case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
+ case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
+ val = get_kernel_wa_level(reg->id) & KVM_REG_FEATURE_LEVEL_MASK;
+ break;
+ default:
+ return -ENOENT;
+ }
+
+ if (copy_to_user(uaddr, &val, KVM_REG_SIZE(reg->id)))
+ return -EFAULT;
+
+ return 0;
+}
+
+int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
+{
+ void __user *uaddr = (void __user *)(long)reg->addr;
+ u64 val;
+ int wa_level;
+
+ if (copy_from_user(&val, uaddr, KVM_REG_SIZE(reg->id)))
+ return -EFAULT;
+
+ switch (reg->id) {
+ case KVM_REG_ARM_PSCI_VERSION:
+ {
+ bool wants_02;
+
+ wants_02 = test_bit(KVM_ARM_VCPU_PSCI_0_2, vcpu->arch.features);
+
+ switch (val) {
+ case KVM_ARM_PSCI_0_1:
+ if (wants_02)
+ return -EINVAL;
+ vcpu->kvm->arch.psci_version = val;
+ return 0;
+ case KVM_ARM_PSCI_0_2:
+ case KVM_ARM_PSCI_1_0:
+ if (!wants_02)
+ return -EINVAL;
+ vcpu->kvm->arch.psci_version = val;
+ return 0;
+ }
+ break;
+ }
+
+ case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
+ if (val & ~KVM_REG_FEATURE_LEVEL_MASK)
+ return -EINVAL;
+
+ if (get_kernel_wa_level(reg->id) < val)
+ return -EINVAL;
+
+ return 0;
+
+ case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
+ if (val & ~(KVM_REG_FEATURE_LEVEL_MASK |
+ KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED))
+ return -EINVAL;
+
+ /* The enabled bit must not be set unless the level is AVAIL. */
+ if ((val & KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED) &&
+ (val & KVM_REG_FEATURE_LEVEL_MASK) != KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL)
+ return -EINVAL;
+
+ /*
+ * Map all the possible incoming states to the only two we
+ * really want to deal with.
+ */
+ switch (val & KVM_REG_FEATURE_LEVEL_MASK) {
+ case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL:
+ case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_UNKNOWN:
+ wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
+ break;
+ case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL:
+ case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED:
+ wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ /*
+ * We can deal with NOT_AVAIL on NOT_REQUIRED, but not the
+ * other way around.
+ */
+ if (get_kernel_wa_level(reg->id) < wa_level)
+ return -EINVAL;
+
+ return 0;
+ default:
+ return -ENOENT;
+ }
+
+ return -EINVAL;
+}
diff --git a/arch/arm64/kvm/psci.c b/arch/arm64/kvm/psci.c
index 3eae32876897..d5bc663a8629 100644
--- a/arch/arm64/kvm/psci.c
+++ b/arch/arm64/kvm/psci.c
@@ -403,169 +403,3 @@ int kvm_psci_call(struct kvm_vcpu *vcpu)
return -EINVAL;
};
}
-
-int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
-{
- return 3; /* PSCI version and two workaround registers */
-}
-
-int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
-{
- if (put_user(KVM_REG_ARM_PSCI_VERSION, uindices++))
- return -EFAULT;
-
- if (put_user(KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1, uindices++))
- return -EFAULT;
-
- if (put_user(KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2, uindices++))
- return -EFAULT;
-
- return 0;
-}
-
-#define KVM_REG_FEATURE_LEVEL_WIDTH 4
-#define KVM_REG_FEATURE_LEVEL_MASK (BIT(KVM_REG_FEATURE_LEVEL_WIDTH) - 1)
-
-/*
- * Convert the workaround level into an easy-to-compare number, where higher
- * values mean better protection.
- */
-static int get_kernel_wa_level(u64 regid)
-{
- switch (regid) {
- case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
- switch (arm64_get_spectre_v2_state()) {
- case SPECTRE_VULNERABLE:
- return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
- case SPECTRE_MITIGATED:
- return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_AVAIL;
- case SPECTRE_UNAFFECTED:
- return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_REQUIRED;
- }
- return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
- case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
- switch (arm64_get_spectre_v4_state()) {
- case SPECTRE_MITIGATED:
- /*
- * As for the hypercall discovery, we pretend we
- * don't have any FW mitigation if SSBS is there at
- * all times.
- */
- if (cpus_have_final_cap(ARM64_SSBS))
- return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
- fallthrough;
- case SPECTRE_UNAFFECTED:
- return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
- case SPECTRE_VULNERABLE:
- return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
- }
- }
-
- return -EINVAL;
-}
-
-int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
-{
- void __user *uaddr = (void __user *)(long)reg->addr;
- u64 val;
-
- switch (reg->id) {
- case KVM_REG_ARM_PSCI_VERSION:
- val = kvm_psci_version(vcpu, vcpu->kvm);
- break;
- case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
- case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
- val = get_kernel_wa_level(reg->id) & KVM_REG_FEATURE_LEVEL_MASK;
- break;
- default:
- return -ENOENT;
- }
-
- if (copy_to_user(uaddr, &val, KVM_REG_SIZE(reg->id)))
- return -EFAULT;
-
- return 0;
-}
-
-int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
-{
- void __user *uaddr = (void __user *)(long)reg->addr;
- u64 val;
- int wa_level;
-
- if (copy_from_user(&val, uaddr, KVM_REG_SIZE(reg->id)))
- return -EFAULT;
-
- switch (reg->id) {
- case KVM_REG_ARM_PSCI_VERSION:
- {
- bool wants_02;
-
- wants_02 = test_bit(KVM_ARM_VCPU_PSCI_0_2, vcpu->arch.features);
-
- switch (val) {
- case KVM_ARM_PSCI_0_1:
- if (wants_02)
- return -EINVAL;
- vcpu->kvm->arch.psci_version = val;
- return 0;
- case KVM_ARM_PSCI_0_2:
- case KVM_ARM_PSCI_1_0:
- if (!wants_02)
- return -EINVAL;
- vcpu->kvm->arch.psci_version = val;
- return 0;
- }
- break;
- }
-
- case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
- if (val & ~KVM_REG_FEATURE_LEVEL_MASK)
- return -EINVAL;
-
- if (get_kernel_wa_level(reg->id) < val)
- return -EINVAL;
-
- return 0;
-
- case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
- if (val & ~(KVM_REG_FEATURE_LEVEL_MASK |
- KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED))
- return -EINVAL;
-
- /* The enabled bit must not be set unless the level is AVAIL. */
- if ((val & KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED) &&
- (val & KVM_REG_FEATURE_LEVEL_MASK) != KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL)
- return -EINVAL;
-
- /*
- * Map all the possible incoming states to the only two we
- * really want to deal with.
- */
- switch (val & KVM_REG_FEATURE_LEVEL_MASK) {
- case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL:
- case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_UNKNOWN:
- wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
- break;
- case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL:
- case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED:
- wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
- break;
- default:
- return -EINVAL;
- }
-
- /*
- * We can deal with NOT_AVAIL on NOT_REQUIRED, but not the
- * other way around.
- */
- if (get_kernel_wa_level(reg->id) < wa_level)
- return -EINVAL;
-
- return 0;
- default:
- return -ENOENT;
- }
-
- return -EINVAL;
-}
diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
index 0e2509d27910..5d38628a8d04 100644
--- a/include/kvm/arm_hypercalls.h
+++ b/include/kvm/arm_hypercalls.h
@@ -40,4 +40,11 @@ static inline void smccc_set_retval(struct kvm_vcpu *vcpu,
vcpu_set_reg(vcpu, 3, a3);
}
+struct kvm_one_reg;
+
+int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
+int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
+int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
+int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
+
#endif
diff --git a/include/kvm/arm_psci.h b/include/kvm/arm_psci.h
index 5b58bd2fe088..080c2d0bd6e7 100644
--- a/include/kvm/arm_psci.h
+++ b/include/kvm/arm_psci.h
@@ -42,11 +42,4 @@ static inline int kvm_psci_version(struct kvm_vcpu *vcpu, struct kvm *kvm)
int kvm_psci_call(struct kvm_vcpu *vcpu);
-struct kvm_one_reg;
-
-int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
-int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
-int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
-int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
-
#endif /* __KVM_ARM_PSCI_H__ */
--
2.35.1.473.g83b2b277ed-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 117+ messages in thread* [PATCH v4 01/13] KVM: arm64: Factor out firmware register handling from psci.c
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: Paolo Bonzini, Catalin Marinas, Will Deacon, Peter Shier,
Ricardo Koller, Oliver Upton, Reiji Watanabe, Jing Zhang,
Raghavendra Rao Anata, linux-arm-kernel, kvmarm, linux-kernel,
kvm
Common hypercall firmware register handing is currently employed
by psci.c. Since the upcoming patches add more of these registers,
it's better to move the generic handling to hypercall.c for a
cleaner presentation.
While we are at it, collect all the firmware registers under
fw_reg_ids[] to help implement kvm_arm_get_fw_num_regs() and
kvm_arm_copy_fw_reg_indices() in a generic way.
No functional change intended.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
arch/arm64/kvm/guest.c | 2 +-
arch/arm64/kvm/hypercalls.c | 170 +++++++++++++++++++++++++++++++++++
arch/arm64/kvm/psci.c | 166 ----------------------------------
include/kvm/arm_hypercalls.h | 7 ++
include/kvm/arm_psci.h | 7 --
5 files changed, 178 insertions(+), 174 deletions(-)
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index e116c7767730..8238e52d890d 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -18,7 +18,7 @@
#include <linux/string.h>
#include <linux/vmalloc.h>
#include <linux/fs.h>
-#include <kvm/arm_psci.h>
+#include <kvm/arm_hypercalls.h>
#include <asm/cputype.h>
#include <linux/uaccess.h>
#include <asm/fpsimd.h>
diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
index 30da78f72b3b..3c2fcf31ad3d 100644
--- a/arch/arm64/kvm/hypercalls.c
+++ b/arch/arm64/kvm/hypercalls.c
@@ -146,3 +146,173 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
smccc_set_retval(vcpu, val[0], val[1], val[2], val[3]);
return 1;
}
+
+static const u64 kvm_arm_fw_reg_ids[] = {
+ KVM_REG_ARM_PSCI_VERSION,
+ KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
+ KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
+};
+
+int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
+{
+ return ARRAY_SIZE(kvm_arm_fw_reg_ids);
+}
+
+int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(kvm_arm_fw_reg_ids); i++) {
+ if (put_user(kvm_arm_fw_reg_ids[i], uindices++))
+ return -EFAULT;
+ }
+
+ return 0;
+}
+
+#define KVM_REG_FEATURE_LEVEL_WIDTH 4
+#define KVM_REG_FEATURE_LEVEL_MASK (BIT(KVM_REG_FEATURE_LEVEL_WIDTH) - 1)
+
+/*
+ * Convert the workaround level into an easy-to-compare number, where higher
+ * values mean better protection.
+ */
+static int get_kernel_wa_level(u64 regid)
+{
+ switch (regid) {
+ case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
+ switch (arm64_get_spectre_v2_state()) {
+ case SPECTRE_VULNERABLE:
+ return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
+ case SPECTRE_MITIGATED:
+ return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_AVAIL;
+ case SPECTRE_UNAFFECTED:
+ return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_REQUIRED;
+ }
+ return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
+ case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
+ switch (arm64_get_spectre_v4_state()) {
+ case SPECTRE_MITIGATED:
+ /*
+ * As for the hypercall discovery, we pretend we
+ * don't have any FW mitigation if SSBS is there at
+ * all times.
+ */
+ if (cpus_have_final_cap(ARM64_SSBS))
+ return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
+ fallthrough;
+ case SPECTRE_UNAFFECTED:
+ return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
+ case SPECTRE_VULNERABLE:
+ return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
+ }
+ }
+
+ return -EINVAL;
+}
+
+int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
+{
+ void __user *uaddr = (void __user *)(long)reg->addr;
+ u64 val;
+
+ switch (reg->id) {
+ case KVM_REG_ARM_PSCI_VERSION:
+ val = kvm_psci_version(vcpu, vcpu->kvm);
+ break;
+ case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
+ case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
+ val = get_kernel_wa_level(reg->id) & KVM_REG_FEATURE_LEVEL_MASK;
+ break;
+ default:
+ return -ENOENT;
+ }
+
+ if (copy_to_user(uaddr, &val, KVM_REG_SIZE(reg->id)))
+ return -EFAULT;
+
+ return 0;
+}
+
+int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
+{
+ void __user *uaddr = (void __user *)(long)reg->addr;
+ u64 val;
+ int wa_level;
+
+ if (copy_from_user(&val, uaddr, KVM_REG_SIZE(reg->id)))
+ return -EFAULT;
+
+ switch (reg->id) {
+ case KVM_REG_ARM_PSCI_VERSION:
+ {
+ bool wants_02;
+
+ wants_02 = test_bit(KVM_ARM_VCPU_PSCI_0_2, vcpu->arch.features);
+
+ switch (val) {
+ case KVM_ARM_PSCI_0_1:
+ if (wants_02)
+ return -EINVAL;
+ vcpu->kvm->arch.psci_version = val;
+ return 0;
+ case KVM_ARM_PSCI_0_2:
+ case KVM_ARM_PSCI_1_0:
+ if (!wants_02)
+ return -EINVAL;
+ vcpu->kvm->arch.psci_version = val;
+ return 0;
+ }
+ break;
+ }
+
+ case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
+ if (val & ~KVM_REG_FEATURE_LEVEL_MASK)
+ return -EINVAL;
+
+ if (get_kernel_wa_level(reg->id) < val)
+ return -EINVAL;
+
+ return 0;
+
+ case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
+ if (val & ~(KVM_REG_FEATURE_LEVEL_MASK |
+ KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED))
+ return -EINVAL;
+
+ /* The enabled bit must not be set unless the level is AVAIL. */
+ if ((val & KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED) &&
+ (val & KVM_REG_FEATURE_LEVEL_MASK) != KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL)
+ return -EINVAL;
+
+ /*
+ * Map all the possible incoming states to the only two we
+ * really want to deal with.
+ */
+ switch (val & KVM_REG_FEATURE_LEVEL_MASK) {
+ case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL:
+ case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_UNKNOWN:
+ wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
+ break;
+ case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL:
+ case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED:
+ wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ /*
+ * We can deal with NOT_AVAIL on NOT_REQUIRED, but not the
+ * other way around.
+ */
+ if (get_kernel_wa_level(reg->id) < wa_level)
+ return -EINVAL;
+
+ return 0;
+ default:
+ return -ENOENT;
+ }
+
+ return -EINVAL;
+}
diff --git a/arch/arm64/kvm/psci.c b/arch/arm64/kvm/psci.c
index 3eae32876897..d5bc663a8629 100644
--- a/arch/arm64/kvm/psci.c
+++ b/arch/arm64/kvm/psci.c
@@ -403,169 +403,3 @@ int kvm_psci_call(struct kvm_vcpu *vcpu)
return -EINVAL;
};
}
-
-int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
-{
- return 3; /* PSCI version and two workaround registers */
-}
-
-int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
-{
- if (put_user(KVM_REG_ARM_PSCI_VERSION, uindices++))
- return -EFAULT;
-
- if (put_user(KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1, uindices++))
- return -EFAULT;
-
- if (put_user(KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2, uindices++))
- return -EFAULT;
-
- return 0;
-}
-
-#define KVM_REG_FEATURE_LEVEL_WIDTH 4
-#define KVM_REG_FEATURE_LEVEL_MASK (BIT(KVM_REG_FEATURE_LEVEL_WIDTH) - 1)
-
-/*
- * Convert the workaround level into an easy-to-compare number, where higher
- * values mean better protection.
- */
-static int get_kernel_wa_level(u64 regid)
-{
- switch (regid) {
- case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
- switch (arm64_get_spectre_v2_state()) {
- case SPECTRE_VULNERABLE:
- return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
- case SPECTRE_MITIGATED:
- return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_AVAIL;
- case SPECTRE_UNAFFECTED:
- return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_REQUIRED;
- }
- return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
- case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
- switch (arm64_get_spectre_v4_state()) {
- case SPECTRE_MITIGATED:
- /*
- * As for the hypercall discovery, we pretend we
- * don't have any FW mitigation if SSBS is there at
- * all times.
- */
- if (cpus_have_final_cap(ARM64_SSBS))
- return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
- fallthrough;
- case SPECTRE_UNAFFECTED:
- return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
- case SPECTRE_VULNERABLE:
- return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
- }
- }
-
- return -EINVAL;
-}
-
-int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
-{
- void __user *uaddr = (void __user *)(long)reg->addr;
- u64 val;
-
- switch (reg->id) {
- case KVM_REG_ARM_PSCI_VERSION:
- val = kvm_psci_version(vcpu, vcpu->kvm);
- break;
- case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
- case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
- val = get_kernel_wa_level(reg->id) & KVM_REG_FEATURE_LEVEL_MASK;
- break;
- default:
- return -ENOENT;
- }
-
- if (copy_to_user(uaddr, &val, KVM_REG_SIZE(reg->id)))
- return -EFAULT;
-
- return 0;
-}
-
-int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
-{
- void __user *uaddr = (void __user *)(long)reg->addr;
- u64 val;
- int wa_level;
-
- if (copy_from_user(&val, uaddr, KVM_REG_SIZE(reg->id)))
- return -EFAULT;
-
- switch (reg->id) {
- case KVM_REG_ARM_PSCI_VERSION:
- {
- bool wants_02;
-
- wants_02 = test_bit(KVM_ARM_VCPU_PSCI_0_2, vcpu->arch.features);
-
- switch (val) {
- case KVM_ARM_PSCI_0_1:
- if (wants_02)
- return -EINVAL;
- vcpu->kvm->arch.psci_version = val;
- return 0;
- case KVM_ARM_PSCI_0_2:
- case KVM_ARM_PSCI_1_0:
- if (!wants_02)
- return -EINVAL;
- vcpu->kvm->arch.psci_version = val;
- return 0;
- }
- break;
- }
-
- case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
- if (val & ~KVM_REG_FEATURE_LEVEL_MASK)
- return -EINVAL;
-
- if (get_kernel_wa_level(reg->id) < val)
- return -EINVAL;
-
- return 0;
-
- case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
- if (val & ~(KVM_REG_FEATURE_LEVEL_MASK |
- KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED))
- return -EINVAL;
-
- /* The enabled bit must not be set unless the level is AVAIL. */
- if ((val & KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED) &&
- (val & KVM_REG_FEATURE_LEVEL_MASK) != KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL)
- return -EINVAL;
-
- /*
- * Map all the possible incoming states to the only two we
- * really want to deal with.
- */
- switch (val & KVM_REG_FEATURE_LEVEL_MASK) {
- case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL:
- case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_UNKNOWN:
- wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
- break;
- case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL:
- case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED:
- wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
- break;
- default:
- return -EINVAL;
- }
-
- /*
- * We can deal with NOT_AVAIL on NOT_REQUIRED, but not the
- * other way around.
- */
- if (get_kernel_wa_level(reg->id) < wa_level)
- return -EINVAL;
-
- return 0;
- default:
- return -ENOENT;
- }
-
- return -EINVAL;
-}
diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
index 0e2509d27910..5d38628a8d04 100644
--- a/include/kvm/arm_hypercalls.h
+++ b/include/kvm/arm_hypercalls.h
@@ -40,4 +40,11 @@ static inline void smccc_set_retval(struct kvm_vcpu *vcpu,
vcpu_set_reg(vcpu, 3, a3);
}
+struct kvm_one_reg;
+
+int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
+int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
+int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
+int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
+
#endif
diff --git a/include/kvm/arm_psci.h b/include/kvm/arm_psci.h
index 5b58bd2fe088..080c2d0bd6e7 100644
--- a/include/kvm/arm_psci.h
+++ b/include/kvm/arm_psci.h
@@ -42,11 +42,4 @@ static inline int kvm_psci_version(struct kvm_vcpu *vcpu, struct kvm *kvm)
int kvm_psci_call(struct kvm_vcpu *vcpu);
-struct kvm_one_reg;
-
-int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
-int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
-int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
-int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
-
#endif /* __KVM_ARM_PSCI_H__ */
--
2.35.1.473.g83b2b277ed-goog
^ permalink raw reply related [flat|nested] 117+ messages in thread* [PATCH v4 01/13] KVM: arm64: Factor out firmware register handling from psci.c
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: Paolo Bonzini, Catalin Marinas, Will Deacon, Peter Shier,
Ricardo Koller, Oliver Upton, Reiji Watanabe, Jing Zhang,
Raghavendra Rao Anata, linux-arm-kernel, kvmarm, linux-kernel,
kvm
Common hypercall firmware register handing is currently employed
by psci.c. Since the upcoming patches add more of these registers,
it's better to move the generic handling to hypercall.c for a
cleaner presentation.
While we are at it, collect all the firmware registers under
fw_reg_ids[] to help implement kvm_arm_get_fw_num_regs() and
kvm_arm_copy_fw_reg_indices() in a generic way.
No functional change intended.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
arch/arm64/kvm/guest.c | 2 +-
arch/arm64/kvm/hypercalls.c | 170 +++++++++++++++++++++++++++++++++++
arch/arm64/kvm/psci.c | 166 ----------------------------------
include/kvm/arm_hypercalls.h | 7 ++
include/kvm/arm_psci.h | 7 --
5 files changed, 178 insertions(+), 174 deletions(-)
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index e116c7767730..8238e52d890d 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -18,7 +18,7 @@
#include <linux/string.h>
#include <linux/vmalloc.h>
#include <linux/fs.h>
-#include <kvm/arm_psci.h>
+#include <kvm/arm_hypercalls.h>
#include <asm/cputype.h>
#include <linux/uaccess.h>
#include <asm/fpsimd.h>
diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
index 30da78f72b3b..3c2fcf31ad3d 100644
--- a/arch/arm64/kvm/hypercalls.c
+++ b/arch/arm64/kvm/hypercalls.c
@@ -146,3 +146,173 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
smccc_set_retval(vcpu, val[0], val[1], val[2], val[3]);
return 1;
}
+
+static const u64 kvm_arm_fw_reg_ids[] = {
+ KVM_REG_ARM_PSCI_VERSION,
+ KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
+ KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
+};
+
+int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
+{
+ return ARRAY_SIZE(kvm_arm_fw_reg_ids);
+}
+
+int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(kvm_arm_fw_reg_ids); i++) {
+ if (put_user(kvm_arm_fw_reg_ids[i], uindices++))
+ return -EFAULT;
+ }
+
+ return 0;
+}
+
+#define KVM_REG_FEATURE_LEVEL_WIDTH 4
+#define KVM_REG_FEATURE_LEVEL_MASK (BIT(KVM_REG_FEATURE_LEVEL_WIDTH) - 1)
+
+/*
+ * Convert the workaround level into an easy-to-compare number, where higher
+ * values mean better protection.
+ */
+static int get_kernel_wa_level(u64 regid)
+{
+ switch (regid) {
+ case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
+ switch (arm64_get_spectre_v2_state()) {
+ case SPECTRE_VULNERABLE:
+ return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
+ case SPECTRE_MITIGATED:
+ return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_AVAIL;
+ case SPECTRE_UNAFFECTED:
+ return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_REQUIRED;
+ }
+ return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
+ case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
+ switch (arm64_get_spectre_v4_state()) {
+ case SPECTRE_MITIGATED:
+ /*
+ * As for the hypercall discovery, we pretend we
+ * don't have any FW mitigation if SSBS is there at
+ * all times.
+ */
+ if (cpus_have_final_cap(ARM64_SSBS))
+ return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
+ fallthrough;
+ case SPECTRE_UNAFFECTED:
+ return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
+ case SPECTRE_VULNERABLE:
+ return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
+ }
+ }
+
+ return -EINVAL;
+}
+
+int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
+{
+ void __user *uaddr = (void __user *)(long)reg->addr;
+ u64 val;
+
+ switch (reg->id) {
+ case KVM_REG_ARM_PSCI_VERSION:
+ val = kvm_psci_version(vcpu, vcpu->kvm);
+ break;
+ case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
+ case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
+ val = get_kernel_wa_level(reg->id) & KVM_REG_FEATURE_LEVEL_MASK;
+ break;
+ default:
+ return -ENOENT;
+ }
+
+ if (copy_to_user(uaddr, &val, KVM_REG_SIZE(reg->id)))
+ return -EFAULT;
+
+ return 0;
+}
+
+int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
+{
+ void __user *uaddr = (void __user *)(long)reg->addr;
+ u64 val;
+ int wa_level;
+
+ if (copy_from_user(&val, uaddr, KVM_REG_SIZE(reg->id)))
+ return -EFAULT;
+
+ switch (reg->id) {
+ case KVM_REG_ARM_PSCI_VERSION:
+ {
+ bool wants_02;
+
+ wants_02 = test_bit(KVM_ARM_VCPU_PSCI_0_2, vcpu->arch.features);
+
+ switch (val) {
+ case KVM_ARM_PSCI_0_1:
+ if (wants_02)
+ return -EINVAL;
+ vcpu->kvm->arch.psci_version = val;
+ return 0;
+ case KVM_ARM_PSCI_0_2:
+ case KVM_ARM_PSCI_1_0:
+ if (!wants_02)
+ return -EINVAL;
+ vcpu->kvm->arch.psci_version = val;
+ return 0;
+ }
+ break;
+ }
+
+ case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
+ if (val & ~KVM_REG_FEATURE_LEVEL_MASK)
+ return -EINVAL;
+
+ if (get_kernel_wa_level(reg->id) < val)
+ return -EINVAL;
+
+ return 0;
+
+ case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
+ if (val & ~(KVM_REG_FEATURE_LEVEL_MASK |
+ KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED))
+ return -EINVAL;
+
+ /* The enabled bit must not be set unless the level is AVAIL. */
+ if ((val & KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED) &&
+ (val & KVM_REG_FEATURE_LEVEL_MASK) != KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL)
+ return -EINVAL;
+
+ /*
+ * Map all the possible incoming states to the only two we
+ * really want to deal with.
+ */
+ switch (val & KVM_REG_FEATURE_LEVEL_MASK) {
+ case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL:
+ case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_UNKNOWN:
+ wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
+ break;
+ case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL:
+ case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED:
+ wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ /*
+ * We can deal with NOT_AVAIL on NOT_REQUIRED, but not the
+ * other way around.
+ */
+ if (get_kernel_wa_level(reg->id) < wa_level)
+ return -EINVAL;
+
+ return 0;
+ default:
+ return -ENOENT;
+ }
+
+ return -EINVAL;
+}
diff --git a/arch/arm64/kvm/psci.c b/arch/arm64/kvm/psci.c
index 3eae32876897..d5bc663a8629 100644
--- a/arch/arm64/kvm/psci.c
+++ b/arch/arm64/kvm/psci.c
@@ -403,169 +403,3 @@ int kvm_psci_call(struct kvm_vcpu *vcpu)
return -EINVAL;
};
}
-
-int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
-{
- return 3; /* PSCI version and two workaround registers */
-}
-
-int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
-{
- if (put_user(KVM_REG_ARM_PSCI_VERSION, uindices++))
- return -EFAULT;
-
- if (put_user(KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1, uindices++))
- return -EFAULT;
-
- if (put_user(KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2, uindices++))
- return -EFAULT;
-
- return 0;
-}
-
-#define KVM_REG_FEATURE_LEVEL_WIDTH 4
-#define KVM_REG_FEATURE_LEVEL_MASK (BIT(KVM_REG_FEATURE_LEVEL_WIDTH) - 1)
-
-/*
- * Convert the workaround level into an easy-to-compare number, where higher
- * values mean better protection.
- */
-static int get_kernel_wa_level(u64 regid)
-{
- switch (regid) {
- case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
- switch (arm64_get_spectre_v2_state()) {
- case SPECTRE_VULNERABLE:
- return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
- case SPECTRE_MITIGATED:
- return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_AVAIL;
- case SPECTRE_UNAFFECTED:
- return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_REQUIRED;
- }
- return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
- case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
- switch (arm64_get_spectre_v4_state()) {
- case SPECTRE_MITIGATED:
- /*
- * As for the hypercall discovery, we pretend we
- * don't have any FW mitigation if SSBS is there at
- * all times.
- */
- if (cpus_have_final_cap(ARM64_SSBS))
- return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
- fallthrough;
- case SPECTRE_UNAFFECTED:
- return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
- case SPECTRE_VULNERABLE:
- return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
- }
- }
-
- return -EINVAL;
-}
-
-int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
-{
- void __user *uaddr = (void __user *)(long)reg->addr;
- u64 val;
-
- switch (reg->id) {
- case KVM_REG_ARM_PSCI_VERSION:
- val = kvm_psci_version(vcpu, vcpu->kvm);
- break;
- case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
- case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
- val = get_kernel_wa_level(reg->id) & KVM_REG_FEATURE_LEVEL_MASK;
- break;
- default:
- return -ENOENT;
- }
-
- if (copy_to_user(uaddr, &val, KVM_REG_SIZE(reg->id)))
- return -EFAULT;
-
- return 0;
-}
-
-int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
-{
- void __user *uaddr = (void __user *)(long)reg->addr;
- u64 val;
- int wa_level;
-
- if (copy_from_user(&val, uaddr, KVM_REG_SIZE(reg->id)))
- return -EFAULT;
-
- switch (reg->id) {
- case KVM_REG_ARM_PSCI_VERSION:
- {
- bool wants_02;
-
- wants_02 = test_bit(KVM_ARM_VCPU_PSCI_0_2, vcpu->arch.features);
-
- switch (val) {
- case KVM_ARM_PSCI_0_1:
- if (wants_02)
- return -EINVAL;
- vcpu->kvm->arch.psci_version = val;
- return 0;
- case KVM_ARM_PSCI_0_2:
- case KVM_ARM_PSCI_1_0:
- if (!wants_02)
- return -EINVAL;
- vcpu->kvm->arch.psci_version = val;
- return 0;
- }
- break;
- }
-
- case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
- if (val & ~KVM_REG_FEATURE_LEVEL_MASK)
- return -EINVAL;
-
- if (get_kernel_wa_level(reg->id) < val)
- return -EINVAL;
-
- return 0;
-
- case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
- if (val & ~(KVM_REG_FEATURE_LEVEL_MASK |
- KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED))
- return -EINVAL;
-
- /* The enabled bit must not be set unless the level is AVAIL. */
- if ((val & KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED) &&
- (val & KVM_REG_FEATURE_LEVEL_MASK) != KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL)
- return -EINVAL;
-
- /*
- * Map all the possible incoming states to the only two we
- * really want to deal with.
- */
- switch (val & KVM_REG_FEATURE_LEVEL_MASK) {
- case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL:
- case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_UNKNOWN:
- wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
- break;
- case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL:
- case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED:
- wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
- break;
- default:
- return -EINVAL;
- }
-
- /*
- * We can deal with NOT_AVAIL on NOT_REQUIRED, but not the
- * other way around.
- */
- if (get_kernel_wa_level(reg->id) < wa_level)
- return -EINVAL;
-
- return 0;
- default:
- return -ENOENT;
- }
-
- return -EINVAL;
-}
diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
index 0e2509d27910..5d38628a8d04 100644
--- a/include/kvm/arm_hypercalls.h
+++ b/include/kvm/arm_hypercalls.h
@@ -40,4 +40,11 @@ static inline void smccc_set_retval(struct kvm_vcpu *vcpu,
vcpu_set_reg(vcpu, 3, a3);
}
+struct kvm_one_reg;
+
+int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
+int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
+int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
+int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
+
#endif
diff --git a/include/kvm/arm_psci.h b/include/kvm/arm_psci.h
index 5b58bd2fe088..080c2d0bd6e7 100644
--- a/include/kvm/arm_psci.h
+++ b/include/kvm/arm_psci.h
@@ -42,11 +42,4 @@ static inline int kvm_psci_version(struct kvm_vcpu *vcpu, struct kvm *kvm)
int kvm_psci_call(struct kvm_vcpu *vcpu);
-struct kvm_one_reg;
-
-int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
-int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
-int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
-int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
-
#endif /* __KVM_ARM_PSCI_H__ */
--
2.35.1.473.g83b2b277ed-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 117+ messages in thread* Re: [PATCH v4 01/13] KVM: arm64: Factor out firmware register handling from psci.c
2022-02-24 17:25 ` Raghavendra Rao Ananta
(?)
@ 2022-03-14 18:15 ` Oliver Upton
-1 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-14 18:15 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: kvm, Will Deacon, Marc Zyngier, Peter Shier, linux-kernel,
Catalin Marinas, Paolo Bonzini, kvmarm, linux-arm-kernel
Hi Raghu,
On Thu, Feb 24, 2022 at 05:25:47PM +0000, Raghavendra Rao Ananta wrote:
> Common hypercall firmware register handing is currently employed
> by psci.c. Since the upcoming patches add more of these registers,
> it's better to move the generic handling to hypercall.c for a
> cleaner presentation.
>
> While we are at it, collect all the firmware registers under
> fw_reg_ids[] to help implement kvm_arm_get_fw_num_regs() and
> kvm_arm_copy_fw_reg_indices() in a generic way.
>
> No functional change intended.
>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
You might owe a rebase, thanks to the new Spectre bits KVM picked up (in
Linus' tree) and PSCIv1.1 (kvmarm/next) :-)
Besides the nits:
Reviewed-by: Oliver Upton <oupton@google.com>
> ---
> arch/arm64/kvm/guest.c | 2 +-
> arch/arm64/kvm/hypercalls.c | 170 +++++++++++++++++++++++++++++++++++
> arch/arm64/kvm/psci.c | 166 ----------------------------------
> include/kvm/arm_hypercalls.h | 7 ++
> include/kvm/arm_psci.h | 7 --
> 5 files changed, 178 insertions(+), 174 deletions(-)
>
> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> index e116c7767730..8238e52d890d 100644
> --- a/arch/arm64/kvm/guest.c
> +++ b/arch/arm64/kvm/guest.c
> @@ -18,7 +18,7 @@
> #include <linux/string.h>
> #include <linux/vmalloc.h>
> #include <linux/fs.h>
> -#include <kvm/arm_psci.h>
> +#include <kvm/arm_hypercalls.h>
> #include <asm/cputype.h>
> #include <linux/uaccess.h>
> #include <asm/fpsimd.h>
> diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> index 30da78f72b3b..3c2fcf31ad3d 100644
> --- a/arch/arm64/kvm/hypercalls.c
> +++ b/arch/arm64/kvm/hypercalls.c
> @@ -146,3 +146,173 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> smccc_set_retval(vcpu, val[0], val[1], val[2], val[3]);
> return 1;
> }
> +
> +static const u64 kvm_arm_fw_reg_ids[] = {
> + KVM_REG_ARM_PSCI_VERSION,
> + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> +};
> +
> +int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> +{
> + return ARRAY_SIZE(kvm_arm_fw_reg_ids);
> +}
> +
> +int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(kvm_arm_fw_reg_ids); i++) {
> + if (put_user(kvm_arm_fw_reg_ids[i], uindices++))
> + return -EFAULT;
> + }
> +
> + return 0;
> +}
> +
> +#define KVM_REG_FEATURE_LEVEL_WIDTH 4
> +#define KVM_REG_FEATURE_LEVEL_MASK (BIT(KVM_REG_FEATURE_LEVEL_WIDTH) - 1)
Hrm... Not your code but this should really use GENMASK() to be
consistent with the rest of the kernel. Also, looks like _WIDTH is
useless.
Perhaps fold these together:
#define KVM_REG_FEATURE_LEVEL_MASK GENMASK(3, 0)
Also these kind of macros probably belong in headers.
> +
> +/*
> + * Convert the workaround level into an easy-to-compare number, where higher
> + * values mean better protection.
> + */
> +static int get_kernel_wa_level(u64 regid)
> +{
> + switch (regid) {
> + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> + switch (arm64_get_spectre_v2_state()) {
> + case SPECTRE_VULNERABLE:
> + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
> + case SPECTRE_MITIGATED:
> + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_AVAIL;
> + case SPECTRE_UNAFFECTED:
> + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_REQUIRED;
> + }
> + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
> + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> + switch (arm64_get_spectre_v4_state()) {
> + case SPECTRE_MITIGATED:
> + /*
> + * As for the hypercall discovery, we pretend we
> + * don't have any FW mitigation if SSBS is there at
> + * all times.
> + */
> + if (cpus_have_final_cap(ARM64_SSBS))
> + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> + fallthrough;
> + case SPECTRE_UNAFFECTED:
> + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
> + case SPECTRE_VULNERABLE:
> + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> + }
> + }
> +
> + return -EINVAL;
> +}
> +
> +int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> +{
> + void __user *uaddr = (void __user *)(long)reg->addr;
> + u64 val;
> +
> + switch (reg->id) {
> + case KVM_REG_ARM_PSCI_VERSION:
> + val = kvm_psci_version(vcpu, vcpu->kvm);
> + break;
> + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> + val = get_kernel_wa_level(reg->id) & KVM_REG_FEATURE_LEVEL_MASK;
> + break;
> + default:
> + return -ENOENT;
> + }
> +
> + if (copy_to_user(uaddr, &val, KVM_REG_SIZE(reg->id)))
> + return -EFAULT;
> +
> + return 0;
> +}
> +
> +int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> +{
> + void __user *uaddr = (void __user *)(long)reg->addr;
> + u64 val;
> + int wa_level;
> +
> + if (copy_from_user(&val, uaddr, KVM_REG_SIZE(reg->id)))
> + return -EFAULT;
> +
> + switch (reg->id) {
> + case KVM_REG_ARM_PSCI_VERSION:
> + {
> + bool wants_02;
> +
> + wants_02 = test_bit(KVM_ARM_VCPU_PSCI_0_2, vcpu->arch.features);
> +
> + switch (val) {
> + case KVM_ARM_PSCI_0_1:
> + if (wants_02)
> + return -EINVAL;
> + vcpu->kvm->arch.psci_version = val;
> + return 0;
> + case KVM_ARM_PSCI_0_2:
> + case KVM_ARM_PSCI_1_0:
> + if (!wants_02)
> + return -EINVAL;
> + vcpu->kvm->arch.psci_version = val;
> + return 0;
> + }
> + break;
> + }
> +
> + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> + if (val & ~KVM_REG_FEATURE_LEVEL_MASK)
> + return -EINVAL;
> +
> + if (get_kernel_wa_level(reg->id) < val)
> + return -EINVAL;
> +
> + return 0;
> +
> + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> + if (val & ~(KVM_REG_FEATURE_LEVEL_MASK |
> + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED))
> + return -EINVAL;
> +
> + /* The enabled bit must not be set unless the level is AVAIL. */
> + if ((val & KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED) &&
> + (val & KVM_REG_FEATURE_LEVEL_MASK) != KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL)
> + return -EINVAL;
> +
> + /*
> + * Map all the possible incoming states to the only two we
> + * really want to deal with.
> + */
> + switch (val & KVM_REG_FEATURE_LEVEL_MASK) {
> + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL:
> + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_UNKNOWN:
> + wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> + break;
> + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL:
> + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED:
> + wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + /*
> + * We can deal with NOT_AVAIL on NOT_REQUIRED, but not the
> + * other way around.
> + */
> + if (get_kernel_wa_level(reg->id) < wa_level)
> + return -EINVAL;
> +
> + return 0;
> + default:
> + return -ENOENT;
> + }
> +
> + return -EINVAL;
> +}
> diff --git a/arch/arm64/kvm/psci.c b/arch/arm64/kvm/psci.c
> index 3eae32876897..d5bc663a8629 100644
> --- a/arch/arm64/kvm/psci.c
> +++ b/arch/arm64/kvm/psci.c
> @@ -403,169 +403,3 @@ int kvm_psci_call(struct kvm_vcpu *vcpu)
> return -EINVAL;
> };
> }
> -
> -int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> -{
> - return 3; /* PSCI version and two workaround registers */
> -}
> -
> -int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
> -{
> - if (put_user(KVM_REG_ARM_PSCI_VERSION, uindices++))
> - return -EFAULT;
> -
> - if (put_user(KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1, uindices++))
> - return -EFAULT;
> -
> - if (put_user(KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2, uindices++))
> - return -EFAULT;
> -
> - return 0;
> -}
> -
> -#define KVM_REG_FEATURE_LEVEL_WIDTH 4
> -#define KVM_REG_FEATURE_LEVEL_MASK (BIT(KVM_REG_FEATURE_LEVEL_WIDTH) - 1)
> -
> -/*
> - * Convert the workaround level into an easy-to-compare number, where higher
> - * values mean better protection.
> - */
> -static int get_kernel_wa_level(u64 regid)
> -{
> - switch (regid) {
> - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> - switch (arm64_get_spectre_v2_state()) {
> - case SPECTRE_VULNERABLE:
> - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
> - case SPECTRE_MITIGATED:
> - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_AVAIL;
> - case SPECTRE_UNAFFECTED:
> - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_REQUIRED;
> - }
> - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
> - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> - switch (arm64_get_spectre_v4_state()) {
> - case SPECTRE_MITIGATED:
> - /*
> - * As for the hypercall discovery, we pretend we
> - * don't have any FW mitigation if SSBS is there at
> - * all times.
> - */
> - if (cpus_have_final_cap(ARM64_SSBS))
> - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> - fallthrough;
> - case SPECTRE_UNAFFECTED:
> - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
> - case SPECTRE_VULNERABLE:
> - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> - }
> - }
> -
> - return -EINVAL;
> -}
> -
> -int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> -{
> - void __user *uaddr = (void __user *)(long)reg->addr;
> - u64 val;
> -
> - switch (reg->id) {
> - case KVM_REG_ARM_PSCI_VERSION:
> - val = kvm_psci_version(vcpu, vcpu->kvm);
> - break;
> - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> - val = get_kernel_wa_level(reg->id) & KVM_REG_FEATURE_LEVEL_MASK;
> - break;
> - default:
> - return -ENOENT;
> - }
> -
> - if (copy_to_user(uaddr, &val, KVM_REG_SIZE(reg->id)))
> - return -EFAULT;
> -
> - return 0;
> -}
> -
> -int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> -{
> - void __user *uaddr = (void __user *)(long)reg->addr;
> - u64 val;
> - int wa_level;
> -
> - if (copy_from_user(&val, uaddr, KVM_REG_SIZE(reg->id)))
> - return -EFAULT;
> -
> - switch (reg->id) {
> - case KVM_REG_ARM_PSCI_VERSION:
> - {
> - bool wants_02;
> -
> - wants_02 = test_bit(KVM_ARM_VCPU_PSCI_0_2, vcpu->arch.features);
> -
> - switch (val) {
> - case KVM_ARM_PSCI_0_1:
> - if (wants_02)
> - return -EINVAL;
> - vcpu->kvm->arch.psci_version = val;
> - return 0;
> - case KVM_ARM_PSCI_0_2:
> - case KVM_ARM_PSCI_1_0:
> - if (!wants_02)
> - return -EINVAL;
> - vcpu->kvm->arch.psci_version = val;
> - return 0;
> - }
> - break;
> - }
> -
> - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> - if (val & ~KVM_REG_FEATURE_LEVEL_MASK)
> - return -EINVAL;
> -
> - if (get_kernel_wa_level(reg->id) < val)
> - return -EINVAL;
> -
> - return 0;
> -
> - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> - if (val & ~(KVM_REG_FEATURE_LEVEL_MASK |
> - KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED))
> - return -EINVAL;
> -
> - /* The enabled bit must not be set unless the level is AVAIL. */
> - if ((val & KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED) &&
> - (val & KVM_REG_FEATURE_LEVEL_MASK) != KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL)
> - return -EINVAL;
> -
> - /*
> - * Map all the possible incoming states to the only two we
> - * really want to deal with.
> - */
> - switch (val & KVM_REG_FEATURE_LEVEL_MASK) {
> - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL:
> - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_UNKNOWN:
> - wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> - break;
> - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL:
> - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED:
> - wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
> - break;
> - default:
> - return -EINVAL;
> - }
> -
> - /*
> - * We can deal with NOT_AVAIL on NOT_REQUIRED, but not the
> - * other way around.
> - */
> - if (get_kernel_wa_level(reg->id) < wa_level)
> - return -EINVAL;
> -
> - return 0;
> - default:
> - return -ENOENT;
> - }
> -
> - return -EINVAL;
> -}
> diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> index 0e2509d27910..5d38628a8d04 100644
> --- a/include/kvm/arm_hypercalls.h
> +++ b/include/kvm/arm_hypercalls.h
> @@ -40,4 +40,11 @@ static inline void smccc_set_retval(struct kvm_vcpu *vcpu,
> vcpu_set_reg(vcpu, 3, a3);
> }
>
> +struct kvm_one_reg;
> +
> +int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
> +int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
> +int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> +int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> +
> #endif
> diff --git a/include/kvm/arm_psci.h b/include/kvm/arm_psci.h
> index 5b58bd2fe088..080c2d0bd6e7 100644
> --- a/include/kvm/arm_psci.h
> +++ b/include/kvm/arm_psci.h
> @@ -42,11 +42,4 @@ static inline int kvm_psci_version(struct kvm_vcpu *vcpu, struct kvm *kvm)
>
> int kvm_psci_call(struct kvm_vcpu *vcpu);
>
> -struct kvm_one_reg;
> -
> -int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
> -int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
> -int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> -int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> -
> #endif /* __KVM_ARM_PSCI_H__ */
> --
> 2.35.1.473.g83b2b277ed-goog
>
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 01/13] KVM: arm64: Factor out firmware register handling from psci.c
@ 2022-03-14 18:15 ` Oliver Upton
0 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-14 18:15 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
Hi Raghu,
On Thu, Feb 24, 2022 at 05:25:47PM +0000, Raghavendra Rao Ananta wrote:
> Common hypercall firmware register handing is currently employed
> by psci.c. Since the upcoming patches add more of these registers,
> it's better to move the generic handling to hypercall.c for a
> cleaner presentation.
>
> While we are at it, collect all the firmware registers under
> fw_reg_ids[] to help implement kvm_arm_get_fw_num_regs() and
> kvm_arm_copy_fw_reg_indices() in a generic way.
>
> No functional change intended.
>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
You might owe a rebase, thanks to the new Spectre bits KVM picked up (in
Linus' tree) and PSCIv1.1 (kvmarm/next) :-)
Besides the nits:
Reviewed-by: Oliver Upton <oupton@google.com>
> ---
> arch/arm64/kvm/guest.c | 2 +-
> arch/arm64/kvm/hypercalls.c | 170 +++++++++++++++++++++++++++++++++++
> arch/arm64/kvm/psci.c | 166 ----------------------------------
> include/kvm/arm_hypercalls.h | 7 ++
> include/kvm/arm_psci.h | 7 --
> 5 files changed, 178 insertions(+), 174 deletions(-)
>
> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> index e116c7767730..8238e52d890d 100644
> --- a/arch/arm64/kvm/guest.c
> +++ b/arch/arm64/kvm/guest.c
> @@ -18,7 +18,7 @@
> #include <linux/string.h>
> #include <linux/vmalloc.h>
> #include <linux/fs.h>
> -#include <kvm/arm_psci.h>
> +#include <kvm/arm_hypercalls.h>
> #include <asm/cputype.h>
> #include <linux/uaccess.h>
> #include <asm/fpsimd.h>
> diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> index 30da78f72b3b..3c2fcf31ad3d 100644
> --- a/arch/arm64/kvm/hypercalls.c
> +++ b/arch/arm64/kvm/hypercalls.c
> @@ -146,3 +146,173 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> smccc_set_retval(vcpu, val[0], val[1], val[2], val[3]);
> return 1;
> }
> +
> +static const u64 kvm_arm_fw_reg_ids[] = {
> + KVM_REG_ARM_PSCI_VERSION,
> + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> +};
> +
> +int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> +{
> + return ARRAY_SIZE(kvm_arm_fw_reg_ids);
> +}
> +
> +int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(kvm_arm_fw_reg_ids); i++) {
> + if (put_user(kvm_arm_fw_reg_ids[i], uindices++))
> + return -EFAULT;
> + }
> +
> + return 0;
> +}
> +
> +#define KVM_REG_FEATURE_LEVEL_WIDTH 4
> +#define KVM_REG_FEATURE_LEVEL_MASK (BIT(KVM_REG_FEATURE_LEVEL_WIDTH) - 1)
Hrm... Not your code but this should really use GENMASK() to be
consistent with the rest of the kernel. Also, looks like _WIDTH is
useless.
Perhaps fold these together:
#define KVM_REG_FEATURE_LEVEL_MASK GENMASK(3, 0)
Also these kind of macros probably belong in headers.
> +
> +/*
> + * Convert the workaround level into an easy-to-compare number, where higher
> + * values mean better protection.
> + */
> +static int get_kernel_wa_level(u64 regid)
> +{
> + switch (regid) {
> + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> + switch (arm64_get_spectre_v2_state()) {
> + case SPECTRE_VULNERABLE:
> + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
> + case SPECTRE_MITIGATED:
> + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_AVAIL;
> + case SPECTRE_UNAFFECTED:
> + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_REQUIRED;
> + }
> + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
> + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> + switch (arm64_get_spectre_v4_state()) {
> + case SPECTRE_MITIGATED:
> + /*
> + * As for the hypercall discovery, we pretend we
> + * don't have any FW mitigation if SSBS is there at
> + * all times.
> + */
> + if (cpus_have_final_cap(ARM64_SSBS))
> + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> + fallthrough;
> + case SPECTRE_UNAFFECTED:
> + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
> + case SPECTRE_VULNERABLE:
> + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> + }
> + }
> +
> + return -EINVAL;
> +}
> +
> +int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> +{
> + void __user *uaddr = (void __user *)(long)reg->addr;
> + u64 val;
> +
> + switch (reg->id) {
> + case KVM_REG_ARM_PSCI_VERSION:
> + val = kvm_psci_version(vcpu, vcpu->kvm);
> + break;
> + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> + val = get_kernel_wa_level(reg->id) & KVM_REG_FEATURE_LEVEL_MASK;
> + break;
> + default:
> + return -ENOENT;
> + }
> +
> + if (copy_to_user(uaddr, &val, KVM_REG_SIZE(reg->id)))
> + return -EFAULT;
> +
> + return 0;
> +}
> +
> +int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> +{
> + void __user *uaddr = (void __user *)(long)reg->addr;
> + u64 val;
> + int wa_level;
> +
> + if (copy_from_user(&val, uaddr, KVM_REG_SIZE(reg->id)))
> + return -EFAULT;
> +
> + switch (reg->id) {
> + case KVM_REG_ARM_PSCI_VERSION:
> + {
> + bool wants_02;
> +
> + wants_02 = test_bit(KVM_ARM_VCPU_PSCI_0_2, vcpu->arch.features);
> +
> + switch (val) {
> + case KVM_ARM_PSCI_0_1:
> + if (wants_02)
> + return -EINVAL;
> + vcpu->kvm->arch.psci_version = val;
> + return 0;
> + case KVM_ARM_PSCI_0_2:
> + case KVM_ARM_PSCI_1_0:
> + if (!wants_02)
> + return -EINVAL;
> + vcpu->kvm->arch.psci_version = val;
> + return 0;
> + }
> + break;
> + }
> +
> + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> + if (val & ~KVM_REG_FEATURE_LEVEL_MASK)
> + return -EINVAL;
> +
> + if (get_kernel_wa_level(reg->id) < val)
> + return -EINVAL;
> +
> + return 0;
> +
> + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> + if (val & ~(KVM_REG_FEATURE_LEVEL_MASK |
> + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED))
> + return -EINVAL;
> +
> + /* The enabled bit must not be set unless the level is AVAIL. */
> + if ((val & KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED) &&
> + (val & KVM_REG_FEATURE_LEVEL_MASK) != KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL)
> + return -EINVAL;
> +
> + /*
> + * Map all the possible incoming states to the only two we
> + * really want to deal with.
> + */
> + switch (val & KVM_REG_FEATURE_LEVEL_MASK) {
> + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL:
> + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_UNKNOWN:
> + wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> + break;
> + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL:
> + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED:
> + wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + /*
> + * We can deal with NOT_AVAIL on NOT_REQUIRED, but not the
> + * other way around.
> + */
> + if (get_kernel_wa_level(reg->id) < wa_level)
> + return -EINVAL;
> +
> + return 0;
> + default:
> + return -ENOENT;
> + }
> +
> + return -EINVAL;
> +}
> diff --git a/arch/arm64/kvm/psci.c b/arch/arm64/kvm/psci.c
> index 3eae32876897..d5bc663a8629 100644
> --- a/arch/arm64/kvm/psci.c
> +++ b/arch/arm64/kvm/psci.c
> @@ -403,169 +403,3 @@ int kvm_psci_call(struct kvm_vcpu *vcpu)
> return -EINVAL;
> };
> }
> -
> -int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> -{
> - return 3; /* PSCI version and two workaround registers */
> -}
> -
> -int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
> -{
> - if (put_user(KVM_REG_ARM_PSCI_VERSION, uindices++))
> - return -EFAULT;
> -
> - if (put_user(KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1, uindices++))
> - return -EFAULT;
> -
> - if (put_user(KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2, uindices++))
> - return -EFAULT;
> -
> - return 0;
> -}
> -
> -#define KVM_REG_FEATURE_LEVEL_WIDTH 4
> -#define KVM_REG_FEATURE_LEVEL_MASK (BIT(KVM_REG_FEATURE_LEVEL_WIDTH) - 1)
> -
> -/*
> - * Convert the workaround level into an easy-to-compare number, where higher
> - * values mean better protection.
> - */
> -static int get_kernel_wa_level(u64 regid)
> -{
> - switch (regid) {
> - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> - switch (arm64_get_spectre_v2_state()) {
> - case SPECTRE_VULNERABLE:
> - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
> - case SPECTRE_MITIGATED:
> - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_AVAIL;
> - case SPECTRE_UNAFFECTED:
> - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_REQUIRED;
> - }
> - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
> - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> - switch (arm64_get_spectre_v4_state()) {
> - case SPECTRE_MITIGATED:
> - /*
> - * As for the hypercall discovery, we pretend we
> - * don't have any FW mitigation if SSBS is there at
> - * all times.
> - */
> - if (cpus_have_final_cap(ARM64_SSBS))
> - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> - fallthrough;
> - case SPECTRE_UNAFFECTED:
> - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
> - case SPECTRE_VULNERABLE:
> - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> - }
> - }
> -
> - return -EINVAL;
> -}
> -
> -int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> -{
> - void __user *uaddr = (void __user *)(long)reg->addr;
> - u64 val;
> -
> - switch (reg->id) {
> - case KVM_REG_ARM_PSCI_VERSION:
> - val = kvm_psci_version(vcpu, vcpu->kvm);
> - break;
> - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> - val = get_kernel_wa_level(reg->id) & KVM_REG_FEATURE_LEVEL_MASK;
> - break;
> - default:
> - return -ENOENT;
> - }
> -
> - if (copy_to_user(uaddr, &val, KVM_REG_SIZE(reg->id)))
> - return -EFAULT;
> -
> - return 0;
> -}
> -
> -int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> -{
> - void __user *uaddr = (void __user *)(long)reg->addr;
> - u64 val;
> - int wa_level;
> -
> - if (copy_from_user(&val, uaddr, KVM_REG_SIZE(reg->id)))
> - return -EFAULT;
> -
> - switch (reg->id) {
> - case KVM_REG_ARM_PSCI_VERSION:
> - {
> - bool wants_02;
> -
> - wants_02 = test_bit(KVM_ARM_VCPU_PSCI_0_2, vcpu->arch.features);
> -
> - switch (val) {
> - case KVM_ARM_PSCI_0_1:
> - if (wants_02)
> - return -EINVAL;
> - vcpu->kvm->arch.psci_version = val;
> - return 0;
> - case KVM_ARM_PSCI_0_2:
> - case KVM_ARM_PSCI_1_0:
> - if (!wants_02)
> - return -EINVAL;
> - vcpu->kvm->arch.psci_version = val;
> - return 0;
> - }
> - break;
> - }
> -
> - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> - if (val & ~KVM_REG_FEATURE_LEVEL_MASK)
> - return -EINVAL;
> -
> - if (get_kernel_wa_level(reg->id) < val)
> - return -EINVAL;
> -
> - return 0;
> -
> - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> - if (val & ~(KVM_REG_FEATURE_LEVEL_MASK |
> - KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED))
> - return -EINVAL;
> -
> - /* The enabled bit must not be set unless the level is AVAIL. */
> - if ((val & KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED) &&
> - (val & KVM_REG_FEATURE_LEVEL_MASK) != KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL)
> - return -EINVAL;
> -
> - /*
> - * Map all the possible incoming states to the only two we
> - * really want to deal with.
> - */
> - switch (val & KVM_REG_FEATURE_LEVEL_MASK) {
> - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL:
> - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_UNKNOWN:
> - wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> - break;
> - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL:
> - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED:
> - wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
> - break;
> - default:
> - return -EINVAL;
> - }
> -
> - /*
> - * We can deal with NOT_AVAIL on NOT_REQUIRED, but not the
> - * other way around.
> - */
> - if (get_kernel_wa_level(reg->id) < wa_level)
> - return -EINVAL;
> -
> - return 0;
> - default:
> - return -ENOENT;
> - }
> -
> - return -EINVAL;
> -}
> diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> index 0e2509d27910..5d38628a8d04 100644
> --- a/include/kvm/arm_hypercalls.h
> +++ b/include/kvm/arm_hypercalls.h
> @@ -40,4 +40,11 @@ static inline void smccc_set_retval(struct kvm_vcpu *vcpu,
> vcpu_set_reg(vcpu, 3, a3);
> }
>
> +struct kvm_one_reg;
> +
> +int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
> +int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
> +int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> +int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> +
> #endif
> diff --git a/include/kvm/arm_psci.h b/include/kvm/arm_psci.h
> index 5b58bd2fe088..080c2d0bd6e7 100644
> --- a/include/kvm/arm_psci.h
> +++ b/include/kvm/arm_psci.h
> @@ -42,11 +42,4 @@ static inline int kvm_psci_version(struct kvm_vcpu *vcpu, struct kvm *kvm)
>
> int kvm_psci_call(struct kvm_vcpu *vcpu);
>
> -struct kvm_one_reg;
> -
> -int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
> -int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
> -int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> -int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> -
> #endif /* __KVM_ARM_PSCI_H__ */
> --
> 2.35.1.473.g83b2b277ed-goog
>
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 01/13] KVM: arm64: Factor out firmware register handling from psci.c
@ 2022-03-14 18:15 ` Oliver Upton
0 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-14 18:15 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
Hi Raghu,
On Thu, Feb 24, 2022 at 05:25:47PM +0000, Raghavendra Rao Ananta wrote:
> Common hypercall firmware register handing is currently employed
> by psci.c. Since the upcoming patches add more of these registers,
> it's better to move the generic handling to hypercall.c for a
> cleaner presentation.
>
> While we are at it, collect all the firmware registers under
> fw_reg_ids[] to help implement kvm_arm_get_fw_num_regs() and
> kvm_arm_copy_fw_reg_indices() in a generic way.
>
> No functional change intended.
>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
You might owe a rebase, thanks to the new Spectre bits KVM picked up (in
Linus' tree) and PSCIv1.1 (kvmarm/next) :-)
Besides the nits:
Reviewed-by: Oliver Upton <oupton@google.com>
> ---
> arch/arm64/kvm/guest.c | 2 +-
> arch/arm64/kvm/hypercalls.c | 170 +++++++++++++++++++++++++++++++++++
> arch/arm64/kvm/psci.c | 166 ----------------------------------
> include/kvm/arm_hypercalls.h | 7 ++
> include/kvm/arm_psci.h | 7 --
> 5 files changed, 178 insertions(+), 174 deletions(-)
>
> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> index e116c7767730..8238e52d890d 100644
> --- a/arch/arm64/kvm/guest.c
> +++ b/arch/arm64/kvm/guest.c
> @@ -18,7 +18,7 @@
> #include <linux/string.h>
> #include <linux/vmalloc.h>
> #include <linux/fs.h>
> -#include <kvm/arm_psci.h>
> +#include <kvm/arm_hypercalls.h>
> #include <asm/cputype.h>
> #include <linux/uaccess.h>
> #include <asm/fpsimd.h>
> diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> index 30da78f72b3b..3c2fcf31ad3d 100644
> --- a/arch/arm64/kvm/hypercalls.c
> +++ b/arch/arm64/kvm/hypercalls.c
> @@ -146,3 +146,173 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> smccc_set_retval(vcpu, val[0], val[1], val[2], val[3]);
> return 1;
> }
> +
> +static const u64 kvm_arm_fw_reg_ids[] = {
> + KVM_REG_ARM_PSCI_VERSION,
> + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> +};
> +
> +int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> +{
> + return ARRAY_SIZE(kvm_arm_fw_reg_ids);
> +}
> +
> +int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(kvm_arm_fw_reg_ids); i++) {
> + if (put_user(kvm_arm_fw_reg_ids[i], uindices++))
> + return -EFAULT;
> + }
> +
> + return 0;
> +}
> +
> +#define KVM_REG_FEATURE_LEVEL_WIDTH 4
> +#define KVM_REG_FEATURE_LEVEL_MASK (BIT(KVM_REG_FEATURE_LEVEL_WIDTH) - 1)
Hrm... Not your code but this should really use GENMASK() to be
consistent with the rest of the kernel. Also, looks like _WIDTH is
useless.
Perhaps fold these together:
#define KVM_REG_FEATURE_LEVEL_MASK GENMASK(3, 0)
Also these kind of macros probably belong in headers.
> +
> +/*
> + * Convert the workaround level into an easy-to-compare number, where higher
> + * values mean better protection.
> + */
> +static int get_kernel_wa_level(u64 regid)
> +{
> + switch (regid) {
> + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> + switch (arm64_get_spectre_v2_state()) {
> + case SPECTRE_VULNERABLE:
> + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
> + case SPECTRE_MITIGATED:
> + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_AVAIL;
> + case SPECTRE_UNAFFECTED:
> + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_REQUIRED;
> + }
> + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
> + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> + switch (arm64_get_spectre_v4_state()) {
> + case SPECTRE_MITIGATED:
> + /*
> + * As for the hypercall discovery, we pretend we
> + * don't have any FW mitigation if SSBS is there at
> + * all times.
> + */
> + if (cpus_have_final_cap(ARM64_SSBS))
> + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> + fallthrough;
> + case SPECTRE_UNAFFECTED:
> + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
> + case SPECTRE_VULNERABLE:
> + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> + }
> + }
> +
> + return -EINVAL;
> +}
> +
> +int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> +{
> + void __user *uaddr = (void __user *)(long)reg->addr;
> + u64 val;
> +
> + switch (reg->id) {
> + case KVM_REG_ARM_PSCI_VERSION:
> + val = kvm_psci_version(vcpu, vcpu->kvm);
> + break;
> + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> + val = get_kernel_wa_level(reg->id) & KVM_REG_FEATURE_LEVEL_MASK;
> + break;
> + default:
> + return -ENOENT;
> + }
> +
> + if (copy_to_user(uaddr, &val, KVM_REG_SIZE(reg->id)))
> + return -EFAULT;
> +
> + return 0;
> +}
> +
> +int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> +{
> + void __user *uaddr = (void __user *)(long)reg->addr;
> + u64 val;
> + int wa_level;
> +
> + if (copy_from_user(&val, uaddr, KVM_REG_SIZE(reg->id)))
> + return -EFAULT;
> +
> + switch (reg->id) {
> + case KVM_REG_ARM_PSCI_VERSION:
> + {
> + bool wants_02;
> +
> + wants_02 = test_bit(KVM_ARM_VCPU_PSCI_0_2, vcpu->arch.features);
> +
> + switch (val) {
> + case KVM_ARM_PSCI_0_1:
> + if (wants_02)
> + return -EINVAL;
> + vcpu->kvm->arch.psci_version = val;
> + return 0;
> + case KVM_ARM_PSCI_0_2:
> + case KVM_ARM_PSCI_1_0:
> + if (!wants_02)
> + return -EINVAL;
> + vcpu->kvm->arch.psci_version = val;
> + return 0;
> + }
> + break;
> + }
> +
> + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> + if (val & ~KVM_REG_FEATURE_LEVEL_MASK)
> + return -EINVAL;
> +
> + if (get_kernel_wa_level(reg->id) < val)
> + return -EINVAL;
> +
> + return 0;
> +
> + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> + if (val & ~(KVM_REG_FEATURE_LEVEL_MASK |
> + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED))
> + return -EINVAL;
> +
> + /* The enabled bit must not be set unless the level is AVAIL. */
> + if ((val & KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED) &&
> + (val & KVM_REG_FEATURE_LEVEL_MASK) != KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL)
> + return -EINVAL;
> +
> + /*
> + * Map all the possible incoming states to the only two we
> + * really want to deal with.
> + */
> + switch (val & KVM_REG_FEATURE_LEVEL_MASK) {
> + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL:
> + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_UNKNOWN:
> + wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> + break;
> + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL:
> + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED:
> + wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + /*
> + * We can deal with NOT_AVAIL on NOT_REQUIRED, but not the
> + * other way around.
> + */
> + if (get_kernel_wa_level(reg->id) < wa_level)
> + return -EINVAL;
> +
> + return 0;
> + default:
> + return -ENOENT;
> + }
> +
> + return -EINVAL;
> +}
> diff --git a/arch/arm64/kvm/psci.c b/arch/arm64/kvm/psci.c
> index 3eae32876897..d5bc663a8629 100644
> --- a/arch/arm64/kvm/psci.c
> +++ b/arch/arm64/kvm/psci.c
> @@ -403,169 +403,3 @@ int kvm_psci_call(struct kvm_vcpu *vcpu)
> return -EINVAL;
> };
> }
> -
> -int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> -{
> - return 3; /* PSCI version and two workaround registers */
> -}
> -
> -int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
> -{
> - if (put_user(KVM_REG_ARM_PSCI_VERSION, uindices++))
> - return -EFAULT;
> -
> - if (put_user(KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1, uindices++))
> - return -EFAULT;
> -
> - if (put_user(KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2, uindices++))
> - return -EFAULT;
> -
> - return 0;
> -}
> -
> -#define KVM_REG_FEATURE_LEVEL_WIDTH 4
> -#define KVM_REG_FEATURE_LEVEL_MASK (BIT(KVM_REG_FEATURE_LEVEL_WIDTH) - 1)
> -
> -/*
> - * Convert the workaround level into an easy-to-compare number, where higher
> - * values mean better protection.
> - */
> -static int get_kernel_wa_level(u64 regid)
> -{
> - switch (regid) {
> - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> - switch (arm64_get_spectre_v2_state()) {
> - case SPECTRE_VULNERABLE:
> - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
> - case SPECTRE_MITIGATED:
> - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_AVAIL;
> - case SPECTRE_UNAFFECTED:
> - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_REQUIRED;
> - }
> - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
> - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> - switch (arm64_get_spectre_v4_state()) {
> - case SPECTRE_MITIGATED:
> - /*
> - * As for the hypercall discovery, we pretend we
> - * don't have any FW mitigation if SSBS is there at
> - * all times.
> - */
> - if (cpus_have_final_cap(ARM64_SSBS))
> - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> - fallthrough;
> - case SPECTRE_UNAFFECTED:
> - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
> - case SPECTRE_VULNERABLE:
> - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> - }
> - }
> -
> - return -EINVAL;
> -}
> -
> -int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> -{
> - void __user *uaddr = (void __user *)(long)reg->addr;
> - u64 val;
> -
> - switch (reg->id) {
> - case KVM_REG_ARM_PSCI_VERSION:
> - val = kvm_psci_version(vcpu, vcpu->kvm);
> - break;
> - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> - val = get_kernel_wa_level(reg->id) & KVM_REG_FEATURE_LEVEL_MASK;
> - break;
> - default:
> - return -ENOENT;
> - }
> -
> - if (copy_to_user(uaddr, &val, KVM_REG_SIZE(reg->id)))
> - return -EFAULT;
> -
> - return 0;
> -}
> -
> -int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> -{
> - void __user *uaddr = (void __user *)(long)reg->addr;
> - u64 val;
> - int wa_level;
> -
> - if (copy_from_user(&val, uaddr, KVM_REG_SIZE(reg->id)))
> - return -EFAULT;
> -
> - switch (reg->id) {
> - case KVM_REG_ARM_PSCI_VERSION:
> - {
> - bool wants_02;
> -
> - wants_02 = test_bit(KVM_ARM_VCPU_PSCI_0_2, vcpu->arch.features);
> -
> - switch (val) {
> - case KVM_ARM_PSCI_0_1:
> - if (wants_02)
> - return -EINVAL;
> - vcpu->kvm->arch.psci_version = val;
> - return 0;
> - case KVM_ARM_PSCI_0_2:
> - case KVM_ARM_PSCI_1_0:
> - if (!wants_02)
> - return -EINVAL;
> - vcpu->kvm->arch.psci_version = val;
> - return 0;
> - }
> - break;
> - }
> -
> - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> - if (val & ~KVM_REG_FEATURE_LEVEL_MASK)
> - return -EINVAL;
> -
> - if (get_kernel_wa_level(reg->id) < val)
> - return -EINVAL;
> -
> - return 0;
> -
> - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> - if (val & ~(KVM_REG_FEATURE_LEVEL_MASK |
> - KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED))
> - return -EINVAL;
> -
> - /* The enabled bit must not be set unless the level is AVAIL. */
> - if ((val & KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED) &&
> - (val & KVM_REG_FEATURE_LEVEL_MASK) != KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL)
> - return -EINVAL;
> -
> - /*
> - * Map all the possible incoming states to the only two we
> - * really want to deal with.
> - */
> - switch (val & KVM_REG_FEATURE_LEVEL_MASK) {
> - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL:
> - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_UNKNOWN:
> - wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> - break;
> - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL:
> - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED:
> - wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
> - break;
> - default:
> - return -EINVAL;
> - }
> -
> - /*
> - * We can deal with NOT_AVAIL on NOT_REQUIRED, but not the
> - * other way around.
> - */
> - if (get_kernel_wa_level(reg->id) < wa_level)
> - return -EINVAL;
> -
> - return 0;
> - default:
> - return -ENOENT;
> - }
> -
> - return -EINVAL;
> -}
> diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> index 0e2509d27910..5d38628a8d04 100644
> --- a/include/kvm/arm_hypercalls.h
> +++ b/include/kvm/arm_hypercalls.h
> @@ -40,4 +40,11 @@ static inline void smccc_set_retval(struct kvm_vcpu *vcpu,
> vcpu_set_reg(vcpu, 3, a3);
> }
>
> +struct kvm_one_reg;
> +
> +int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
> +int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
> +int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> +int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> +
> #endif
> diff --git a/include/kvm/arm_psci.h b/include/kvm/arm_psci.h
> index 5b58bd2fe088..080c2d0bd6e7 100644
> --- a/include/kvm/arm_psci.h
> +++ b/include/kvm/arm_psci.h
> @@ -42,11 +42,4 @@ static inline int kvm_psci_version(struct kvm_vcpu *vcpu, struct kvm *kvm)
>
> int kvm_psci_call(struct kvm_vcpu *vcpu);
>
> -struct kvm_one_reg;
> -
> -int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
> -int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
> -int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> -int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> -
> #endif /* __KVM_ARM_PSCI_H__ */
> --
> 2.35.1.473.g83b2b277ed-goog
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 01/13] KVM: arm64: Factor out firmware register handling from psci.c
2022-03-14 18:15 ` Oliver Upton
(?)
@ 2022-03-14 23:15 ` Raghavendra Rao Ananta
-1 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-03-14 23:15 UTC (permalink / raw)
To: Oliver Upton
Cc: kvm, Will Deacon, Marc Zyngier, Peter Shier, linux-kernel,
Catalin Marinas, Paolo Bonzini, kvmarm, linux-arm-kernel
On Mon, Mar 14, 2022 at 11:15 AM Oliver Upton <oupton@google.com> wrote:
>
> Hi Raghu,
>
> On Thu, Feb 24, 2022 at 05:25:47PM +0000, Raghavendra Rao Ananta wrote:
> > Common hypercall firmware register handing is currently employed
> > by psci.c. Since the upcoming patches add more of these registers,
> > it's better to move the generic handling to hypercall.c for a
> > cleaner presentation.
> >
> > While we are at it, collect all the firmware registers under
> > fw_reg_ids[] to help implement kvm_arm_get_fw_num_regs() and
> > kvm_arm_copy_fw_reg_indices() in a generic way.
> >
> > No functional change intended.
> >
> > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
>
> You might owe a rebase, thanks to the new Spectre bits KVM picked up (in
> Linus' tree) and PSCIv1.1 (kvmarm/next) :-)
>
> Besides the nits:
>
> Reviewed-by: Oliver Upton <oupton@google.com>
>
> > ---
> > arch/arm64/kvm/guest.c | 2 +-
> > arch/arm64/kvm/hypercalls.c | 170 +++++++++++++++++++++++++++++++++++
> > arch/arm64/kvm/psci.c | 166 ----------------------------------
> > include/kvm/arm_hypercalls.h | 7 ++
> > include/kvm/arm_psci.h | 7 --
> > 5 files changed, 178 insertions(+), 174 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> > index e116c7767730..8238e52d890d 100644
> > --- a/arch/arm64/kvm/guest.c
> > +++ b/arch/arm64/kvm/guest.c
> > @@ -18,7 +18,7 @@
> > #include <linux/string.h>
> > #include <linux/vmalloc.h>
> > #include <linux/fs.h>
> > -#include <kvm/arm_psci.h>
> > +#include <kvm/arm_hypercalls.h>
> > #include <asm/cputype.h>
> > #include <linux/uaccess.h>
> > #include <asm/fpsimd.h>
> > diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> > index 30da78f72b3b..3c2fcf31ad3d 100644
> > --- a/arch/arm64/kvm/hypercalls.c
> > +++ b/arch/arm64/kvm/hypercalls.c
> > @@ -146,3 +146,173 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > smccc_set_retval(vcpu, val[0], val[1], val[2], val[3]);
> > return 1;
> > }
> > +
> > +static const u64 kvm_arm_fw_reg_ids[] = {
> > + KVM_REG_ARM_PSCI_VERSION,
> > + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> > + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > +};
> > +
> > +int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> > +{
> > + return ARRAY_SIZE(kvm_arm_fw_reg_ids);
> > +}
> > +
> > +int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < ARRAY_SIZE(kvm_arm_fw_reg_ids); i++) {
> > + if (put_user(kvm_arm_fw_reg_ids[i], uindices++))
> > + return -EFAULT;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +#define KVM_REG_FEATURE_LEVEL_WIDTH 4
> > +#define KVM_REG_FEATURE_LEVEL_MASK (BIT(KVM_REG_FEATURE_LEVEL_WIDTH) - 1)
>
> Hrm... Not your code but this should really use GENMASK() to be
> consistent with the rest of the kernel. Also, looks like _WIDTH is
> useless.
>
> Perhaps fold these together:
>
> #define KVM_REG_FEATURE_LEVEL_MASK GENMASK(3, 0)
>
> Also these kind of macros probably belong in headers.
>
Thanks for the suggestion. I'll definitely rebase and will try to
clean these up as well.
Regards,
Raghavendra
> > +
> > +/*
> > + * Convert the workaround level into an easy-to-compare number, where higher
> > + * values mean better protection.
> > + */
> > +static int get_kernel_wa_level(u64 regid)
> > +{
> > + switch (regid) {
> > + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> > + switch (arm64_get_spectre_v2_state()) {
> > + case SPECTRE_VULNERABLE:
> > + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
> > + case SPECTRE_MITIGATED:
> > + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_AVAIL;
> > + case SPECTRE_UNAFFECTED:
> > + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_REQUIRED;
> > + }
> > + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
> > + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> > + switch (arm64_get_spectre_v4_state()) {
> > + case SPECTRE_MITIGATED:
> > + /*
> > + * As for the hypercall discovery, we pretend we
> > + * don't have any FW mitigation if SSBS is there at
> > + * all times.
> > + */
> > + if (cpus_have_final_cap(ARM64_SSBS))
> > + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> > + fallthrough;
> > + case SPECTRE_UNAFFECTED:
> > + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
> > + case SPECTRE_VULNERABLE:
> > + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> > + }
> > + }
> > +
> > + return -EINVAL;
> > +}
> > +
> > +int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > +{
> > + void __user *uaddr = (void __user *)(long)reg->addr;
> > + u64 val;
> > +
> > + switch (reg->id) {
> > + case KVM_REG_ARM_PSCI_VERSION:
> > + val = kvm_psci_version(vcpu, vcpu->kvm);
> > + break;
> > + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> > + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> > + val = get_kernel_wa_level(reg->id) & KVM_REG_FEATURE_LEVEL_MASK;
> > + break;
> > + default:
> > + return -ENOENT;
> > + }
> > +
> > + if (copy_to_user(uaddr, &val, KVM_REG_SIZE(reg->id)))
> > + return -EFAULT;
> > +
> > + return 0;
> > +}
> > +
> > +int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > +{
> > + void __user *uaddr = (void __user *)(long)reg->addr;
> > + u64 val;
> > + int wa_level;
> > +
> > + if (copy_from_user(&val, uaddr, KVM_REG_SIZE(reg->id)))
> > + return -EFAULT;
> > +
> > + switch (reg->id) {
> > + case KVM_REG_ARM_PSCI_VERSION:
> > + {
> > + bool wants_02;
> > +
> > + wants_02 = test_bit(KVM_ARM_VCPU_PSCI_0_2, vcpu->arch.features);
> > +
> > + switch (val) {
> > + case KVM_ARM_PSCI_0_1:
> > + if (wants_02)
> > + return -EINVAL;
> > + vcpu->kvm->arch.psci_version = val;
> > + return 0;
> > + case KVM_ARM_PSCI_0_2:
> > + case KVM_ARM_PSCI_1_0:
> > + if (!wants_02)
> > + return -EINVAL;
> > + vcpu->kvm->arch.psci_version = val;
> > + return 0;
> > + }
> > + break;
> > + }
> > +
> > + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> > + if (val & ~KVM_REG_FEATURE_LEVEL_MASK)
> > + return -EINVAL;
> > +
> > + if (get_kernel_wa_level(reg->id) < val)
> > + return -EINVAL;
> > +
> > + return 0;
> > +
> > + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> > + if (val & ~(KVM_REG_FEATURE_LEVEL_MASK |
> > + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED))
> > + return -EINVAL;
> > +
> > + /* The enabled bit must not be set unless the level is AVAIL. */
> > + if ((val & KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED) &&
> > + (val & KVM_REG_FEATURE_LEVEL_MASK) != KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL)
> > + return -EINVAL;
> > +
> > + /*
> > + * Map all the possible incoming states to the only two we
> > + * really want to deal with.
> > + */
> > + switch (val & KVM_REG_FEATURE_LEVEL_MASK) {
> > + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL:
> > + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_UNKNOWN:
> > + wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> > + break;
> > + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL:
> > + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED:
> > + wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
> > + break;
> > + default:
> > + return -EINVAL;
> > + }
> > +
> > + /*
> > + * We can deal with NOT_AVAIL on NOT_REQUIRED, but not the
> > + * other way around.
> > + */
> > + if (get_kernel_wa_level(reg->id) < wa_level)
> > + return -EINVAL;
> > +
> > + return 0;
> > + default:
> > + return -ENOENT;
> > + }
> > +
> > + return -EINVAL;
> > +}
> > diff --git a/arch/arm64/kvm/psci.c b/arch/arm64/kvm/psci.c
> > index 3eae32876897..d5bc663a8629 100644
> > --- a/arch/arm64/kvm/psci.c
> > +++ b/arch/arm64/kvm/psci.c
> > @@ -403,169 +403,3 @@ int kvm_psci_call(struct kvm_vcpu *vcpu)
> > return -EINVAL;
> > };
> > }
> > -
> > -int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> > -{
> > - return 3; /* PSCI version and two workaround registers */
> > -}
> > -
> > -int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
> > -{
> > - if (put_user(KVM_REG_ARM_PSCI_VERSION, uindices++))
> > - return -EFAULT;
> > -
> > - if (put_user(KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1, uindices++))
> > - return -EFAULT;
> > -
> > - if (put_user(KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2, uindices++))
> > - return -EFAULT;
> > -
> > - return 0;
> > -}
> > -
> > -#define KVM_REG_FEATURE_LEVEL_WIDTH 4
> > -#define KVM_REG_FEATURE_LEVEL_MASK (BIT(KVM_REG_FEATURE_LEVEL_WIDTH) - 1)
> > -
> > -/*
> > - * Convert the workaround level into an easy-to-compare number, where higher
> > - * values mean better protection.
> > - */
> > -static int get_kernel_wa_level(u64 regid)
> > -{
> > - switch (regid) {
> > - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> > - switch (arm64_get_spectre_v2_state()) {
> > - case SPECTRE_VULNERABLE:
> > - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
> > - case SPECTRE_MITIGATED:
> > - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_AVAIL;
> > - case SPECTRE_UNAFFECTED:
> > - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_REQUIRED;
> > - }
> > - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
> > - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> > - switch (arm64_get_spectre_v4_state()) {
> > - case SPECTRE_MITIGATED:
> > - /*
> > - * As for the hypercall discovery, we pretend we
> > - * don't have any FW mitigation if SSBS is there at
> > - * all times.
> > - */
> > - if (cpus_have_final_cap(ARM64_SSBS))
> > - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> > - fallthrough;
> > - case SPECTRE_UNAFFECTED:
> > - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
> > - case SPECTRE_VULNERABLE:
> > - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> > - }
> > - }
> > -
> > - return -EINVAL;
> > -}
> > -
> > -int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > -{
> > - void __user *uaddr = (void __user *)(long)reg->addr;
> > - u64 val;
> > -
> > - switch (reg->id) {
> > - case KVM_REG_ARM_PSCI_VERSION:
> > - val = kvm_psci_version(vcpu, vcpu->kvm);
> > - break;
> > - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> > - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> > - val = get_kernel_wa_level(reg->id) & KVM_REG_FEATURE_LEVEL_MASK;
> > - break;
> > - default:
> > - return -ENOENT;
> > - }
> > -
> > - if (copy_to_user(uaddr, &val, KVM_REG_SIZE(reg->id)))
> > - return -EFAULT;
> > -
> > - return 0;
> > -}
> > -
> > -int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > -{
> > - void __user *uaddr = (void __user *)(long)reg->addr;
> > - u64 val;
> > - int wa_level;
> > -
> > - if (copy_from_user(&val, uaddr, KVM_REG_SIZE(reg->id)))
> > - return -EFAULT;
> > -
> > - switch (reg->id) {
> > - case KVM_REG_ARM_PSCI_VERSION:
> > - {
> > - bool wants_02;
> > -
> > - wants_02 = test_bit(KVM_ARM_VCPU_PSCI_0_2, vcpu->arch.features);
> > -
> > - switch (val) {
> > - case KVM_ARM_PSCI_0_1:
> > - if (wants_02)
> > - return -EINVAL;
> > - vcpu->kvm->arch.psci_version = val;
> > - return 0;
> > - case KVM_ARM_PSCI_0_2:
> > - case KVM_ARM_PSCI_1_0:
> > - if (!wants_02)
> > - return -EINVAL;
> > - vcpu->kvm->arch.psci_version = val;
> > - return 0;
> > - }
> > - break;
> > - }
> > -
> > - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> > - if (val & ~KVM_REG_FEATURE_LEVEL_MASK)
> > - return -EINVAL;
> > -
> > - if (get_kernel_wa_level(reg->id) < val)
> > - return -EINVAL;
> > -
> > - return 0;
> > -
> > - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> > - if (val & ~(KVM_REG_FEATURE_LEVEL_MASK |
> > - KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED))
> > - return -EINVAL;
> > -
> > - /* The enabled bit must not be set unless the level is AVAIL. */
> > - if ((val & KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED) &&
> > - (val & KVM_REG_FEATURE_LEVEL_MASK) != KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL)
> > - return -EINVAL;
> > -
> > - /*
> > - * Map all the possible incoming states to the only two we
> > - * really want to deal with.
> > - */
> > - switch (val & KVM_REG_FEATURE_LEVEL_MASK) {
> > - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL:
> > - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_UNKNOWN:
> > - wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> > - break;
> > - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL:
> > - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED:
> > - wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
> > - break;
> > - default:
> > - return -EINVAL;
> > - }
> > -
> > - /*
> > - * We can deal with NOT_AVAIL on NOT_REQUIRED, but not the
> > - * other way around.
> > - */
> > - if (get_kernel_wa_level(reg->id) < wa_level)
> > - return -EINVAL;
> > -
> > - return 0;
> > - default:
> > - return -ENOENT;
> > - }
> > -
> > - return -EINVAL;
> > -}
> > diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> > index 0e2509d27910..5d38628a8d04 100644
> > --- a/include/kvm/arm_hypercalls.h
> > +++ b/include/kvm/arm_hypercalls.h
> > @@ -40,4 +40,11 @@ static inline void smccc_set_retval(struct kvm_vcpu *vcpu,
> > vcpu_set_reg(vcpu, 3, a3);
> > }
> >
> > +struct kvm_one_reg;
> > +
> > +int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
> > +int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
> > +int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> > +int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> > +
> > #endif
> > diff --git a/include/kvm/arm_psci.h b/include/kvm/arm_psci.h
> > index 5b58bd2fe088..080c2d0bd6e7 100644
> > --- a/include/kvm/arm_psci.h
> > +++ b/include/kvm/arm_psci.h
> > @@ -42,11 +42,4 @@ static inline int kvm_psci_version(struct kvm_vcpu *vcpu, struct kvm *kvm)
> >
> > int kvm_psci_call(struct kvm_vcpu *vcpu);
> >
> > -struct kvm_one_reg;
> > -
> > -int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
> > -int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
> > -int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> > -int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> > -
> > #endif /* __KVM_ARM_PSCI_H__ */
> > --
> > 2.35.1.473.g83b2b277ed-goog
> >
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 01/13] KVM: arm64: Factor out firmware register handling from psci.c
@ 2022-03-14 23:15 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-03-14 23:15 UTC (permalink / raw)
To: Oliver Upton
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Mon, Mar 14, 2022 at 11:15 AM Oliver Upton <oupton@google.com> wrote:
>
> Hi Raghu,
>
> On Thu, Feb 24, 2022 at 05:25:47PM +0000, Raghavendra Rao Ananta wrote:
> > Common hypercall firmware register handing is currently employed
> > by psci.c. Since the upcoming patches add more of these registers,
> > it's better to move the generic handling to hypercall.c for a
> > cleaner presentation.
> >
> > While we are at it, collect all the firmware registers under
> > fw_reg_ids[] to help implement kvm_arm_get_fw_num_regs() and
> > kvm_arm_copy_fw_reg_indices() in a generic way.
> >
> > No functional change intended.
> >
> > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
>
> You might owe a rebase, thanks to the new Spectre bits KVM picked up (in
> Linus' tree) and PSCIv1.1 (kvmarm/next) :-)
>
> Besides the nits:
>
> Reviewed-by: Oliver Upton <oupton@google.com>
>
> > ---
> > arch/arm64/kvm/guest.c | 2 +-
> > arch/arm64/kvm/hypercalls.c | 170 +++++++++++++++++++++++++++++++++++
> > arch/arm64/kvm/psci.c | 166 ----------------------------------
> > include/kvm/arm_hypercalls.h | 7 ++
> > include/kvm/arm_psci.h | 7 --
> > 5 files changed, 178 insertions(+), 174 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> > index e116c7767730..8238e52d890d 100644
> > --- a/arch/arm64/kvm/guest.c
> > +++ b/arch/arm64/kvm/guest.c
> > @@ -18,7 +18,7 @@
> > #include <linux/string.h>
> > #include <linux/vmalloc.h>
> > #include <linux/fs.h>
> > -#include <kvm/arm_psci.h>
> > +#include <kvm/arm_hypercalls.h>
> > #include <asm/cputype.h>
> > #include <linux/uaccess.h>
> > #include <asm/fpsimd.h>
> > diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> > index 30da78f72b3b..3c2fcf31ad3d 100644
> > --- a/arch/arm64/kvm/hypercalls.c
> > +++ b/arch/arm64/kvm/hypercalls.c
> > @@ -146,3 +146,173 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > smccc_set_retval(vcpu, val[0], val[1], val[2], val[3]);
> > return 1;
> > }
> > +
> > +static const u64 kvm_arm_fw_reg_ids[] = {
> > + KVM_REG_ARM_PSCI_VERSION,
> > + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> > + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > +};
> > +
> > +int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> > +{
> > + return ARRAY_SIZE(kvm_arm_fw_reg_ids);
> > +}
> > +
> > +int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < ARRAY_SIZE(kvm_arm_fw_reg_ids); i++) {
> > + if (put_user(kvm_arm_fw_reg_ids[i], uindices++))
> > + return -EFAULT;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +#define KVM_REG_FEATURE_LEVEL_WIDTH 4
> > +#define KVM_REG_FEATURE_LEVEL_MASK (BIT(KVM_REG_FEATURE_LEVEL_WIDTH) - 1)
>
> Hrm... Not your code but this should really use GENMASK() to be
> consistent with the rest of the kernel. Also, looks like _WIDTH is
> useless.
>
> Perhaps fold these together:
>
> #define KVM_REG_FEATURE_LEVEL_MASK GENMASK(3, 0)
>
> Also these kind of macros probably belong in headers.
>
Thanks for the suggestion. I'll definitely rebase and will try to
clean these up as well.
Regards,
Raghavendra
> > +
> > +/*
> > + * Convert the workaround level into an easy-to-compare number, where higher
> > + * values mean better protection.
> > + */
> > +static int get_kernel_wa_level(u64 regid)
> > +{
> > + switch (regid) {
> > + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> > + switch (arm64_get_spectre_v2_state()) {
> > + case SPECTRE_VULNERABLE:
> > + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
> > + case SPECTRE_MITIGATED:
> > + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_AVAIL;
> > + case SPECTRE_UNAFFECTED:
> > + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_REQUIRED;
> > + }
> > + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
> > + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> > + switch (arm64_get_spectre_v4_state()) {
> > + case SPECTRE_MITIGATED:
> > + /*
> > + * As for the hypercall discovery, we pretend we
> > + * don't have any FW mitigation if SSBS is there at
> > + * all times.
> > + */
> > + if (cpus_have_final_cap(ARM64_SSBS))
> > + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> > + fallthrough;
> > + case SPECTRE_UNAFFECTED:
> > + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
> > + case SPECTRE_VULNERABLE:
> > + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> > + }
> > + }
> > +
> > + return -EINVAL;
> > +}
> > +
> > +int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > +{
> > + void __user *uaddr = (void __user *)(long)reg->addr;
> > + u64 val;
> > +
> > + switch (reg->id) {
> > + case KVM_REG_ARM_PSCI_VERSION:
> > + val = kvm_psci_version(vcpu, vcpu->kvm);
> > + break;
> > + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> > + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> > + val = get_kernel_wa_level(reg->id) & KVM_REG_FEATURE_LEVEL_MASK;
> > + break;
> > + default:
> > + return -ENOENT;
> > + }
> > +
> > + if (copy_to_user(uaddr, &val, KVM_REG_SIZE(reg->id)))
> > + return -EFAULT;
> > +
> > + return 0;
> > +}
> > +
> > +int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > +{
> > + void __user *uaddr = (void __user *)(long)reg->addr;
> > + u64 val;
> > + int wa_level;
> > +
> > + if (copy_from_user(&val, uaddr, KVM_REG_SIZE(reg->id)))
> > + return -EFAULT;
> > +
> > + switch (reg->id) {
> > + case KVM_REG_ARM_PSCI_VERSION:
> > + {
> > + bool wants_02;
> > +
> > + wants_02 = test_bit(KVM_ARM_VCPU_PSCI_0_2, vcpu->arch.features);
> > +
> > + switch (val) {
> > + case KVM_ARM_PSCI_0_1:
> > + if (wants_02)
> > + return -EINVAL;
> > + vcpu->kvm->arch.psci_version = val;
> > + return 0;
> > + case KVM_ARM_PSCI_0_2:
> > + case KVM_ARM_PSCI_1_0:
> > + if (!wants_02)
> > + return -EINVAL;
> > + vcpu->kvm->arch.psci_version = val;
> > + return 0;
> > + }
> > + break;
> > + }
> > +
> > + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> > + if (val & ~KVM_REG_FEATURE_LEVEL_MASK)
> > + return -EINVAL;
> > +
> > + if (get_kernel_wa_level(reg->id) < val)
> > + return -EINVAL;
> > +
> > + return 0;
> > +
> > + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> > + if (val & ~(KVM_REG_FEATURE_LEVEL_MASK |
> > + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED))
> > + return -EINVAL;
> > +
> > + /* The enabled bit must not be set unless the level is AVAIL. */
> > + if ((val & KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED) &&
> > + (val & KVM_REG_FEATURE_LEVEL_MASK) != KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL)
> > + return -EINVAL;
> > +
> > + /*
> > + * Map all the possible incoming states to the only two we
> > + * really want to deal with.
> > + */
> > + switch (val & KVM_REG_FEATURE_LEVEL_MASK) {
> > + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL:
> > + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_UNKNOWN:
> > + wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> > + break;
> > + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL:
> > + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED:
> > + wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
> > + break;
> > + default:
> > + return -EINVAL;
> > + }
> > +
> > + /*
> > + * We can deal with NOT_AVAIL on NOT_REQUIRED, but not the
> > + * other way around.
> > + */
> > + if (get_kernel_wa_level(reg->id) < wa_level)
> > + return -EINVAL;
> > +
> > + return 0;
> > + default:
> > + return -ENOENT;
> > + }
> > +
> > + return -EINVAL;
> > +}
> > diff --git a/arch/arm64/kvm/psci.c b/arch/arm64/kvm/psci.c
> > index 3eae32876897..d5bc663a8629 100644
> > --- a/arch/arm64/kvm/psci.c
> > +++ b/arch/arm64/kvm/psci.c
> > @@ -403,169 +403,3 @@ int kvm_psci_call(struct kvm_vcpu *vcpu)
> > return -EINVAL;
> > };
> > }
> > -
> > -int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> > -{
> > - return 3; /* PSCI version and two workaround registers */
> > -}
> > -
> > -int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
> > -{
> > - if (put_user(KVM_REG_ARM_PSCI_VERSION, uindices++))
> > - return -EFAULT;
> > -
> > - if (put_user(KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1, uindices++))
> > - return -EFAULT;
> > -
> > - if (put_user(KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2, uindices++))
> > - return -EFAULT;
> > -
> > - return 0;
> > -}
> > -
> > -#define KVM_REG_FEATURE_LEVEL_WIDTH 4
> > -#define KVM_REG_FEATURE_LEVEL_MASK (BIT(KVM_REG_FEATURE_LEVEL_WIDTH) - 1)
> > -
> > -/*
> > - * Convert the workaround level into an easy-to-compare number, where higher
> > - * values mean better protection.
> > - */
> > -static int get_kernel_wa_level(u64 regid)
> > -{
> > - switch (regid) {
> > - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> > - switch (arm64_get_spectre_v2_state()) {
> > - case SPECTRE_VULNERABLE:
> > - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
> > - case SPECTRE_MITIGATED:
> > - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_AVAIL;
> > - case SPECTRE_UNAFFECTED:
> > - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_REQUIRED;
> > - }
> > - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
> > - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> > - switch (arm64_get_spectre_v4_state()) {
> > - case SPECTRE_MITIGATED:
> > - /*
> > - * As for the hypercall discovery, we pretend we
> > - * don't have any FW mitigation if SSBS is there at
> > - * all times.
> > - */
> > - if (cpus_have_final_cap(ARM64_SSBS))
> > - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> > - fallthrough;
> > - case SPECTRE_UNAFFECTED:
> > - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
> > - case SPECTRE_VULNERABLE:
> > - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> > - }
> > - }
> > -
> > - return -EINVAL;
> > -}
> > -
> > -int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > -{
> > - void __user *uaddr = (void __user *)(long)reg->addr;
> > - u64 val;
> > -
> > - switch (reg->id) {
> > - case KVM_REG_ARM_PSCI_VERSION:
> > - val = kvm_psci_version(vcpu, vcpu->kvm);
> > - break;
> > - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> > - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> > - val = get_kernel_wa_level(reg->id) & KVM_REG_FEATURE_LEVEL_MASK;
> > - break;
> > - default:
> > - return -ENOENT;
> > - }
> > -
> > - if (copy_to_user(uaddr, &val, KVM_REG_SIZE(reg->id)))
> > - return -EFAULT;
> > -
> > - return 0;
> > -}
> > -
> > -int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > -{
> > - void __user *uaddr = (void __user *)(long)reg->addr;
> > - u64 val;
> > - int wa_level;
> > -
> > - if (copy_from_user(&val, uaddr, KVM_REG_SIZE(reg->id)))
> > - return -EFAULT;
> > -
> > - switch (reg->id) {
> > - case KVM_REG_ARM_PSCI_VERSION:
> > - {
> > - bool wants_02;
> > -
> > - wants_02 = test_bit(KVM_ARM_VCPU_PSCI_0_2, vcpu->arch.features);
> > -
> > - switch (val) {
> > - case KVM_ARM_PSCI_0_1:
> > - if (wants_02)
> > - return -EINVAL;
> > - vcpu->kvm->arch.psci_version = val;
> > - return 0;
> > - case KVM_ARM_PSCI_0_2:
> > - case KVM_ARM_PSCI_1_0:
> > - if (!wants_02)
> > - return -EINVAL;
> > - vcpu->kvm->arch.psci_version = val;
> > - return 0;
> > - }
> > - break;
> > - }
> > -
> > - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> > - if (val & ~KVM_REG_FEATURE_LEVEL_MASK)
> > - return -EINVAL;
> > -
> > - if (get_kernel_wa_level(reg->id) < val)
> > - return -EINVAL;
> > -
> > - return 0;
> > -
> > - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> > - if (val & ~(KVM_REG_FEATURE_LEVEL_MASK |
> > - KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED))
> > - return -EINVAL;
> > -
> > - /* The enabled bit must not be set unless the level is AVAIL. */
> > - if ((val & KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED) &&
> > - (val & KVM_REG_FEATURE_LEVEL_MASK) != KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL)
> > - return -EINVAL;
> > -
> > - /*
> > - * Map all the possible incoming states to the only two we
> > - * really want to deal with.
> > - */
> > - switch (val & KVM_REG_FEATURE_LEVEL_MASK) {
> > - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL:
> > - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_UNKNOWN:
> > - wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> > - break;
> > - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL:
> > - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED:
> > - wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
> > - break;
> > - default:
> > - return -EINVAL;
> > - }
> > -
> > - /*
> > - * We can deal with NOT_AVAIL on NOT_REQUIRED, but not the
> > - * other way around.
> > - */
> > - if (get_kernel_wa_level(reg->id) < wa_level)
> > - return -EINVAL;
> > -
> > - return 0;
> > - default:
> > - return -ENOENT;
> > - }
> > -
> > - return -EINVAL;
> > -}
> > diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> > index 0e2509d27910..5d38628a8d04 100644
> > --- a/include/kvm/arm_hypercalls.h
> > +++ b/include/kvm/arm_hypercalls.h
> > @@ -40,4 +40,11 @@ static inline void smccc_set_retval(struct kvm_vcpu *vcpu,
> > vcpu_set_reg(vcpu, 3, a3);
> > }
> >
> > +struct kvm_one_reg;
> > +
> > +int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
> > +int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
> > +int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> > +int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> > +
> > #endif
> > diff --git a/include/kvm/arm_psci.h b/include/kvm/arm_psci.h
> > index 5b58bd2fe088..080c2d0bd6e7 100644
> > --- a/include/kvm/arm_psci.h
> > +++ b/include/kvm/arm_psci.h
> > @@ -42,11 +42,4 @@ static inline int kvm_psci_version(struct kvm_vcpu *vcpu, struct kvm *kvm)
> >
> > int kvm_psci_call(struct kvm_vcpu *vcpu);
> >
> > -struct kvm_one_reg;
> > -
> > -int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
> > -int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
> > -int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> > -int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> > -
> > #endif /* __KVM_ARM_PSCI_H__ */
> > --
> > 2.35.1.473.g83b2b277ed-goog
> >
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 01/13] KVM: arm64: Factor out firmware register handling from psci.c
@ 2022-03-14 23:15 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-03-14 23:15 UTC (permalink / raw)
To: Oliver Upton
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Mon, Mar 14, 2022 at 11:15 AM Oliver Upton <oupton@google.com> wrote:
>
> Hi Raghu,
>
> On Thu, Feb 24, 2022 at 05:25:47PM +0000, Raghavendra Rao Ananta wrote:
> > Common hypercall firmware register handing is currently employed
> > by psci.c. Since the upcoming patches add more of these registers,
> > it's better to move the generic handling to hypercall.c for a
> > cleaner presentation.
> >
> > While we are at it, collect all the firmware registers under
> > fw_reg_ids[] to help implement kvm_arm_get_fw_num_regs() and
> > kvm_arm_copy_fw_reg_indices() in a generic way.
> >
> > No functional change intended.
> >
> > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
>
> You might owe a rebase, thanks to the new Spectre bits KVM picked up (in
> Linus' tree) and PSCIv1.1 (kvmarm/next) :-)
>
> Besides the nits:
>
> Reviewed-by: Oliver Upton <oupton@google.com>
>
> > ---
> > arch/arm64/kvm/guest.c | 2 +-
> > arch/arm64/kvm/hypercalls.c | 170 +++++++++++++++++++++++++++++++++++
> > arch/arm64/kvm/psci.c | 166 ----------------------------------
> > include/kvm/arm_hypercalls.h | 7 ++
> > include/kvm/arm_psci.h | 7 --
> > 5 files changed, 178 insertions(+), 174 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> > index e116c7767730..8238e52d890d 100644
> > --- a/arch/arm64/kvm/guest.c
> > +++ b/arch/arm64/kvm/guest.c
> > @@ -18,7 +18,7 @@
> > #include <linux/string.h>
> > #include <linux/vmalloc.h>
> > #include <linux/fs.h>
> > -#include <kvm/arm_psci.h>
> > +#include <kvm/arm_hypercalls.h>
> > #include <asm/cputype.h>
> > #include <linux/uaccess.h>
> > #include <asm/fpsimd.h>
> > diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> > index 30da78f72b3b..3c2fcf31ad3d 100644
> > --- a/arch/arm64/kvm/hypercalls.c
> > +++ b/arch/arm64/kvm/hypercalls.c
> > @@ -146,3 +146,173 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > smccc_set_retval(vcpu, val[0], val[1], val[2], val[3]);
> > return 1;
> > }
> > +
> > +static const u64 kvm_arm_fw_reg_ids[] = {
> > + KVM_REG_ARM_PSCI_VERSION,
> > + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> > + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > +};
> > +
> > +int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> > +{
> > + return ARRAY_SIZE(kvm_arm_fw_reg_ids);
> > +}
> > +
> > +int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < ARRAY_SIZE(kvm_arm_fw_reg_ids); i++) {
> > + if (put_user(kvm_arm_fw_reg_ids[i], uindices++))
> > + return -EFAULT;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +#define KVM_REG_FEATURE_LEVEL_WIDTH 4
> > +#define KVM_REG_FEATURE_LEVEL_MASK (BIT(KVM_REG_FEATURE_LEVEL_WIDTH) - 1)
>
> Hrm... Not your code but this should really use GENMASK() to be
> consistent with the rest of the kernel. Also, looks like _WIDTH is
> useless.
>
> Perhaps fold these together:
>
> #define KVM_REG_FEATURE_LEVEL_MASK GENMASK(3, 0)
>
> Also these kind of macros probably belong in headers.
>
Thanks for the suggestion. I'll definitely rebase and will try to
clean these up as well.
Regards,
Raghavendra
> > +
> > +/*
> > + * Convert the workaround level into an easy-to-compare number, where higher
> > + * values mean better protection.
> > + */
> > +static int get_kernel_wa_level(u64 regid)
> > +{
> > + switch (regid) {
> > + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> > + switch (arm64_get_spectre_v2_state()) {
> > + case SPECTRE_VULNERABLE:
> > + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
> > + case SPECTRE_MITIGATED:
> > + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_AVAIL;
> > + case SPECTRE_UNAFFECTED:
> > + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_REQUIRED;
> > + }
> > + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
> > + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> > + switch (arm64_get_spectre_v4_state()) {
> > + case SPECTRE_MITIGATED:
> > + /*
> > + * As for the hypercall discovery, we pretend we
> > + * don't have any FW mitigation if SSBS is there at
> > + * all times.
> > + */
> > + if (cpus_have_final_cap(ARM64_SSBS))
> > + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> > + fallthrough;
> > + case SPECTRE_UNAFFECTED:
> > + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
> > + case SPECTRE_VULNERABLE:
> > + return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> > + }
> > + }
> > +
> > + return -EINVAL;
> > +}
> > +
> > +int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > +{
> > + void __user *uaddr = (void __user *)(long)reg->addr;
> > + u64 val;
> > +
> > + switch (reg->id) {
> > + case KVM_REG_ARM_PSCI_VERSION:
> > + val = kvm_psci_version(vcpu, vcpu->kvm);
> > + break;
> > + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> > + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> > + val = get_kernel_wa_level(reg->id) & KVM_REG_FEATURE_LEVEL_MASK;
> > + break;
> > + default:
> > + return -ENOENT;
> > + }
> > +
> > + if (copy_to_user(uaddr, &val, KVM_REG_SIZE(reg->id)))
> > + return -EFAULT;
> > +
> > + return 0;
> > +}
> > +
> > +int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > +{
> > + void __user *uaddr = (void __user *)(long)reg->addr;
> > + u64 val;
> > + int wa_level;
> > +
> > + if (copy_from_user(&val, uaddr, KVM_REG_SIZE(reg->id)))
> > + return -EFAULT;
> > +
> > + switch (reg->id) {
> > + case KVM_REG_ARM_PSCI_VERSION:
> > + {
> > + bool wants_02;
> > +
> > + wants_02 = test_bit(KVM_ARM_VCPU_PSCI_0_2, vcpu->arch.features);
> > +
> > + switch (val) {
> > + case KVM_ARM_PSCI_0_1:
> > + if (wants_02)
> > + return -EINVAL;
> > + vcpu->kvm->arch.psci_version = val;
> > + return 0;
> > + case KVM_ARM_PSCI_0_2:
> > + case KVM_ARM_PSCI_1_0:
> > + if (!wants_02)
> > + return -EINVAL;
> > + vcpu->kvm->arch.psci_version = val;
> > + return 0;
> > + }
> > + break;
> > + }
> > +
> > + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> > + if (val & ~KVM_REG_FEATURE_LEVEL_MASK)
> > + return -EINVAL;
> > +
> > + if (get_kernel_wa_level(reg->id) < val)
> > + return -EINVAL;
> > +
> > + return 0;
> > +
> > + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> > + if (val & ~(KVM_REG_FEATURE_LEVEL_MASK |
> > + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED))
> > + return -EINVAL;
> > +
> > + /* The enabled bit must not be set unless the level is AVAIL. */
> > + if ((val & KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED) &&
> > + (val & KVM_REG_FEATURE_LEVEL_MASK) != KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL)
> > + return -EINVAL;
> > +
> > + /*
> > + * Map all the possible incoming states to the only two we
> > + * really want to deal with.
> > + */
> > + switch (val & KVM_REG_FEATURE_LEVEL_MASK) {
> > + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL:
> > + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_UNKNOWN:
> > + wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> > + break;
> > + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL:
> > + case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED:
> > + wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
> > + break;
> > + default:
> > + return -EINVAL;
> > + }
> > +
> > + /*
> > + * We can deal with NOT_AVAIL on NOT_REQUIRED, but not the
> > + * other way around.
> > + */
> > + if (get_kernel_wa_level(reg->id) < wa_level)
> > + return -EINVAL;
> > +
> > + return 0;
> > + default:
> > + return -ENOENT;
> > + }
> > +
> > + return -EINVAL;
> > +}
> > diff --git a/arch/arm64/kvm/psci.c b/arch/arm64/kvm/psci.c
> > index 3eae32876897..d5bc663a8629 100644
> > --- a/arch/arm64/kvm/psci.c
> > +++ b/arch/arm64/kvm/psci.c
> > @@ -403,169 +403,3 @@ int kvm_psci_call(struct kvm_vcpu *vcpu)
> > return -EINVAL;
> > };
> > }
> > -
> > -int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> > -{
> > - return 3; /* PSCI version and two workaround registers */
> > -}
> > -
> > -int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
> > -{
> > - if (put_user(KVM_REG_ARM_PSCI_VERSION, uindices++))
> > - return -EFAULT;
> > -
> > - if (put_user(KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1, uindices++))
> > - return -EFAULT;
> > -
> > - if (put_user(KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2, uindices++))
> > - return -EFAULT;
> > -
> > - return 0;
> > -}
> > -
> > -#define KVM_REG_FEATURE_LEVEL_WIDTH 4
> > -#define KVM_REG_FEATURE_LEVEL_MASK (BIT(KVM_REG_FEATURE_LEVEL_WIDTH) - 1)
> > -
> > -/*
> > - * Convert the workaround level into an easy-to-compare number, where higher
> > - * values mean better protection.
> > - */
> > -static int get_kernel_wa_level(u64 regid)
> > -{
> > - switch (regid) {
> > - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> > - switch (arm64_get_spectre_v2_state()) {
> > - case SPECTRE_VULNERABLE:
> > - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
> > - case SPECTRE_MITIGATED:
> > - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_AVAIL;
> > - case SPECTRE_UNAFFECTED:
> > - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_REQUIRED;
> > - }
> > - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
> > - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> > - switch (arm64_get_spectre_v4_state()) {
> > - case SPECTRE_MITIGATED:
> > - /*
> > - * As for the hypercall discovery, we pretend we
> > - * don't have any FW mitigation if SSBS is there at
> > - * all times.
> > - */
> > - if (cpus_have_final_cap(ARM64_SSBS))
> > - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> > - fallthrough;
> > - case SPECTRE_UNAFFECTED:
> > - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
> > - case SPECTRE_VULNERABLE:
> > - return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> > - }
> > - }
> > -
> > - return -EINVAL;
> > -}
> > -
> > -int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > -{
> > - void __user *uaddr = (void __user *)(long)reg->addr;
> > - u64 val;
> > -
> > - switch (reg->id) {
> > - case KVM_REG_ARM_PSCI_VERSION:
> > - val = kvm_psci_version(vcpu, vcpu->kvm);
> > - break;
> > - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> > - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> > - val = get_kernel_wa_level(reg->id) & KVM_REG_FEATURE_LEVEL_MASK;
> > - break;
> > - default:
> > - return -ENOENT;
> > - }
> > -
> > - if (copy_to_user(uaddr, &val, KVM_REG_SIZE(reg->id)))
> > - return -EFAULT;
> > -
> > - return 0;
> > -}
> > -
> > -int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > -{
> > - void __user *uaddr = (void __user *)(long)reg->addr;
> > - u64 val;
> > - int wa_level;
> > -
> > - if (copy_from_user(&val, uaddr, KVM_REG_SIZE(reg->id)))
> > - return -EFAULT;
> > -
> > - switch (reg->id) {
> > - case KVM_REG_ARM_PSCI_VERSION:
> > - {
> > - bool wants_02;
> > -
> > - wants_02 = test_bit(KVM_ARM_VCPU_PSCI_0_2, vcpu->arch.features);
> > -
> > - switch (val) {
> > - case KVM_ARM_PSCI_0_1:
> > - if (wants_02)
> > - return -EINVAL;
> > - vcpu->kvm->arch.psci_version = val;
> > - return 0;
> > - case KVM_ARM_PSCI_0_2:
> > - case KVM_ARM_PSCI_1_0:
> > - if (!wants_02)
> > - return -EINVAL;
> > - vcpu->kvm->arch.psci_version = val;
> > - return 0;
> > - }
> > - break;
> > - }
> > -
> > - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> > - if (val & ~KVM_REG_FEATURE_LEVEL_MASK)
> > - return -EINVAL;
> > -
> > - if (get_kernel_wa_level(reg->id) < val)
> > - return -EINVAL;
> > -
> > - return 0;
> > -
> > - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> > - if (val & ~(KVM_REG_FEATURE_LEVEL_MASK |
> > - KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED))
> > - return -EINVAL;
> > -
> > - /* The enabled bit must not be set unless the level is AVAIL. */
> > - if ((val & KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED) &&
> > - (val & KVM_REG_FEATURE_LEVEL_MASK) != KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL)
> > - return -EINVAL;
> > -
> > - /*
> > - * Map all the possible incoming states to the only two we
> > - * really want to deal with.
> > - */
> > - switch (val & KVM_REG_FEATURE_LEVEL_MASK) {
> > - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL:
> > - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_UNKNOWN:
> > - wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
> > - break;
> > - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL:
> > - case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED:
> > - wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
> > - break;
> > - default:
> > - return -EINVAL;
> > - }
> > -
> > - /*
> > - * We can deal with NOT_AVAIL on NOT_REQUIRED, but not the
> > - * other way around.
> > - */
> > - if (get_kernel_wa_level(reg->id) < wa_level)
> > - return -EINVAL;
> > -
> > - return 0;
> > - default:
> > - return -ENOENT;
> > - }
> > -
> > - return -EINVAL;
> > -}
> > diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> > index 0e2509d27910..5d38628a8d04 100644
> > --- a/include/kvm/arm_hypercalls.h
> > +++ b/include/kvm/arm_hypercalls.h
> > @@ -40,4 +40,11 @@ static inline void smccc_set_retval(struct kvm_vcpu *vcpu,
> > vcpu_set_reg(vcpu, 3, a3);
> > }
> >
> > +struct kvm_one_reg;
> > +
> > +int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
> > +int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
> > +int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> > +int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> > +
> > #endif
> > diff --git a/include/kvm/arm_psci.h b/include/kvm/arm_psci.h
> > index 5b58bd2fe088..080c2d0bd6e7 100644
> > --- a/include/kvm/arm_psci.h
> > +++ b/include/kvm/arm_psci.h
> > @@ -42,11 +42,4 @@ static inline int kvm_psci_version(struct kvm_vcpu *vcpu, struct kvm *kvm)
> >
> > int kvm_psci_call(struct kvm_vcpu *vcpu);
> >
> > -struct kvm_one_reg;
> > -
> > -int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
> > -int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
> > -int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> > -int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> > -
> > #endif /* __KVM_ARM_PSCI_H__ */
> > --
> > 2.35.1.473.g83b2b277ed-goog
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 117+ messages in thread
* [PATCH v4 02/13] KVM: arm64: Introduce KVM_CAP_ARM_REG_SCOPE
2022-02-24 17:25 ` Raghavendra Rao Ananta
(?)
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
-1 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: kvm, Catalin Marinas, Peter Shier, linux-kernel, Paolo Bonzini,
Will Deacon, kvmarm, linux-arm-kernel
KVM_[GET|SET]_ONE_REG act on per-vCPU basis. Currently certain
ARM64 registers, such as KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_[1|2],
are accessed via this interface even though the effect that
they have are really per-VM. As a result, userspace could just
waste cycles to read/write the same information for every vCPU
that it spawns, only to realize that there's absolutely no change
in the VM's state. The problem gets worse in proportion to the
number of vCPUs created.
As a result, to avoid this redundancy, introduce the capability
KVM_CAP_ARM_REG_SCOPE. If enabled, KVM_GET_REG_LIST will advertise
the registers that are VM-scoped by dynamically modifying the
register encoding. KVM_REG_ARM_SCOPE_* helper macros are introduced
to decode the same. By learning this, userspace can access such
registers only once.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
Documentation/virt/kvm/api.rst | 16 ++++++++++++++++
arch/arm64/include/asm/kvm_host.h | 3 +++
arch/arm64/include/uapi/asm/kvm.h | 6 ++++++
arch/arm64/kvm/arm.c | 13 +++++++------
include/uapi/linux/kvm.h | 1 +
5 files changed, 33 insertions(+), 6 deletions(-)
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index a4267104db50..7e7b3439f540 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -7561,3 +7561,19 @@ The argument to KVM_ENABLE_CAP is also a bitmask, and must be a subset
of the result of KVM_CHECK_EXTENSION. KVM will forward to userspace
the hypercalls whose corresponding bit is in the argument, and return
ENOSYS for the others.
+
+8.34 KVM_CAP_ARM_REG_SCOPE
+--------------------------
+
+:Architectures: arm64
+
+The capability, if enabled, amends the existing register encoding
+with additional information to the userspace if a particular register
+is scoped per-vCPU or per-VM via KVM_GET_REG_LIST. KVM provides
+KVM_REG_ARM_SCOPE_* helper macros to decode the same. Userspace can
+use this information from the register encoding to access a VM-scopped
+regiser only once, as opposed to accessing it for every vCPU for the
+same effect.
+
+On the other hand, if the capability is disabled, all the registers
+remain vCPU-scopped by default, retaining backward compatibility.
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 5bc01e62c08a..8132de6bd718 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -136,6 +136,9 @@ struct kvm_arch {
/* Memory Tagging Extension enabled for the guest */
bool mte_enabled;
+
+ /* Register scoping enabled for KVM registers */
+ bool reg_scope_enabled;
};
struct kvm_vcpu_fault_info {
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index b3edde68bc3e..c35447cc0e0c 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -199,6 +199,12 @@ struct kvm_arm_copy_mte_tags {
#define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000
#define KVM_REG_ARM_COPROC_SHIFT 16
+/* Defines if a KVM register is one per-vCPU or one per-VM */
+#define KVM_REG_ARM_SCOPE_MASK 0x0000000010000000
+#define KVM_REG_ARM_SCOPE_SHIFT 28
+#define KVM_REG_ARM_SCOPE_VCPU 0
+#define KVM_REG_ARM_SCOPE_VM 1
+
/* Normal registers are mapped as coprocessor 16. */
#define KVM_REG_ARM_CORE (0x0010 << KVM_REG_ARM_COPROC_SHIFT)
#define KVM_REG_ARM_CORE_REG(name) (offsetof(struct kvm_regs, name) / sizeof(__u32))
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index ecc5958e27fe..107977c82c6c 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -81,26 +81,26 @@ int kvm_arch_check_processor_compat(void *opaque)
int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
struct kvm_enable_cap *cap)
{
- int r;
+ int r = 0;
if (cap->flags)
return -EINVAL;
switch (cap->cap) {
case KVM_CAP_ARM_NISV_TO_USER:
- r = 0;
kvm->arch.return_nisv_io_abort_to_user = true;
break;
case KVM_CAP_ARM_MTE:
mutex_lock(&kvm->lock);
- if (!system_supports_mte() || kvm->created_vcpus) {
+ if (!system_supports_mte() || kvm->created_vcpus)
r = -EINVAL;
- } else {
- r = 0;
+ else
kvm->arch.mte_enabled = true;
- }
mutex_unlock(&kvm->lock);
break;
+ case KVM_CAP_ARM_REG_SCOPE:
+ WRITE_ONCE(kvm->arch.reg_scope_enabled, true);
+ break;
default:
r = -EINVAL;
break;
@@ -209,6 +209,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
case KVM_CAP_SET_GUEST_DEBUG:
case KVM_CAP_VCPU_ATTRIBUTES:
case KVM_CAP_PTP_KVM:
+ case KVM_CAP_ARM_REG_SCOPE:
r = 1;
break;
case KVM_CAP_SET_GUEST_DEBUG2:
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 5191b57e1562..c4fe81ed9ee6 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1134,6 +1134,7 @@ struct kvm_ppc_resize_hpt {
#define KVM_CAP_VM_GPA_BITS 207
#define KVM_CAP_XSAVE2 208
#define KVM_CAP_SYS_ATTRIBUTES 209
+#define KVM_CAP_ARM_REG_SCOPE 210
#ifdef KVM_CAP_IRQ_ROUTING
--
2.35.1.473.g83b2b277ed-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 117+ messages in thread* [PATCH v4 02/13] KVM: arm64: Introduce KVM_CAP_ARM_REG_SCOPE
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: Paolo Bonzini, Catalin Marinas, Will Deacon, Peter Shier,
Ricardo Koller, Oliver Upton, Reiji Watanabe, Jing Zhang,
Raghavendra Rao Anata, linux-arm-kernel, kvmarm, linux-kernel,
kvm
KVM_[GET|SET]_ONE_REG act on per-vCPU basis. Currently certain
ARM64 registers, such as KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_[1|2],
are accessed via this interface even though the effect that
they have are really per-VM. As a result, userspace could just
waste cycles to read/write the same information for every vCPU
that it spawns, only to realize that there's absolutely no change
in the VM's state. The problem gets worse in proportion to the
number of vCPUs created.
As a result, to avoid this redundancy, introduce the capability
KVM_CAP_ARM_REG_SCOPE. If enabled, KVM_GET_REG_LIST will advertise
the registers that are VM-scoped by dynamically modifying the
register encoding. KVM_REG_ARM_SCOPE_* helper macros are introduced
to decode the same. By learning this, userspace can access such
registers only once.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
Documentation/virt/kvm/api.rst | 16 ++++++++++++++++
arch/arm64/include/asm/kvm_host.h | 3 +++
arch/arm64/include/uapi/asm/kvm.h | 6 ++++++
arch/arm64/kvm/arm.c | 13 +++++++------
include/uapi/linux/kvm.h | 1 +
5 files changed, 33 insertions(+), 6 deletions(-)
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index a4267104db50..7e7b3439f540 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -7561,3 +7561,19 @@ The argument to KVM_ENABLE_CAP is also a bitmask, and must be a subset
of the result of KVM_CHECK_EXTENSION. KVM will forward to userspace
the hypercalls whose corresponding bit is in the argument, and return
ENOSYS for the others.
+
+8.34 KVM_CAP_ARM_REG_SCOPE
+--------------------------
+
+:Architectures: arm64
+
+The capability, if enabled, amends the existing register encoding
+with additional information to the userspace if a particular register
+is scoped per-vCPU or per-VM via KVM_GET_REG_LIST. KVM provides
+KVM_REG_ARM_SCOPE_* helper macros to decode the same. Userspace can
+use this information from the register encoding to access a VM-scopped
+regiser only once, as opposed to accessing it for every vCPU for the
+same effect.
+
+On the other hand, if the capability is disabled, all the registers
+remain vCPU-scopped by default, retaining backward compatibility.
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 5bc01e62c08a..8132de6bd718 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -136,6 +136,9 @@ struct kvm_arch {
/* Memory Tagging Extension enabled for the guest */
bool mte_enabled;
+
+ /* Register scoping enabled for KVM registers */
+ bool reg_scope_enabled;
};
struct kvm_vcpu_fault_info {
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index b3edde68bc3e..c35447cc0e0c 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -199,6 +199,12 @@ struct kvm_arm_copy_mte_tags {
#define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000
#define KVM_REG_ARM_COPROC_SHIFT 16
+/* Defines if a KVM register is one per-vCPU or one per-VM */
+#define KVM_REG_ARM_SCOPE_MASK 0x0000000010000000
+#define KVM_REG_ARM_SCOPE_SHIFT 28
+#define KVM_REG_ARM_SCOPE_VCPU 0
+#define KVM_REG_ARM_SCOPE_VM 1
+
/* Normal registers are mapped as coprocessor 16. */
#define KVM_REG_ARM_CORE (0x0010 << KVM_REG_ARM_COPROC_SHIFT)
#define KVM_REG_ARM_CORE_REG(name) (offsetof(struct kvm_regs, name) / sizeof(__u32))
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index ecc5958e27fe..107977c82c6c 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -81,26 +81,26 @@ int kvm_arch_check_processor_compat(void *opaque)
int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
struct kvm_enable_cap *cap)
{
- int r;
+ int r = 0;
if (cap->flags)
return -EINVAL;
switch (cap->cap) {
case KVM_CAP_ARM_NISV_TO_USER:
- r = 0;
kvm->arch.return_nisv_io_abort_to_user = true;
break;
case KVM_CAP_ARM_MTE:
mutex_lock(&kvm->lock);
- if (!system_supports_mte() || kvm->created_vcpus) {
+ if (!system_supports_mte() || kvm->created_vcpus)
r = -EINVAL;
- } else {
- r = 0;
+ else
kvm->arch.mte_enabled = true;
- }
mutex_unlock(&kvm->lock);
break;
+ case KVM_CAP_ARM_REG_SCOPE:
+ WRITE_ONCE(kvm->arch.reg_scope_enabled, true);
+ break;
default:
r = -EINVAL;
break;
@@ -209,6 +209,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
case KVM_CAP_SET_GUEST_DEBUG:
case KVM_CAP_VCPU_ATTRIBUTES:
case KVM_CAP_PTP_KVM:
+ case KVM_CAP_ARM_REG_SCOPE:
r = 1;
break;
case KVM_CAP_SET_GUEST_DEBUG2:
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 5191b57e1562..c4fe81ed9ee6 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1134,6 +1134,7 @@ struct kvm_ppc_resize_hpt {
#define KVM_CAP_VM_GPA_BITS 207
#define KVM_CAP_XSAVE2 208
#define KVM_CAP_SYS_ATTRIBUTES 209
+#define KVM_CAP_ARM_REG_SCOPE 210
#ifdef KVM_CAP_IRQ_ROUTING
--
2.35.1.473.g83b2b277ed-goog
^ permalink raw reply related [flat|nested] 117+ messages in thread* [PATCH v4 02/13] KVM: arm64: Introduce KVM_CAP_ARM_REG_SCOPE
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: Paolo Bonzini, Catalin Marinas, Will Deacon, Peter Shier,
Ricardo Koller, Oliver Upton, Reiji Watanabe, Jing Zhang,
Raghavendra Rao Anata, linux-arm-kernel, kvmarm, linux-kernel,
kvm
KVM_[GET|SET]_ONE_REG act on per-vCPU basis. Currently certain
ARM64 registers, such as KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_[1|2],
are accessed via this interface even though the effect that
they have are really per-VM. As a result, userspace could just
waste cycles to read/write the same information for every vCPU
that it spawns, only to realize that there's absolutely no change
in the VM's state. The problem gets worse in proportion to the
number of vCPUs created.
As a result, to avoid this redundancy, introduce the capability
KVM_CAP_ARM_REG_SCOPE. If enabled, KVM_GET_REG_LIST will advertise
the registers that are VM-scoped by dynamically modifying the
register encoding. KVM_REG_ARM_SCOPE_* helper macros are introduced
to decode the same. By learning this, userspace can access such
registers only once.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
Documentation/virt/kvm/api.rst | 16 ++++++++++++++++
arch/arm64/include/asm/kvm_host.h | 3 +++
arch/arm64/include/uapi/asm/kvm.h | 6 ++++++
arch/arm64/kvm/arm.c | 13 +++++++------
include/uapi/linux/kvm.h | 1 +
5 files changed, 33 insertions(+), 6 deletions(-)
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index a4267104db50..7e7b3439f540 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -7561,3 +7561,19 @@ The argument to KVM_ENABLE_CAP is also a bitmask, and must be a subset
of the result of KVM_CHECK_EXTENSION. KVM will forward to userspace
the hypercalls whose corresponding bit is in the argument, and return
ENOSYS for the others.
+
+8.34 KVM_CAP_ARM_REG_SCOPE
+--------------------------
+
+:Architectures: arm64
+
+The capability, if enabled, amends the existing register encoding
+with additional information to the userspace if a particular register
+is scoped per-vCPU or per-VM via KVM_GET_REG_LIST. KVM provides
+KVM_REG_ARM_SCOPE_* helper macros to decode the same. Userspace can
+use this information from the register encoding to access a VM-scopped
+regiser only once, as opposed to accessing it for every vCPU for the
+same effect.
+
+On the other hand, if the capability is disabled, all the registers
+remain vCPU-scopped by default, retaining backward compatibility.
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 5bc01e62c08a..8132de6bd718 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -136,6 +136,9 @@ struct kvm_arch {
/* Memory Tagging Extension enabled for the guest */
bool mte_enabled;
+
+ /* Register scoping enabled for KVM registers */
+ bool reg_scope_enabled;
};
struct kvm_vcpu_fault_info {
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index b3edde68bc3e..c35447cc0e0c 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -199,6 +199,12 @@ struct kvm_arm_copy_mte_tags {
#define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000
#define KVM_REG_ARM_COPROC_SHIFT 16
+/* Defines if a KVM register is one per-vCPU or one per-VM */
+#define KVM_REG_ARM_SCOPE_MASK 0x0000000010000000
+#define KVM_REG_ARM_SCOPE_SHIFT 28
+#define KVM_REG_ARM_SCOPE_VCPU 0
+#define KVM_REG_ARM_SCOPE_VM 1
+
/* Normal registers are mapped as coprocessor 16. */
#define KVM_REG_ARM_CORE (0x0010 << KVM_REG_ARM_COPROC_SHIFT)
#define KVM_REG_ARM_CORE_REG(name) (offsetof(struct kvm_regs, name) / sizeof(__u32))
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index ecc5958e27fe..107977c82c6c 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -81,26 +81,26 @@ int kvm_arch_check_processor_compat(void *opaque)
int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
struct kvm_enable_cap *cap)
{
- int r;
+ int r = 0;
if (cap->flags)
return -EINVAL;
switch (cap->cap) {
case KVM_CAP_ARM_NISV_TO_USER:
- r = 0;
kvm->arch.return_nisv_io_abort_to_user = true;
break;
case KVM_CAP_ARM_MTE:
mutex_lock(&kvm->lock);
- if (!system_supports_mte() || kvm->created_vcpus) {
+ if (!system_supports_mte() || kvm->created_vcpus)
r = -EINVAL;
- } else {
- r = 0;
+ else
kvm->arch.mte_enabled = true;
- }
mutex_unlock(&kvm->lock);
break;
+ case KVM_CAP_ARM_REG_SCOPE:
+ WRITE_ONCE(kvm->arch.reg_scope_enabled, true);
+ break;
default:
r = -EINVAL;
break;
@@ -209,6 +209,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
case KVM_CAP_SET_GUEST_DEBUG:
case KVM_CAP_VCPU_ATTRIBUTES:
case KVM_CAP_PTP_KVM:
+ case KVM_CAP_ARM_REG_SCOPE:
r = 1;
break;
case KVM_CAP_SET_GUEST_DEBUG2:
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 5191b57e1562..c4fe81ed9ee6 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1134,6 +1134,7 @@ struct kvm_ppc_resize_hpt {
#define KVM_CAP_VM_GPA_BITS 207
#define KVM_CAP_XSAVE2 208
#define KVM_CAP_SYS_ATTRIBUTES 209
+#define KVM_CAP_ARM_REG_SCOPE 210
#ifdef KVM_CAP_IRQ_ROUTING
--
2.35.1.473.g83b2b277ed-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 117+ messages in thread* Re: [PATCH v4 02/13] KVM: arm64: Introduce KVM_CAP_ARM_REG_SCOPE
2022-02-24 17:25 ` Raghavendra Rao Ananta
(?)
@ 2022-02-25 6:42 ` Oliver Upton
-1 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-02-25 6:42 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: kvm, Will Deacon, Marc Zyngier, Peter Shier, linux-kernel,
Catalin Marinas, Paolo Bonzini, kvmarm, linux-arm-kernel
On Thu, Feb 24, 2022 at 05:25:48PM +0000, Raghavendra Rao Ananta wrote:
> KVM_[GET|SET]_ONE_REG act on per-vCPU basis. Currently certain
> ARM64 registers, such as KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_[1|2],
> are accessed via this interface even though the effect that
> they have are really per-VM. As a result, userspace could just
> waste cycles to read/write the same information for every vCPU
> that it spawns, only to realize that there's absolutely no change
> in the VM's state. The problem gets worse in proportion to the
> number of vCPUs created.
>
> As a result, to avoid this redundancy, introduce the capability
> KVM_CAP_ARM_REG_SCOPE. If enabled, KVM_GET_REG_LIST will advertise
> the registers that are VM-scoped by dynamically modifying the
> register encoding. KVM_REG_ARM_SCOPE_* helper macros are introduced
> to decode the same. By learning this, userspace can access such
> registers only once.
>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> ---
> Documentation/virt/kvm/api.rst | 16 ++++++++++++++++
> arch/arm64/include/asm/kvm_host.h | 3 +++
> arch/arm64/include/uapi/asm/kvm.h | 6 ++++++
> arch/arm64/kvm/arm.c | 13 +++++++------
> include/uapi/linux/kvm.h | 1 +
> 5 files changed, 33 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index a4267104db50..7e7b3439f540 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -7561,3 +7561,19 @@ The argument to KVM_ENABLE_CAP is also a bitmask, and must be a subset
> of the result of KVM_CHECK_EXTENSION. KVM will forward to userspace
> the hypercalls whose corresponding bit is in the argument, and return
> ENOSYS for the others.
> +
> +8.34 KVM_CAP_ARM_REG_SCOPE
> +--------------------------
> +
> +:Architectures: arm64
> +
> +The capability, if enabled, amends the existing register encoding
> +with additional information to the userspace if a particular register
> +is scoped per-vCPU or per-VM via KVM_GET_REG_LIST. KVM provides
> +KVM_REG_ARM_SCOPE_* helper macros to decode the same. Userspace can
> +use this information from the register encoding to access a VM-scopped
> +regiser only once, as opposed to accessing it for every vCPU for the
> +same effect.
> +
Could you describe the encoding changes in 4.68 'KVM_SET_ONE_REG', along
with the other ARM encoding details?
> +On the other hand, if the capability is disabled, all the registers
> +remain vCPU-scopped by default, retaining backward compatibility.
typo: vCPU-scoped
That said, I don't believe we need to document behavior if the CAP is
disabled, as the implicated ioctls should continue to work the same.
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 5bc01e62c08a..8132de6bd718 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -136,6 +136,9 @@ struct kvm_arch {
>
> /* Memory Tagging Extension enabled for the guest */
> bool mte_enabled;
> +
> + /* Register scoping enabled for KVM registers */
> + bool reg_scope_enabled;
> };
>
> struct kvm_vcpu_fault_info {
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index b3edde68bc3e..c35447cc0e0c 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -199,6 +199,12 @@ struct kvm_arm_copy_mte_tags {
> #define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000
> #define KVM_REG_ARM_COPROC_SHIFT 16
>
> +/* Defines if a KVM register is one per-vCPU or one per-VM */
> +#define KVM_REG_ARM_SCOPE_MASK 0x0000000010000000
> +#define KVM_REG_ARM_SCOPE_SHIFT 28
Thinking about the advertisement of VM- and vCPU-scoped registers, this
could be generally useful. Might it make sense to add such an encoding
to the arch-generic register definitions?
If that is the case, we may want to snap up a few more bits (a nybble)
for future expansion.
> +#define KVM_REG_ARM_SCOPE_VCPU 0
> +#define KVM_REG_ARM_SCOPE_VM 1
> +
> /* Normal registers are mapped as coprocessor 16. */
> #define KVM_REG_ARM_CORE (0x0010 << KVM_REG_ARM_COPROC_SHIFT)
> #define KVM_REG_ARM_CORE_REG(name) (offsetof(struct kvm_regs, name) / sizeof(__u32))
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index ecc5958e27fe..107977c82c6c 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -81,26 +81,26 @@ int kvm_arch_check_processor_compat(void *opaque)
> int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
> struct kvm_enable_cap *cap)
> {
> - int r;
> + int r = 0;
>
> if (cap->flags)
> return -EINVAL;
>
> switch (cap->cap) {
> case KVM_CAP_ARM_NISV_TO_USER:
> - r = 0;
> kvm->arch.return_nisv_io_abort_to_user = true;
> break;
> case KVM_CAP_ARM_MTE:
> mutex_lock(&kvm->lock);
> - if (!system_supports_mte() || kvm->created_vcpus) {
> + if (!system_supports_mte() || kvm->created_vcpus)
> r = -EINVAL;
> - } else {
> - r = 0;
> + else
> kvm->arch.mte_enabled = true;
> - }
> mutex_unlock(&kvm->lock);
> break;
Hmm.. these all look like cleanups. If you want to propose these, could
you do it in a separate patch?
> + case KVM_CAP_ARM_REG_SCOPE:
> + WRITE_ONCE(kvm->arch.reg_scope_enabled, true);
> + break;
> default:
> r = -EINVAL;
> break;
> @@ -209,6 +209,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> case KVM_CAP_SET_GUEST_DEBUG:
> case KVM_CAP_VCPU_ATTRIBUTES:
> case KVM_CAP_PTP_KVM:
> + case KVM_CAP_ARM_REG_SCOPE:
It is a bit odd to advertise a capability (and allow userspace to enable
it), despite the fact that the feature itself hasn't yet been
implemented.
Is it possible to fold the feature in to the patch that exposes it to
userspace? Otherwise, you could punt advertisement of the CAP until it
is actually implemented in kernel.
--
Oliver
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 02/13] KVM: arm64: Introduce KVM_CAP_ARM_REG_SCOPE
@ 2022-02-25 6:42 ` Oliver Upton
0 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-02-25 6:42 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Thu, Feb 24, 2022 at 05:25:48PM +0000, Raghavendra Rao Ananta wrote:
> KVM_[GET|SET]_ONE_REG act on per-vCPU basis. Currently certain
> ARM64 registers, such as KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_[1|2],
> are accessed via this interface even though the effect that
> they have are really per-VM. As a result, userspace could just
> waste cycles to read/write the same information for every vCPU
> that it spawns, only to realize that there's absolutely no change
> in the VM's state. The problem gets worse in proportion to the
> number of vCPUs created.
>
> As a result, to avoid this redundancy, introduce the capability
> KVM_CAP_ARM_REG_SCOPE. If enabled, KVM_GET_REG_LIST will advertise
> the registers that are VM-scoped by dynamically modifying the
> register encoding. KVM_REG_ARM_SCOPE_* helper macros are introduced
> to decode the same. By learning this, userspace can access such
> registers only once.
>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> ---
> Documentation/virt/kvm/api.rst | 16 ++++++++++++++++
> arch/arm64/include/asm/kvm_host.h | 3 +++
> arch/arm64/include/uapi/asm/kvm.h | 6 ++++++
> arch/arm64/kvm/arm.c | 13 +++++++------
> include/uapi/linux/kvm.h | 1 +
> 5 files changed, 33 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index a4267104db50..7e7b3439f540 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -7561,3 +7561,19 @@ The argument to KVM_ENABLE_CAP is also a bitmask, and must be a subset
> of the result of KVM_CHECK_EXTENSION. KVM will forward to userspace
> the hypercalls whose corresponding bit is in the argument, and return
> ENOSYS for the others.
> +
> +8.34 KVM_CAP_ARM_REG_SCOPE
> +--------------------------
> +
> +:Architectures: arm64
> +
> +The capability, if enabled, amends the existing register encoding
> +with additional information to the userspace if a particular register
> +is scoped per-vCPU or per-VM via KVM_GET_REG_LIST. KVM provides
> +KVM_REG_ARM_SCOPE_* helper macros to decode the same. Userspace can
> +use this information from the register encoding to access a VM-scopped
> +regiser only once, as opposed to accessing it for every vCPU for the
> +same effect.
> +
Could you describe the encoding changes in 4.68 'KVM_SET_ONE_REG', along
with the other ARM encoding details?
> +On the other hand, if the capability is disabled, all the registers
> +remain vCPU-scopped by default, retaining backward compatibility.
typo: vCPU-scoped
That said, I don't believe we need to document behavior if the CAP is
disabled, as the implicated ioctls should continue to work the same.
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 5bc01e62c08a..8132de6bd718 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -136,6 +136,9 @@ struct kvm_arch {
>
> /* Memory Tagging Extension enabled for the guest */
> bool mte_enabled;
> +
> + /* Register scoping enabled for KVM registers */
> + bool reg_scope_enabled;
> };
>
> struct kvm_vcpu_fault_info {
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index b3edde68bc3e..c35447cc0e0c 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -199,6 +199,12 @@ struct kvm_arm_copy_mte_tags {
> #define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000
> #define KVM_REG_ARM_COPROC_SHIFT 16
>
> +/* Defines if a KVM register is one per-vCPU or one per-VM */
> +#define KVM_REG_ARM_SCOPE_MASK 0x0000000010000000
> +#define KVM_REG_ARM_SCOPE_SHIFT 28
Thinking about the advertisement of VM- and vCPU-scoped registers, this
could be generally useful. Might it make sense to add such an encoding
to the arch-generic register definitions?
If that is the case, we may want to snap up a few more bits (a nybble)
for future expansion.
> +#define KVM_REG_ARM_SCOPE_VCPU 0
> +#define KVM_REG_ARM_SCOPE_VM 1
> +
> /* Normal registers are mapped as coprocessor 16. */
> #define KVM_REG_ARM_CORE (0x0010 << KVM_REG_ARM_COPROC_SHIFT)
> #define KVM_REG_ARM_CORE_REG(name) (offsetof(struct kvm_regs, name) / sizeof(__u32))
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index ecc5958e27fe..107977c82c6c 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -81,26 +81,26 @@ int kvm_arch_check_processor_compat(void *opaque)
> int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
> struct kvm_enable_cap *cap)
> {
> - int r;
> + int r = 0;
>
> if (cap->flags)
> return -EINVAL;
>
> switch (cap->cap) {
> case KVM_CAP_ARM_NISV_TO_USER:
> - r = 0;
> kvm->arch.return_nisv_io_abort_to_user = true;
> break;
> case KVM_CAP_ARM_MTE:
> mutex_lock(&kvm->lock);
> - if (!system_supports_mte() || kvm->created_vcpus) {
> + if (!system_supports_mte() || kvm->created_vcpus)
> r = -EINVAL;
> - } else {
> - r = 0;
> + else
> kvm->arch.mte_enabled = true;
> - }
> mutex_unlock(&kvm->lock);
> break;
Hmm.. these all look like cleanups. If you want to propose these, could
you do it in a separate patch?
> + case KVM_CAP_ARM_REG_SCOPE:
> + WRITE_ONCE(kvm->arch.reg_scope_enabled, true);
> + break;
> default:
> r = -EINVAL;
> break;
> @@ -209,6 +209,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> case KVM_CAP_SET_GUEST_DEBUG:
> case KVM_CAP_VCPU_ATTRIBUTES:
> case KVM_CAP_PTP_KVM:
> + case KVM_CAP_ARM_REG_SCOPE:
It is a bit odd to advertise a capability (and allow userspace to enable
it), despite the fact that the feature itself hasn't yet been
implemented.
Is it possible to fold the feature in to the patch that exposes it to
userspace? Otherwise, you could punt advertisement of the CAP until it
is actually implemented in kernel.
--
Oliver
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 02/13] KVM: arm64: Introduce KVM_CAP_ARM_REG_SCOPE
@ 2022-02-25 6:42 ` Oliver Upton
0 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-02-25 6:42 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Thu, Feb 24, 2022 at 05:25:48PM +0000, Raghavendra Rao Ananta wrote:
> KVM_[GET|SET]_ONE_REG act on per-vCPU basis. Currently certain
> ARM64 registers, such as KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_[1|2],
> are accessed via this interface even though the effect that
> they have are really per-VM. As a result, userspace could just
> waste cycles to read/write the same information for every vCPU
> that it spawns, only to realize that there's absolutely no change
> in the VM's state. The problem gets worse in proportion to the
> number of vCPUs created.
>
> As a result, to avoid this redundancy, introduce the capability
> KVM_CAP_ARM_REG_SCOPE. If enabled, KVM_GET_REG_LIST will advertise
> the registers that are VM-scoped by dynamically modifying the
> register encoding. KVM_REG_ARM_SCOPE_* helper macros are introduced
> to decode the same. By learning this, userspace can access such
> registers only once.
>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> ---
> Documentation/virt/kvm/api.rst | 16 ++++++++++++++++
> arch/arm64/include/asm/kvm_host.h | 3 +++
> arch/arm64/include/uapi/asm/kvm.h | 6 ++++++
> arch/arm64/kvm/arm.c | 13 +++++++------
> include/uapi/linux/kvm.h | 1 +
> 5 files changed, 33 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index a4267104db50..7e7b3439f540 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -7561,3 +7561,19 @@ The argument to KVM_ENABLE_CAP is also a bitmask, and must be a subset
> of the result of KVM_CHECK_EXTENSION. KVM will forward to userspace
> the hypercalls whose corresponding bit is in the argument, and return
> ENOSYS for the others.
> +
> +8.34 KVM_CAP_ARM_REG_SCOPE
> +--------------------------
> +
> +:Architectures: arm64
> +
> +The capability, if enabled, amends the existing register encoding
> +with additional information to the userspace if a particular register
> +is scoped per-vCPU or per-VM via KVM_GET_REG_LIST. KVM provides
> +KVM_REG_ARM_SCOPE_* helper macros to decode the same. Userspace can
> +use this information from the register encoding to access a VM-scopped
> +regiser only once, as opposed to accessing it for every vCPU for the
> +same effect.
> +
Could you describe the encoding changes in 4.68 'KVM_SET_ONE_REG', along
with the other ARM encoding details?
> +On the other hand, if the capability is disabled, all the registers
> +remain vCPU-scopped by default, retaining backward compatibility.
typo: vCPU-scoped
That said, I don't believe we need to document behavior if the CAP is
disabled, as the implicated ioctls should continue to work the same.
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 5bc01e62c08a..8132de6bd718 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -136,6 +136,9 @@ struct kvm_arch {
>
> /* Memory Tagging Extension enabled for the guest */
> bool mte_enabled;
> +
> + /* Register scoping enabled for KVM registers */
> + bool reg_scope_enabled;
> };
>
> struct kvm_vcpu_fault_info {
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index b3edde68bc3e..c35447cc0e0c 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -199,6 +199,12 @@ struct kvm_arm_copy_mte_tags {
> #define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000
> #define KVM_REG_ARM_COPROC_SHIFT 16
>
> +/* Defines if a KVM register is one per-vCPU or one per-VM */
> +#define KVM_REG_ARM_SCOPE_MASK 0x0000000010000000
> +#define KVM_REG_ARM_SCOPE_SHIFT 28
Thinking about the advertisement of VM- and vCPU-scoped registers, this
could be generally useful. Might it make sense to add such an encoding
to the arch-generic register definitions?
If that is the case, we may want to snap up a few more bits (a nybble)
for future expansion.
> +#define KVM_REG_ARM_SCOPE_VCPU 0
> +#define KVM_REG_ARM_SCOPE_VM 1
> +
> /* Normal registers are mapped as coprocessor 16. */
> #define KVM_REG_ARM_CORE (0x0010 << KVM_REG_ARM_COPROC_SHIFT)
> #define KVM_REG_ARM_CORE_REG(name) (offsetof(struct kvm_regs, name) / sizeof(__u32))
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index ecc5958e27fe..107977c82c6c 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -81,26 +81,26 @@ int kvm_arch_check_processor_compat(void *opaque)
> int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
> struct kvm_enable_cap *cap)
> {
> - int r;
> + int r = 0;
>
> if (cap->flags)
> return -EINVAL;
>
> switch (cap->cap) {
> case KVM_CAP_ARM_NISV_TO_USER:
> - r = 0;
> kvm->arch.return_nisv_io_abort_to_user = true;
> break;
> case KVM_CAP_ARM_MTE:
> mutex_lock(&kvm->lock);
> - if (!system_supports_mte() || kvm->created_vcpus) {
> + if (!system_supports_mte() || kvm->created_vcpus)
> r = -EINVAL;
> - } else {
> - r = 0;
> + else
> kvm->arch.mte_enabled = true;
> - }
> mutex_unlock(&kvm->lock);
> break;
Hmm.. these all look like cleanups. If you want to propose these, could
you do it in a separate patch?
> + case KVM_CAP_ARM_REG_SCOPE:
> + WRITE_ONCE(kvm->arch.reg_scope_enabled, true);
> + break;
> default:
> r = -EINVAL;
> break;
> @@ -209,6 +209,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> case KVM_CAP_SET_GUEST_DEBUG:
> case KVM_CAP_VCPU_ATTRIBUTES:
> case KVM_CAP_PTP_KVM:
> + case KVM_CAP_ARM_REG_SCOPE:
It is a bit odd to advertise a capability (and allow userspace to enable
it), despite the fact that the feature itself hasn't yet been
implemented.
Is it possible to fold the feature in to the patch that exposes it to
userspace? Otherwise, you could punt advertisement of the CAP until it
is actually implemented in kernel.
--
Oliver
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 02/13] KVM: arm64: Introduce KVM_CAP_ARM_REG_SCOPE
2022-02-25 6:42 ` Oliver Upton
(?)
@ 2022-02-25 17:34 ` Raghavendra Rao Ananta
-1 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-25 17:34 UTC (permalink / raw)
To: Oliver Upton
Cc: kvm, Will Deacon, Marc Zyngier, Peter Shier, linux-kernel,
Catalin Marinas, Paolo Bonzini, kvmarm, linux-arm-kernel
Hey Oliver,
On Thu, Feb 24, 2022 at 10:43 PM Oliver Upton <oupton@google.com> wrote:
>
> On Thu, Feb 24, 2022 at 05:25:48PM +0000, Raghavendra Rao Ananta wrote:
> > KVM_[GET|SET]_ONE_REG act on per-vCPU basis. Currently certain
> > ARM64 registers, such as KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_[1|2],
> > are accessed via this interface even though the effect that
> > they have are really per-VM. As a result, userspace could just
> > waste cycles to read/write the same information for every vCPU
> > that it spawns, only to realize that there's absolutely no change
> > in the VM's state. The problem gets worse in proportion to the
> > number of vCPUs created.
> >
> > As a result, to avoid this redundancy, introduce the capability
> > KVM_CAP_ARM_REG_SCOPE. If enabled, KVM_GET_REG_LIST will advertise
> > the registers that are VM-scoped by dynamically modifying the
> > register encoding. KVM_REG_ARM_SCOPE_* helper macros are introduced
> > to decode the same. By learning this, userspace can access such
> > registers only once.
> >
> > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > ---
> > Documentation/virt/kvm/api.rst | 16 ++++++++++++++++
> > arch/arm64/include/asm/kvm_host.h | 3 +++
> > arch/arm64/include/uapi/asm/kvm.h | 6 ++++++
> > arch/arm64/kvm/arm.c | 13 +++++++------
> > include/uapi/linux/kvm.h | 1 +
> > 5 files changed, 33 insertions(+), 6 deletions(-)
> >
> > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> > index a4267104db50..7e7b3439f540 100644
> > --- a/Documentation/virt/kvm/api.rst
> > +++ b/Documentation/virt/kvm/api.rst
> > @@ -7561,3 +7561,19 @@ The argument to KVM_ENABLE_CAP is also a bitmask, and must be a subset
> > of the result of KVM_CHECK_EXTENSION. KVM will forward to userspace
> > the hypercalls whose corresponding bit is in the argument, and return
> > ENOSYS for the others.
> > +
> > +8.34 KVM_CAP_ARM_REG_SCOPE
> > +--------------------------
> > +
> > +:Architectures: arm64
> > +
> > +The capability, if enabled, amends the existing register encoding
> > +with additional information to the userspace if a particular register
> > +is scoped per-vCPU or per-VM via KVM_GET_REG_LIST. KVM provides
> > +KVM_REG_ARM_SCOPE_* helper macros to decode the same. Userspace can
> > +use this information from the register encoding to access a VM-scopped
> > +regiser only once, as opposed to accessing it for every vCPU for the
> > +same effect.
> > +
>
> Could you describe the encoding changes in 4.68 'KVM_SET_ONE_REG', along
> with the other ARM encoding details?
>
> > +On the other hand, if the capability is disabled, all the registers
> > +remain vCPU-scopped by default, retaining backward compatibility.
>
> typo: vCPU-scoped
>
> That said, I don't believe we need to document behavior if the CAP is
> disabled, as the implicated ioctls should continue to work the same.
>
Sure, I'll address the above two Doc comments.
> > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > index 5bc01e62c08a..8132de6bd718 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -136,6 +136,9 @@ struct kvm_arch {
> >
> > /* Memory Tagging Extension enabled for the guest */
> > bool mte_enabled;
> > +
> > + /* Register scoping enabled for KVM registers */
> > + bool reg_scope_enabled;
> > };
> >
> > struct kvm_vcpu_fault_info {
> > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > index b3edde68bc3e..c35447cc0e0c 100644
> > --- a/arch/arm64/include/uapi/asm/kvm.h
> > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > @@ -199,6 +199,12 @@ struct kvm_arm_copy_mte_tags {
> > #define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000
> > #define KVM_REG_ARM_COPROC_SHIFT 16
> >
> > +/* Defines if a KVM register is one per-vCPU or one per-VM */
> > +#define KVM_REG_ARM_SCOPE_MASK 0x0000000010000000
> > +#define KVM_REG_ARM_SCOPE_SHIFT 28
>
> Thinking about the advertisement of VM- and vCPU-scoped registers, this
> could be generally useful. Might it make sense to add such an encoding
> to the arch-generic register definitions?
>
> If that is the case, we may want to snap up a few more bits (a nybble)
> for future expansion.
>
That's a great idea! But I wonder if we'll get a push-back since there
are no users of it in other arch(s) yet. Not sure if there was any
need/discussion regarding the same, but I'm happy to share a patch for
the same if you sense that there's a strong potential for the patch.
> > +#define KVM_REG_ARM_SCOPE_VCPU 0
> > +#define KVM_REG_ARM_SCOPE_VM 1
> > +
> > /* Normal registers are mapped as coprocessor 16. */
> > #define KVM_REG_ARM_CORE (0x0010 << KVM_REG_ARM_COPROC_SHIFT)
> > #define KVM_REG_ARM_CORE_REG(name) (offsetof(struct kvm_regs, name) / sizeof(__u32))
> > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > index ecc5958e27fe..107977c82c6c 100644
> > --- a/arch/arm64/kvm/arm.c
> > +++ b/arch/arm64/kvm/arm.c
> > @@ -81,26 +81,26 @@ int kvm_arch_check_processor_compat(void *opaque)
> > int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
> > struct kvm_enable_cap *cap)
> > {
> > - int r;
> > + int r = 0;
> >
> > if (cap->flags)
> > return -EINVAL;
> >
> > switch (cap->cap) {
> > case KVM_CAP_ARM_NISV_TO_USER:
> > - r = 0;
> > kvm->arch.return_nisv_io_abort_to_user = true;
> > break;
> > case KVM_CAP_ARM_MTE:
> > mutex_lock(&kvm->lock);
> > - if (!system_supports_mte() || kvm->created_vcpus) {
> > + if (!system_supports_mte() || kvm->created_vcpus)
> > r = -EINVAL;
> > - } else {
> > - r = 0;
> > + else
> > kvm->arch.mte_enabled = true;
> > - }
> > mutex_unlock(&kvm->lock);
> > break;
>
> Hmm.. these all look like cleanups. If you want to propose these, could
> you do it in a separate patch?
>
Ahh, I thought I could squeeze it in. But sure, I can separate it out.
> > + case KVM_CAP_ARM_REG_SCOPE:
> > + WRITE_ONCE(kvm->arch.reg_scope_enabled, true);
> > + break;
> > default:
> > r = -EINVAL;
> > break;
> > @@ -209,6 +209,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> > case KVM_CAP_SET_GUEST_DEBUG:
> > case KVM_CAP_VCPU_ATTRIBUTES:
> > case KVM_CAP_PTP_KVM:
> > + case KVM_CAP_ARM_REG_SCOPE:
>
> It is a bit odd to advertise a capability (and allow userspace to enable
> it), despite the fact that the feature itself hasn't yet been
> implemented.
>
> Is it possible to fold the feature in to the patch that exposes it to
> userspace? Otherwise, you could punt advertisement of the CAP until it
> is actually implemented in kernel.
>
Well, I didn't want to complicate the patch, but technically the
feature is available with this patch, including all the CAP and macro
definitions. Userspace can still decode the scope information, only
that no registers are added yet, which is done in the next patch. So,
the userspace can still remain the same between this and the next
patch.
Thank you.
Raghavendra
> --
> Oliver
>
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 02/13] KVM: arm64: Introduce KVM_CAP_ARM_REG_SCOPE
@ 2022-02-25 17:34 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-25 17:34 UTC (permalink / raw)
To: Oliver Upton
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
Hey Oliver,
On Thu, Feb 24, 2022 at 10:43 PM Oliver Upton <oupton@google.com> wrote:
>
> On Thu, Feb 24, 2022 at 05:25:48PM +0000, Raghavendra Rao Ananta wrote:
> > KVM_[GET|SET]_ONE_REG act on per-vCPU basis. Currently certain
> > ARM64 registers, such as KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_[1|2],
> > are accessed via this interface even though the effect that
> > they have are really per-VM. As a result, userspace could just
> > waste cycles to read/write the same information for every vCPU
> > that it spawns, only to realize that there's absolutely no change
> > in the VM's state. The problem gets worse in proportion to the
> > number of vCPUs created.
> >
> > As a result, to avoid this redundancy, introduce the capability
> > KVM_CAP_ARM_REG_SCOPE. If enabled, KVM_GET_REG_LIST will advertise
> > the registers that are VM-scoped by dynamically modifying the
> > register encoding. KVM_REG_ARM_SCOPE_* helper macros are introduced
> > to decode the same. By learning this, userspace can access such
> > registers only once.
> >
> > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > ---
> > Documentation/virt/kvm/api.rst | 16 ++++++++++++++++
> > arch/arm64/include/asm/kvm_host.h | 3 +++
> > arch/arm64/include/uapi/asm/kvm.h | 6 ++++++
> > arch/arm64/kvm/arm.c | 13 +++++++------
> > include/uapi/linux/kvm.h | 1 +
> > 5 files changed, 33 insertions(+), 6 deletions(-)
> >
> > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> > index a4267104db50..7e7b3439f540 100644
> > --- a/Documentation/virt/kvm/api.rst
> > +++ b/Documentation/virt/kvm/api.rst
> > @@ -7561,3 +7561,19 @@ The argument to KVM_ENABLE_CAP is also a bitmask, and must be a subset
> > of the result of KVM_CHECK_EXTENSION. KVM will forward to userspace
> > the hypercalls whose corresponding bit is in the argument, and return
> > ENOSYS for the others.
> > +
> > +8.34 KVM_CAP_ARM_REG_SCOPE
> > +--------------------------
> > +
> > +:Architectures: arm64
> > +
> > +The capability, if enabled, amends the existing register encoding
> > +with additional information to the userspace if a particular register
> > +is scoped per-vCPU or per-VM via KVM_GET_REG_LIST. KVM provides
> > +KVM_REG_ARM_SCOPE_* helper macros to decode the same. Userspace can
> > +use this information from the register encoding to access a VM-scopped
> > +regiser only once, as opposed to accessing it for every vCPU for the
> > +same effect.
> > +
>
> Could you describe the encoding changes in 4.68 'KVM_SET_ONE_REG', along
> with the other ARM encoding details?
>
> > +On the other hand, if the capability is disabled, all the registers
> > +remain vCPU-scopped by default, retaining backward compatibility.
>
> typo: vCPU-scoped
>
> That said, I don't believe we need to document behavior if the CAP is
> disabled, as the implicated ioctls should continue to work the same.
>
Sure, I'll address the above two Doc comments.
> > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > index 5bc01e62c08a..8132de6bd718 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -136,6 +136,9 @@ struct kvm_arch {
> >
> > /* Memory Tagging Extension enabled for the guest */
> > bool mte_enabled;
> > +
> > + /* Register scoping enabled for KVM registers */
> > + bool reg_scope_enabled;
> > };
> >
> > struct kvm_vcpu_fault_info {
> > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > index b3edde68bc3e..c35447cc0e0c 100644
> > --- a/arch/arm64/include/uapi/asm/kvm.h
> > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > @@ -199,6 +199,12 @@ struct kvm_arm_copy_mte_tags {
> > #define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000
> > #define KVM_REG_ARM_COPROC_SHIFT 16
> >
> > +/* Defines if a KVM register is one per-vCPU or one per-VM */
> > +#define KVM_REG_ARM_SCOPE_MASK 0x0000000010000000
> > +#define KVM_REG_ARM_SCOPE_SHIFT 28
>
> Thinking about the advertisement of VM- and vCPU-scoped registers, this
> could be generally useful. Might it make sense to add such an encoding
> to the arch-generic register definitions?
>
> If that is the case, we may want to snap up a few more bits (a nybble)
> for future expansion.
>
That's a great idea! But I wonder if we'll get a push-back since there
are no users of it in other arch(s) yet. Not sure if there was any
need/discussion regarding the same, but I'm happy to share a patch for
the same if you sense that there's a strong potential for the patch.
> > +#define KVM_REG_ARM_SCOPE_VCPU 0
> > +#define KVM_REG_ARM_SCOPE_VM 1
> > +
> > /* Normal registers are mapped as coprocessor 16. */
> > #define KVM_REG_ARM_CORE (0x0010 << KVM_REG_ARM_COPROC_SHIFT)
> > #define KVM_REG_ARM_CORE_REG(name) (offsetof(struct kvm_regs, name) / sizeof(__u32))
> > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > index ecc5958e27fe..107977c82c6c 100644
> > --- a/arch/arm64/kvm/arm.c
> > +++ b/arch/arm64/kvm/arm.c
> > @@ -81,26 +81,26 @@ int kvm_arch_check_processor_compat(void *opaque)
> > int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
> > struct kvm_enable_cap *cap)
> > {
> > - int r;
> > + int r = 0;
> >
> > if (cap->flags)
> > return -EINVAL;
> >
> > switch (cap->cap) {
> > case KVM_CAP_ARM_NISV_TO_USER:
> > - r = 0;
> > kvm->arch.return_nisv_io_abort_to_user = true;
> > break;
> > case KVM_CAP_ARM_MTE:
> > mutex_lock(&kvm->lock);
> > - if (!system_supports_mte() || kvm->created_vcpus) {
> > + if (!system_supports_mte() || kvm->created_vcpus)
> > r = -EINVAL;
> > - } else {
> > - r = 0;
> > + else
> > kvm->arch.mte_enabled = true;
> > - }
> > mutex_unlock(&kvm->lock);
> > break;
>
> Hmm.. these all look like cleanups. If you want to propose these, could
> you do it in a separate patch?
>
Ahh, I thought I could squeeze it in. But sure, I can separate it out.
> > + case KVM_CAP_ARM_REG_SCOPE:
> > + WRITE_ONCE(kvm->arch.reg_scope_enabled, true);
> > + break;
> > default:
> > r = -EINVAL;
> > break;
> > @@ -209,6 +209,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> > case KVM_CAP_SET_GUEST_DEBUG:
> > case KVM_CAP_VCPU_ATTRIBUTES:
> > case KVM_CAP_PTP_KVM:
> > + case KVM_CAP_ARM_REG_SCOPE:
>
> It is a bit odd to advertise a capability (and allow userspace to enable
> it), despite the fact that the feature itself hasn't yet been
> implemented.
>
> Is it possible to fold the feature in to the patch that exposes it to
> userspace? Otherwise, you could punt advertisement of the CAP until it
> is actually implemented in kernel.
>
Well, I didn't want to complicate the patch, but technically the
feature is available with this patch, including all the CAP and macro
definitions. Userspace can still decode the scope information, only
that no registers are added yet, which is done in the next patch. So,
the userspace can still remain the same between this and the next
patch.
Thank you.
Raghavendra
> --
> Oliver
>
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 02/13] KVM: arm64: Introduce KVM_CAP_ARM_REG_SCOPE
@ 2022-02-25 17:34 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-25 17:34 UTC (permalink / raw)
To: Oliver Upton
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
Hey Oliver,
On Thu, Feb 24, 2022 at 10:43 PM Oliver Upton <oupton@google.com> wrote:
>
> On Thu, Feb 24, 2022 at 05:25:48PM +0000, Raghavendra Rao Ananta wrote:
> > KVM_[GET|SET]_ONE_REG act on per-vCPU basis. Currently certain
> > ARM64 registers, such as KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_[1|2],
> > are accessed via this interface even though the effect that
> > they have are really per-VM. As a result, userspace could just
> > waste cycles to read/write the same information for every vCPU
> > that it spawns, only to realize that there's absolutely no change
> > in the VM's state. The problem gets worse in proportion to the
> > number of vCPUs created.
> >
> > As a result, to avoid this redundancy, introduce the capability
> > KVM_CAP_ARM_REG_SCOPE. If enabled, KVM_GET_REG_LIST will advertise
> > the registers that are VM-scoped by dynamically modifying the
> > register encoding. KVM_REG_ARM_SCOPE_* helper macros are introduced
> > to decode the same. By learning this, userspace can access such
> > registers only once.
> >
> > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > ---
> > Documentation/virt/kvm/api.rst | 16 ++++++++++++++++
> > arch/arm64/include/asm/kvm_host.h | 3 +++
> > arch/arm64/include/uapi/asm/kvm.h | 6 ++++++
> > arch/arm64/kvm/arm.c | 13 +++++++------
> > include/uapi/linux/kvm.h | 1 +
> > 5 files changed, 33 insertions(+), 6 deletions(-)
> >
> > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> > index a4267104db50..7e7b3439f540 100644
> > --- a/Documentation/virt/kvm/api.rst
> > +++ b/Documentation/virt/kvm/api.rst
> > @@ -7561,3 +7561,19 @@ The argument to KVM_ENABLE_CAP is also a bitmask, and must be a subset
> > of the result of KVM_CHECK_EXTENSION. KVM will forward to userspace
> > the hypercalls whose corresponding bit is in the argument, and return
> > ENOSYS for the others.
> > +
> > +8.34 KVM_CAP_ARM_REG_SCOPE
> > +--------------------------
> > +
> > +:Architectures: arm64
> > +
> > +The capability, if enabled, amends the existing register encoding
> > +with additional information to the userspace if a particular register
> > +is scoped per-vCPU or per-VM via KVM_GET_REG_LIST. KVM provides
> > +KVM_REG_ARM_SCOPE_* helper macros to decode the same. Userspace can
> > +use this information from the register encoding to access a VM-scopped
> > +regiser only once, as opposed to accessing it for every vCPU for the
> > +same effect.
> > +
>
> Could you describe the encoding changes in 4.68 'KVM_SET_ONE_REG', along
> with the other ARM encoding details?
>
> > +On the other hand, if the capability is disabled, all the registers
> > +remain vCPU-scopped by default, retaining backward compatibility.
>
> typo: vCPU-scoped
>
> That said, I don't believe we need to document behavior if the CAP is
> disabled, as the implicated ioctls should continue to work the same.
>
Sure, I'll address the above two Doc comments.
> > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > index 5bc01e62c08a..8132de6bd718 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -136,6 +136,9 @@ struct kvm_arch {
> >
> > /* Memory Tagging Extension enabled for the guest */
> > bool mte_enabled;
> > +
> > + /* Register scoping enabled for KVM registers */
> > + bool reg_scope_enabled;
> > };
> >
> > struct kvm_vcpu_fault_info {
> > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > index b3edde68bc3e..c35447cc0e0c 100644
> > --- a/arch/arm64/include/uapi/asm/kvm.h
> > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > @@ -199,6 +199,12 @@ struct kvm_arm_copy_mte_tags {
> > #define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000
> > #define KVM_REG_ARM_COPROC_SHIFT 16
> >
> > +/* Defines if a KVM register is one per-vCPU or one per-VM */
> > +#define KVM_REG_ARM_SCOPE_MASK 0x0000000010000000
> > +#define KVM_REG_ARM_SCOPE_SHIFT 28
>
> Thinking about the advertisement of VM- and vCPU-scoped registers, this
> could be generally useful. Might it make sense to add such an encoding
> to the arch-generic register definitions?
>
> If that is the case, we may want to snap up a few more bits (a nybble)
> for future expansion.
>
That's a great idea! But I wonder if we'll get a push-back since there
are no users of it in other arch(s) yet. Not sure if there was any
need/discussion regarding the same, but I'm happy to share a patch for
the same if you sense that there's a strong potential for the patch.
> > +#define KVM_REG_ARM_SCOPE_VCPU 0
> > +#define KVM_REG_ARM_SCOPE_VM 1
> > +
> > /* Normal registers are mapped as coprocessor 16. */
> > #define KVM_REG_ARM_CORE (0x0010 << KVM_REG_ARM_COPROC_SHIFT)
> > #define KVM_REG_ARM_CORE_REG(name) (offsetof(struct kvm_regs, name) / sizeof(__u32))
> > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > index ecc5958e27fe..107977c82c6c 100644
> > --- a/arch/arm64/kvm/arm.c
> > +++ b/arch/arm64/kvm/arm.c
> > @@ -81,26 +81,26 @@ int kvm_arch_check_processor_compat(void *opaque)
> > int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
> > struct kvm_enable_cap *cap)
> > {
> > - int r;
> > + int r = 0;
> >
> > if (cap->flags)
> > return -EINVAL;
> >
> > switch (cap->cap) {
> > case KVM_CAP_ARM_NISV_TO_USER:
> > - r = 0;
> > kvm->arch.return_nisv_io_abort_to_user = true;
> > break;
> > case KVM_CAP_ARM_MTE:
> > mutex_lock(&kvm->lock);
> > - if (!system_supports_mte() || kvm->created_vcpus) {
> > + if (!system_supports_mte() || kvm->created_vcpus)
> > r = -EINVAL;
> > - } else {
> > - r = 0;
> > + else
> > kvm->arch.mte_enabled = true;
> > - }
> > mutex_unlock(&kvm->lock);
> > break;
>
> Hmm.. these all look like cleanups. If you want to propose these, could
> you do it in a separate patch?
>
Ahh, I thought I could squeeze it in. But sure, I can separate it out.
> > + case KVM_CAP_ARM_REG_SCOPE:
> > + WRITE_ONCE(kvm->arch.reg_scope_enabled, true);
> > + break;
> > default:
> > r = -EINVAL;
> > break;
> > @@ -209,6 +209,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> > case KVM_CAP_SET_GUEST_DEBUG:
> > case KVM_CAP_VCPU_ATTRIBUTES:
> > case KVM_CAP_PTP_KVM:
> > + case KVM_CAP_ARM_REG_SCOPE:
>
> It is a bit odd to advertise a capability (and allow userspace to enable
> it), despite the fact that the feature itself hasn't yet been
> implemented.
>
> Is it possible to fold the feature in to the patch that exposes it to
> userspace? Otherwise, you could punt advertisement of the CAP until it
> is actually implemented in kernel.
>
Well, I didn't want to complicate the patch, but technically the
feature is available with this patch, including all the CAP and macro
definitions. Userspace can still decode the scope information, only
that no registers are added yet, which is done in the next patch. So,
the userspace can still remain the same between this and the next
patch.
Thank you.
Raghavendra
> --
> Oliver
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 02/13] KVM: arm64: Introduce KVM_CAP_ARM_REG_SCOPE
2022-02-25 17:34 ` Raghavendra Rao Ananta
(?)
@ 2022-02-25 18:26 ` Oliver Upton
-1 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-02-25 18:26 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: kvm, Will Deacon, Marc Zyngier, Peter Shier, linux-kernel,
Catalin Marinas, Paolo Bonzini, kvmarm, linux-arm-kernel
On Fri, Feb 25, 2022 at 09:34:35AM -0800, Raghavendra Rao Ananta wrote:
> Hey Oliver,
>
> On Thu, Feb 24, 2022 at 10:43 PM Oliver Upton <oupton@google.com> wrote:
> >
> > On Thu, Feb 24, 2022 at 05:25:48PM +0000, Raghavendra Rao Ananta wrote:
> > > KVM_[GET|SET]_ONE_REG act on per-vCPU basis. Currently certain
> > > ARM64 registers, such as KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_[1|2],
> > > are accessed via this interface even though the effect that
> > > they have are really per-VM. As a result, userspace could just
> > > waste cycles to read/write the same information for every vCPU
> > > that it spawns, only to realize that there's absolutely no change
> > > in the VM's state. The problem gets worse in proportion to the
> > > number of vCPUs created.
> > >
> > > As a result, to avoid this redundancy, introduce the capability
> > > KVM_CAP_ARM_REG_SCOPE. If enabled, KVM_GET_REG_LIST will advertise
> > > the registers that are VM-scoped by dynamically modifying the
> > > register encoding. KVM_REG_ARM_SCOPE_* helper macros are introduced
> > > to decode the same. By learning this, userspace can access such
> > > registers only once.
> > >
> > > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > > ---
> > > Documentation/virt/kvm/api.rst | 16 ++++++++++++++++
> > > arch/arm64/include/asm/kvm_host.h | 3 +++
> > > arch/arm64/include/uapi/asm/kvm.h | 6 ++++++
> > > arch/arm64/kvm/arm.c | 13 +++++++------
> > > include/uapi/linux/kvm.h | 1 +
> > > 5 files changed, 33 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> > > index a4267104db50..7e7b3439f540 100644
> > > --- a/Documentation/virt/kvm/api.rst
> > > +++ b/Documentation/virt/kvm/api.rst
> > > @@ -7561,3 +7561,19 @@ The argument to KVM_ENABLE_CAP is also a bitmask, and must be a subset
> > > of the result of KVM_CHECK_EXTENSION. KVM will forward to userspace
> > > the hypercalls whose corresponding bit is in the argument, and return
> > > ENOSYS for the others.
> > > +
> > > +8.34 KVM_CAP_ARM_REG_SCOPE
> > > +--------------------------
> > > +
> > > +:Architectures: arm64
> > > +
> > > +The capability, if enabled, amends the existing register encoding
> > > +with additional information to the userspace if a particular register
> > > +is scoped per-vCPU or per-VM via KVM_GET_REG_LIST. KVM provides
> > > +KVM_REG_ARM_SCOPE_* helper macros to decode the same. Userspace can
> > > +use this information from the register encoding to access a VM-scopped
> > > +regiser only once, as opposed to accessing it for every vCPU for the
> > > +same effect.
> > > +
> >
> > Could you describe the encoding changes in 4.68 'KVM_SET_ONE_REG', along
> > with the other ARM encoding details?
> >
> > > +On the other hand, if the capability is disabled, all the registers
> > > +remain vCPU-scopped by default, retaining backward compatibility.
> >
> > typo: vCPU-scoped
> >
> > That said, I don't believe we need to document behavior if the CAP is
> > disabled, as the implicated ioctls should continue to work the same.
> >
> Sure, I'll address the above two Doc comments.
> > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > > index 5bc01e62c08a..8132de6bd718 100644
> > > --- a/arch/arm64/include/asm/kvm_host.h
> > > +++ b/arch/arm64/include/asm/kvm_host.h
> > > @@ -136,6 +136,9 @@ struct kvm_arch {
> > >
> > > /* Memory Tagging Extension enabled for the guest */
> > > bool mte_enabled;
> > > +
> > > + /* Register scoping enabled for KVM registers */
> > > + bool reg_scope_enabled;
> > > };
> > >
> > > struct kvm_vcpu_fault_info {
> > > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > > index b3edde68bc3e..c35447cc0e0c 100644
> > > --- a/arch/arm64/include/uapi/asm/kvm.h
> > > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > > @@ -199,6 +199,12 @@ struct kvm_arm_copy_mte_tags {
> > > #define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000
> > > #define KVM_REG_ARM_COPROC_SHIFT 16
> > >
> > > +/* Defines if a KVM register is one per-vCPU or one per-VM */
> > > +#define KVM_REG_ARM_SCOPE_MASK 0x0000000010000000
> > > +#define KVM_REG_ARM_SCOPE_SHIFT 28
> >
> > Thinking about the advertisement of VM- and vCPU-scoped registers, this
> > could be generally useful. Might it make sense to add such an encoding
> > to the arch-generic register definitions?
> >
> > If that is the case, we may want to snap up a few more bits (a nybble)
> > for future expansion.
> >
> That's a great idea! But I wonder if we'll get a push-back since there
> are no users of it in other arch(s) yet. Not sure if there was any
> need/discussion regarding the same, but I'm happy to share a patch for
> the same if you sense that there's a strong potential for the patch.
>
I'm unsure if this is actually of interest to other architectures, it
just doesn't seem ARM-specific so we should probably raise the question
so we only grab these bits once.
> > > +#define KVM_REG_ARM_SCOPE_VCPU 0
> > > +#define KVM_REG_ARM_SCOPE_VM 1
> > > +
> > > /* Normal registers are mapped as coprocessor 16. */
> > > #define KVM_REG_ARM_CORE (0x0010 << KVM_REG_ARM_COPROC_SHIFT)
> > > #define KVM_REG_ARM_CORE_REG(name) (offsetof(struct kvm_regs, name) / sizeof(__u32))
> > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > > index ecc5958e27fe..107977c82c6c 100644
> > > --- a/arch/arm64/kvm/arm.c
> > > +++ b/arch/arm64/kvm/arm.c
> > > @@ -81,26 +81,26 @@ int kvm_arch_check_processor_compat(void *opaque)
> > > int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
> > > struct kvm_enable_cap *cap)
> > > {
> > > - int r;
> > > + int r = 0;
> > >
> > > if (cap->flags)
> > > return -EINVAL;
> > >
> > > switch (cap->cap) {
> > > case KVM_CAP_ARM_NISV_TO_USER:
> > > - r = 0;
> > > kvm->arch.return_nisv_io_abort_to_user = true;
> > > break;
> > > case KVM_CAP_ARM_MTE:
> > > mutex_lock(&kvm->lock);
> > > - if (!system_supports_mte() || kvm->created_vcpus) {
> > > + if (!system_supports_mte() || kvm->created_vcpus)
> > > r = -EINVAL;
> > > - } else {
> > > - r = 0;
> > > + else
> > > kvm->arch.mte_enabled = true;
> > > - }
> > > mutex_unlock(&kvm->lock);
> > > break;
> >
> > Hmm.. these all look like cleanups. If you want to propose these, could
> > you do it in a separate patch?
> >
> Ahh, I thought I could squeeze it in. But sure, I can separate it out.
> > > + case KVM_CAP_ARM_REG_SCOPE:
> > > + WRITE_ONCE(kvm->arch.reg_scope_enabled, true);
> > > + break;
> > > default:
> > > r = -EINVAL;
> > > break;
> > > @@ -209,6 +209,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> > > case KVM_CAP_SET_GUEST_DEBUG:
> > > case KVM_CAP_VCPU_ATTRIBUTES:
> > > case KVM_CAP_PTP_KVM:
> > > + case KVM_CAP_ARM_REG_SCOPE:
> >
> > It is a bit odd to advertise a capability (and allow userspace to enable
> > it), despite the fact that the feature itself hasn't yet been
> > implemented.
> >
> > Is it possible to fold the feature in to the patch that exposes it to
> > userspace? Otherwise, you could punt advertisement of the CAP until it
> > is actually implemented in kernel.
> >
> Well, I didn't want to complicate the patch, but technically the
> feature is available with this patch, including all the CAP and macro
> definitions. Userspace can still decode the scope information, only
> that no registers are added yet, which is done in the next patch. So,
> the userspace can still remain the same between this and the next
> patch.
But the series isn't cleanly bisectable. There will exist commits in
history that report KVM_CAP_ARM_REG_SCOPE as implemented even though
that is not actually the case. You should really only advertise support
to userspace when the feature is implemented.
Defining kvm->arch.reg_scope_enabled can be done earlier so you have a
bit to test and guard all of the new code, and only expose the CAP in
the last patch of the series.
Also, as an FYI Marc has a patch that I'll be picking up in my own
series which uses bits instead of bools to keep track of certain
VM-wide features:
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=kvm-arm64/mmu/guest-MMIO-guard&id=7dd0a13a4217b870f2e83cdc6045e5ce482a5340
Marc, if neither of our series land in 5.18 could you at least submit
this patch in preparation? Should keep conflicts minimal that way.
Thanks!
--
Oliver
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 02/13] KVM: arm64: Introduce KVM_CAP_ARM_REG_SCOPE
@ 2022-02-25 18:26 ` Oliver Upton
0 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-02-25 18:26 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Fri, Feb 25, 2022 at 09:34:35AM -0800, Raghavendra Rao Ananta wrote:
> Hey Oliver,
>
> On Thu, Feb 24, 2022 at 10:43 PM Oliver Upton <oupton@google.com> wrote:
> >
> > On Thu, Feb 24, 2022 at 05:25:48PM +0000, Raghavendra Rao Ananta wrote:
> > > KVM_[GET|SET]_ONE_REG act on per-vCPU basis. Currently certain
> > > ARM64 registers, such as KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_[1|2],
> > > are accessed via this interface even though the effect that
> > > they have are really per-VM. As a result, userspace could just
> > > waste cycles to read/write the same information for every vCPU
> > > that it spawns, only to realize that there's absolutely no change
> > > in the VM's state. The problem gets worse in proportion to the
> > > number of vCPUs created.
> > >
> > > As a result, to avoid this redundancy, introduce the capability
> > > KVM_CAP_ARM_REG_SCOPE. If enabled, KVM_GET_REG_LIST will advertise
> > > the registers that are VM-scoped by dynamically modifying the
> > > register encoding. KVM_REG_ARM_SCOPE_* helper macros are introduced
> > > to decode the same. By learning this, userspace can access such
> > > registers only once.
> > >
> > > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > > ---
> > > Documentation/virt/kvm/api.rst | 16 ++++++++++++++++
> > > arch/arm64/include/asm/kvm_host.h | 3 +++
> > > arch/arm64/include/uapi/asm/kvm.h | 6 ++++++
> > > arch/arm64/kvm/arm.c | 13 +++++++------
> > > include/uapi/linux/kvm.h | 1 +
> > > 5 files changed, 33 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> > > index a4267104db50..7e7b3439f540 100644
> > > --- a/Documentation/virt/kvm/api.rst
> > > +++ b/Documentation/virt/kvm/api.rst
> > > @@ -7561,3 +7561,19 @@ The argument to KVM_ENABLE_CAP is also a bitmask, and must be a subset
> > > of the result of KVM_CHECK_EXTENSION. KVM will forward to userspace
> > > the hypercalls whose corresponding bit is in the argument, and return
> > > ENOSYS for the others.
> > > +
> > > +8.34 KVM_CAP_ARM_REG_SCOPE
> > > +--------------------------
> > > +
> > > +:Architectures: arm64
> > > +
> > > +The capability, if enabled, amends the existing register encoding
> > > +with additional information to the userspace if a particular register
> > > +is scoped per-vCPU or per-VM via KVM_GET_REG_LIST. KVM provides
> > > +KVM_REG_ARM_SCOPE_* helper macros to decode the same. Userspace can
> > > +use this information from the register encoding to access a VM-scopped
> > > +regiser only once, as opposed to accessing it for every vCPU for the
> > > +same effect.
> > > +
> >
> > Could you describe the encoding changes in 4.68 'KVM_SET_ONE_REG', along
> > with the other ARM encoding details?
> >
> > > +On the other hand, if the capability is disabled, all the registers
> > > +remain vCPU-scopped by default, retaining backward compatibility.
> >
> > typo: vCPU-scoped
> >
> > That said, I don't believe we need to document behavior if the CAP is
> > disabled, as the implicated ioctls should continue to work the same.
> >
> Sure, I'll address the above two Doc comments.
> > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > > index 5bc01e62c08a..8132de6bd718 100644
> > > --- a/arch/arm64/include/asm/kvm_host.h
> > > +++ b/arch/arm64/include/asm/kvm_host.h
> > > @@ -136,6 +136,9 @@ struct kvm_arch {
> > >
> > > /* Memory Tagging Extension enabled for the guest */
> > > bool mte_enabled;
> > > +
> > > + /* Register scoping enabled for KVM registers */
> > > + bool reg_scope_enabled;
> > > };
> > >
> > > struct kvm_vcpu_fault_info {
> > > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > > index b3edde68bc3e..c35447cc0e0c 100644
> > > --- a/arch/arm64/include/uapi/asm/kvm.h
> > > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > > @@ -199,6 +199,12 @@ struct kvm_arm_copy_mte_tags {
> > > #define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000
> > > #define KVM_REG_ARM_COPROC_SHIFT 16
> > >
> > > +/* Defines if a KVM register is one per-vCPU or one per-VM */
> > > +#define KVM_REG_ARM_SCOPE_MASK 0x0000000010000000
> > > +#define KVM_REG_ARM_SCOPE_SHIFT 28
> >
> > Thinking about the advertisement of VM- and vCPU-scoped registers, this
> > could be generally useful. Might it make sense to add such an encoding
> > to the arch-generic register definitions?
> >
> > If that is the case, we may want to snap up a few more bits (a nybble)
> > for future expansion.
> >
> That's a great idea! But I wonder if we'll get a push-back since there
> are no users of it in other arch(s) yet. Not sure if there was any
> need/discussion regarding the same, but I'm happy to share a patch for
> the same if you sense that there's a strong potential for the patch.
>
I'm unsure if this is actually of interest to other architectures, it
just doesn't seem ARM-specific so we should probably raise the question
so we only grab these bits once.
> > > +#define KVM_REG_ARM_SCOPE_VCPU 0
> > > +#define KVM_REG_ARM_SCOPE_VM 1
> > > +
> > > /* Normal registers are mapped as coprocessor 16. */
> > > #define KVM_REG_ARM_CORE (0x0010 << KVM_REG_ARM_COPROC_SHIFT)
> > > #define KVM_REG_ARM_CORE_REG(name) (offsetof(struct kvm_regs, name) / sizeof(__u32))
> > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > > index ecc5958e27fe..107977c82c6c 100644
> > > --- a/arch/arm64/kvm/arm.c
> > > +++ b/arch/arm64/kvm/arm.c
> > > @@ -81,26 +81,26 @@ int kvm_arch_check_processor_compat(void *opaque)
> > > int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
> > > struct kvm_enable_cap *cap)
> > > {
> > > - int r;
> > > + int r = 0;
> > >
> > > if (cap->flags)
> > > return -EINVAL;
> > >
> > > switch (cap->cap) {
> > > case KVM_CAP_ARM_NISV_TO_USER:
> > > - r = 0;
> > > kvm->arch.return_nisv_io_abort_to_user = true;
> > > break;
> > > case KVM_CAP_ARM_MTE:
> > > mutex_lock(&kvm->lock);
> > > - if (!system_supports_mte() || kvm->created_vcpus) {
> > > + if (!system_supports_mte() || kvm->created_vcpus)
> > > r = -EINVAL;
> > > - } else {
> > > - r = 0;
> > > + else
> > > kvm->arch.mte_enabled = true;
> > > - }
> > > mutex_unlock(&kvm->lock);
> > > break;
> >
> > Hmm.. these all look like cleanups. If you want to propose these, could
> > you do it in a separate patch?
> >
> Ahh, I thought I could squeeze it in. But sure, I can separate it out.
> > > + case KVM_CAP_ARM_REG_SCOPE:
> > > + WRITE_ONCE(kvm->arch.reg_scope_enabled, true);
> > > + break;
> > > default:
> > > r = -EINVAL;
> > > break;
> > > @@ -209,6 +209,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> > > case KVM_CAP_SET_GUEST_DEBUG:
> > > case KVM_CAP_VCPU_ATTRIBUTES:
> > > case KVM_CAP_PTP_KVM:
> > > + case KVM_CAP_ARM_REG_SCOPE:
> >
> > It is a bit odd to advertise a capability (and allow userspace to enable
> > it), despite the fact that the feature itself hasn't yet been
> > implemented.
> >
> > Is it possible to fold the feature in to the patch that exposes it to
> > userspace? Otherwise, you could punt advertisement of the CAP until it
> > is actually implemented in kernel.
> >
> Well, I didn't want to complicate the patch, but technically the
> feature is available with this patch, including all the CAP and macro
> definitions. Userspace can still decode the scope information, only
> that no registers are added yet, which is done in the next patch. So,
> the userspace can still remain the same between this and the next
> patch.
But the series isn't cleanly bisectable. There will exist commits in
history that report KVM_CAP_ARM_REG_SCOPE as implemented even though
that is not actually the case. You should really only advertise support
to userspace when the feature is implemented.
Defining kvm->arch.reg_scope_enabled can be done earlier so you have a
bit to test and guard all of the new code, and only expose the CAP in
the last patch of the series.
Also, as an FYI Marc has a patch that I'll be picking up in my own
series which uses bits instead of bools to keep track of certain
VM-wide features:
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=kvm-arm64/mmu/guest-MMIO-guard&id=7dd0a13a4217b870f2e83cdc6045e5ce482a5340
Marc, if neither of our series land in 5.18 could you at least submit
this patch in preparation? Should keep conflicts minimal that way.
Thanks!
--
Oliver
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 02/13] KVM: arm64: Introduce KVM_CAP_ARM_REG_SCOPE
@ 2022-02-25 18:26 ` Oliver Upton
0 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-02-25 18:26 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Fri, Feb 25, 2022 at 09:34:35AM -0800, Raghavendra Rao Ananta wrote:
> Hey Oliver,
>
> On Thu, Feb 24, 2022 at 10:43 PM Oliver Upton <oupton@google.com> wrote:
> >
> > On Thu, Feb 24, 2022 at 05:25:48PM +0000, Raghavendra Rao Ananta wrote:
> > > KVM_[GET|SET]_ONE_REG act on per-vCPU basis. Currently certain
> > > ARM64 registers, such as KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_[1|2],
> > > are accessed via this interface even though the effect that
> > > they have are really per-VM. As a result, userspace could just
> > > waste cycles to read/write the same information for every vCPU
> > > that it spawns, only to realize that there's absolutely no change
> > > in the VM's state. The problem gets worse in proportion to the
> > > number of vCPUs created.
> > >
> > > As a result, to avoid this redundancy, introduce the capability
> > > KVM_CAP_ARM_REG_SCOPE. If enabled, KVM_GET_REG_LIST will advertise
> > > the registers that are VM-scoped by dynamically modifying the
> > > register encoding. KVM_REG_ARM_SCOPE_* helper macros are introduced
> > > to decode the same. By learning this, userspace can access such
> > > registers only once.
> > >
> > > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > > ---
> > > Documentation/virt/kvm/api.rst | 16 ++++++++++++++++
> > > arch/arm64/include/asm/kvm_host.h | 3 +++
> > > arch/arm64/include/uapi/asm/kvm.h | 6 ++++++
> > > arch/arm64/kvm/arm.c | 13 +++++++------
> > > include/uapi/linux/kvm.h | 1 +
> > > 5 files changed, 33 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> > > index a4267104db50..7e7b3439f540 100644
> > > --- a/Documentation/virt/kvm/api.rst
> > > +++ b/Documentation/virt/kvm/api.rst
> > > @@ -7561,3 +7561,19 @@ The argument to KVM_ENABLE_CAP is also a bitmask, and must be a subset
> > > of the result of KVM_CHECK_EXTENSION. KVM will forward to userspace
> > > the hypercalls whose corresponding bit is in the argument, and return
> > > ENOSYS for the others.
> > > +
> > > +8.34 KVM_CAP_ARM_REG_SCOPE
> > > +--------------------------
> > > +
> > > +:Architectures: arm64
> > > +
> > > +The capability, if enabled, amends the existing register encoding
> > > +with additional information to the userspace if a particular register
> > > +is scoped per-vCPU or per-VM via KVM_GET_REG_LIST. KVM provides
> > > +KVM_REG_ARM_SCOPE_* helper macros to decode the same. Userspace can
> > > +use this information from the register encoding to access a VM-scopped
> > > +regiser only once, as opposed to accessing it for every vCPU for the
> > > +same effect.
> > > +
> >
> > Could you describe the encoding changes in 4.68 'KVM_SET_ONE_REG', along
> > with the other ARM encoding details?
> >
> > > +On the other hand, if the capability is disabled, all the registers
> > > +remain vCPU-scopped by default, retaining backward compatibility.
> >
> > typo: vCPU-scoped
> >
> > That said, I don't believe we need to document behavior if the CAP is
> > disabled, as the implicated ioctls should continue to work the same.
> >
> Sure, I'll address the above two Doc comments.
> > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > > index 5bc01e62c08a..8132de6bd718 100644
> > > --- a/arch/arm64/include/asm/kvm_host.h
> > > +++ b/arch/arm64/include/asm/kvm_host.h
> > > @@ -136,6 +136,9 @@ struct kvm_arch {
> > >
> > > /* Memory Tagging Extension enabled for the guest */
> > > bool mte_enabled;
> > > +
> > > + /* Register scoping enabled for KVM registers */
> > > + bool reg_scope_enabled;
> > > };
> > >
> > > struct kvm_vcpu_fault_info {
> > > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > > index b3edde68bc3e..c35447cc0e0c 100644
> > > --- a/arch/arm64/include/uapi/asm/kvm.h
> > > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > > @@ -199,6 +199,12 @@ struct kvm_arm_copy_mte_tags {
> > > #define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000
> > > #define KVM_REG_ARM_COPROC_SHIFT 16
> > >
> > > +/* Defines if a KVM register is one per-vCPU or one per-VM */
> > > +#define KVM_REG_ARM_SCOPE_MASK 0x0000000010000000
> > > +#define KVM_REG_ARM_SCOPE_SHIFT 28
> >
> > Thinking about the advertisement of VM- and vCPU-scoped registers, this
> > could be generally useful. Might it make sense to add such an encoding
> > to the arch-generic register definitions?
> >
> > If that is the case, we may want to snap up a few more bits (a nybble)
> > for future expansion.
> >
> That's a great idea! But I wonder if we'll get a push-back since there
> are no users of it in other arch(s) yet. Not sure if there was any
> need/discussion regarding the same, but I'm happy to share a patch for
> the same if you sense that there's a strong potential for the patch.
>
I'm unsure if this is actually of interest to other architectures, it
just doesn't seem ARM-specific so we should probably raise the question
so we only grab these bits once.
> > > +#define KVM_REG_ARM_SCOPE_VCPU 0
> > > +#define KVM_REG_ARM_SCOPE_VM 1
> > > +
> > > /* Normal registers are mapped as coprocessor 16. */
> > > #define KVM_REG_ARM_CORE (0x0010 << KVM_REG_ARM_COPROC_SHIFT)
> > > #define KVM_REG_ARM_CORE_REG(name) (offsetof(struct kvm_regs, name) / sizeof(__u32))
> > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > > index ecc5958e27fe..107977c82c6c 100644
> > > --- a/arch/arm64/kvm/arm.c
> > > +++ b/arch/arm64/kvm/arm.c
> > > @@ -81,26 +81,26 @@ int kvm_arch_check_processor_compat(void *opaque)
> > > int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
> > > struct kvm_enable_cap *cap)
> > > {
> > > - int r;
> > > + int r = 0;
> > >
> > > if (cap->flags)
> > > return -EINVAL;
> > >
> > > switch (cap->cap) {
> > > case KVM_CAP_ARM_NISV_TO_USER:
> > > - r = 0;
> > > kvm->arch.return_nisv_io_abort_to_user = true;
> > > break;
> > > case KVM_CAP_ARM_MTE:
> > > mutex_lock(&kvm->lock);
> > > - if (!system_supports_mte() || kvm->created_vcpus) {
> > > + if (!system_supports_mte() || kvm->created_vcpus)
> > > r = -EINVAL;
> > > - } else {
> > > - r = 0;
> > > + else
> > > kvm->arch.mte_enabled = true;
> > > - }
> > > mutex_unlock(&kvm->lock);
> > > break;
> >
> > Hmm.. these all look like cleanups. If you want to propose these, could
> > you do it in a separate patch?
> >
> Ahh, I thought I could squeeze it in. But sure, I can separate it out.
> > > + case KVM_CAP_ARM_REG_SCOPE:
> > > + WRITE_ONCE(kvm->arch.reg_scope_enabled, true);
> > > + break;
> > > default:
> > > r = -EINVAL;
> > > break;
> > > @@ -209,6 +209,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> > > case KVM_CAP_SET_GUEST_DEBUG:
> > > case KVM_CAP_VCPU_ATTRIBUTES:
> > > case KVM_CAP_PTP_KVM:
> > > + case KVM_CAP_ARM_REG_SCOPE:
> >
> > It is a bit odd to advertise a capability (and allow userspace to enable
> > it), despite the fact that the feature itself hasn't yet been
> > implemented.
> >
> > Is it possible to fold the feature in to the patch that exposes it to
> > userspace? Otherwise, you could punt advertisement of the CAP until it
> > is actually implemented in kernel.
> >
> Well, I didn't want to complicate the patch, but technically the
> feature is available with this patch, including all the CAP and macro
> definitions. Userspace can still decode the scope information, only
> that no registers are added yet, which is done in the next patch. So,
> the userspace can still remain the same between this and the next
> patch.
But the series isn't cleanly bisectable. There will exist commits in
history that report KVM_CAP_ARM_REG_SCOPE as implemented even though
that is not actually the case. You should really only advertise support
to userspace when the feature is implemented.
Defining kvm->arch.reg_scope_enabled can be done earlier so you have a
bit to test and guard all of the new code, and only expose the CAP in
the last patch of the series.
Also, as an FYI Marc has a patch that I'll be picking up in my own
series which uses bits instead of bools to keep track of certain
VM-wide features:
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=kvm-arm64/mmu/guest-MMIO-guard&id=7dd0a13a4217b870f2e83cdc6045e5ce482a5340
Marc, if neither of our series land in 5.18 could you at least submit
this patch in preparation? Should keep conflicts minimal that way.
Thanks!
--
Oliver
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 117+ messages in thread
* [PATCH v4 03/13] KVM: arm64: Encode the scope for firmware registers
2022-02-24 17:25 ` Raghavendra Rao Ananta
(?)
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
-1 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: kvm, Catalin Marinas, Peter Shier, linux-kernel, Paolo Bonzini,
Will Deacon, kvmarm, linux-arm-kernel
The psuedo-firmware registers, KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1
and KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2, can be scopped as per-VM
registers. Hence, during the KVM_GET_REG_LIST call, encode
KVM_REG_ARM_SCOPE_VM into the registers, but during
KVM_[GET|SET]_ONE_REG calls, clear the scope information such that
they can be processed like before.
For future expansion, helper functions such as
kvm_arm_reg_id_encode_scope() and kvm_arm_reg_id_clear_scope()
are introduced.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
arch/arm64/include/asm/kvm_host.h | 2 +
arch/arm64/kvm/guest.c | 77 +++++++++++++++++++++++++++++++
arch/arm64/kvm/hypercalls.c | 31 +++++++++----
3 files changed, 100 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 8132de6bd718..657733554d98 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -794,6 +794,8 @@ bool kvm_arm_vcpu_is_finalized(struct kvm_vcpu *vcpu);
(test_bit(KVM_ARM_VCPU_PMU_V3, (vcpu)->arch.features))
int kvm_trng_call(struct kvm_vcpu *vcpu);
+int kvm_arm_reg_id_encode_scope(struct kvm_vcpu *vcpu, u64 *reg_id);
+void kvm_arm_reg_id_clear_scope(struct kvm_vcpu *vcpu, u64 *reg_id);
#ifdef CONFIG_KVM
extern phys_addr_t hyp_mem_base;
extern phys_addr_t hyp_mem_size;
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index 8238e52d890d..eb061e64a7a5 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -61,6 +61,83 @@ const struct kvm_stats_header kvm_vcpu_stats_header = {
sizeof(kvm_vcpu_stats_desc),
};
+/* Registers that are VM scopped */
+static const u64 kvm_arm_vm_scope_fw_regs[] = {
+ KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
+ KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
+};
+
+/**
+ * kvm_arm_reg_id_encode_scope - Encode the KVM_REG_ARM_SCOPE info into the
+ * register-id
+ * @vcpu: The vcpu pointer
+ * @reg_id: Pointer to the register
+ *
+ * The function adds the register's scoping information into its encoding.
+ * If it's explicitly marked as a per-VM register, it's encoded with
+ * KVM_REG_ARM_SCOPE_VM. Else, it's marked as KVM_REG_ARM_SCOPE_VCPU, which
+ * is also the default if KVM_CAP_ARM_REG_SCOPE is disabled.
+ *
+ * For any error cases, the function returns an error code, else it returns
+ * the integer value of the encoding.
+ */
+int kvm_arm_reg_id_encode_scope(struct kvm_vcpu *vcpu, u64 *reg_id)
+{
+ const u64 *vm_scope_reg_arr;
+ unsigned int arr_size, idx;
+
+ if (!READ_ONCE(vcpu->kvm->arch.reg_scope_enabled))
+ return KVM_REG_ARM_SCOPE_VCPU;
+
+ if (!reg_id)
+ return -EINVAL;
+
+ switch (*reg_id & KVM_REG_ARM_COPROC_MASK) {
+ case KVM_REG_ARM_FW:
+ vm_scope_reg_arr = kvm_arm_vm_scope_fw_regs;
+ arr_size = ARRAY_SIZE(kvm_arm_vm_scope_fw_regs);
+ break;
+ default:
+ /* All the other register classes are currently
+ * treated as per-vCPU registers.
+ */
+ return KVM_REG_ARM_SCOPE_VCPU;
+ }
+
+ /* By default, all the registers encodings are scoped as vCPU.
+ * Modify the scope only if a register is marked as per-VM.
+ */
+ for (idx = 0; idx < arr_size; idx++) {
+ if (vm_scope_reg_arr[idx] == *reg_id) {
+ *reg_id |=
+ KVM_REG_ARM_SCOPE_VM << KVM_REG_ARM_SCOPE_SHIFT;
+ return KVM_REG_ARM_SCOPE_VM;
+ }
+ }
+
+ return KVM_REG_ARM_SCOPE_VCPU;
+}
+
+/**
+ * kvm_arm_reg_id_clear_scope - Clear the KVM_REG_ARM_SCOPE info from the
+ * register-id
+ * @vcpu: The vcpu pointer
+ * @reg_id: Pointer to the register
+ *
+ * The function clears the register's scoping information, which ultimately
+ * is the raw encoding of the register. Note that the result is same as that
+ * of re-encoding the register as KVM_REG_ARM_SCOPE_VCPU.
+ * The function can be helpful to the existing code that uses the original
+ * register encoding to operate on the register.
+ */
+void kvm_arm_reg_id_clear_scope(struct kvm_vcpu *vcpu, u64 *reg_id)
+{
+ if (!READ_ONCE(vcpu->kvm->arch.reg_scope_enabled) || !reg_id)
+ return;
+
+ *reg_id &= ~(1 << KVM_REG_ARM_SCOPE_SHIFT);
+}
+
static bool core_reg_offset_is_vreg(u64 off)
{
return off >= KVM_REG_ARM_CORE_REG(fp_regs.vregs) &&
diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
index 3c2fcf31ad3d..8624e6964940 100644
--- a/arch/arm64/kvm/hypercalls.c
+++ b/arch/arm64/kvm/hypercalls.c
@@ -160,10 +160,17 @@ int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
{
- int i;
+ int i, ret;
+ u64 reg_id;
for (i = 0; i < ARRAY_SIZE(kvm_arm_fw_reg_ids); i++) {
- if (put_user(kvm_arm_fw_reg_ids[i], uindices++))
+ reg_id = kvm_arm_fw_reg_ids[i];
+
+ ret = kvm_arm_reg_id_encode_scope(vcpu, ®_id);
+ if (ret < 0)
+ return ret;
+
+ if (put_user(reg_id, uindices++))
return -EFAULT;
}
@@ -214,21 +221,23 @@ static int get_kernel_wa_level(u64 regid)
int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
{
void __user *uaddr = (void __user *)(long)reg->addr;
- u64 val;
+ u64 val, reg_id = reg->id;
- switch (reg->id) {
+ kvm_arm_reg_id_clear_scope(vcpu, ®_id);
+
+ switch (reg_id) {
case KVM_REG_ARM_PSCI_VERSION:
val = kvm_psci_version(vcpu, vcpu->kvm);
break;
case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
- val = get_kernel_wa_level(reg->id) & KVM_REG_FEATURE_LEVEL_MASK;
+ val = get_kernel_wa_level(reg_id) & KVM_REG_FEATURE_LEVEL_MASK;
break;
default:
return -ENOENT;
}
- if (copy_to_user(uaddr, &val, KVM_REG_SIZE(reg->id)))
+ if (copy_to_user(uaddr, &val, KVM_REG_SIZE(reg_id)))
return -EFAULT;
return 0;
@@ -237,13 +246,15 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
{
void __user *uaddr = (void __user *)(long)reg->addr;
- u64 val;
+ u64 val, reg_id = reg->id;
int wa_level;
if (copy_from_user(&val, uaddr, KVM_REG_SIZE(reg->id)))
return -EFAULT;
- switch (reg->id) {
+ kvm_arm_reg_id_clear_scope(vcpu, ®_id);
+
+ switch (reg_id) {
case KVM_REG_ARM_PSCI_VERSION:
{
bool wants_02;
@@ -270,7 +281,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
if (val & ~KVM_REG_FEATURE_LEVEL_MASK)
return -EINVAL;
- if (get_kernel_wa_level(reg->id) < val)
+ if (get_kernel_wa_level(reg_id) < val)
return -EINVAL;
return 0;
@@ -306,7 +317,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
* We can deal with NOT_AVAIL on NOT_REQUIRED, but not the
* other way around.
*/
- if (get_kernel_wa_level(reg->id) < wa_level)
+ if (get_kernel_wa_level(reg_id) < wa_level)
return -EINVAL;
return 0;
--
2.35.1.473.g83b2b277ed-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 117+ messages in thread* [PATCH v4 03/13] KVM: arm64: Encode the scope for firmware registers
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: Paolo Bonzini, Catalin Marinas, Will Deacon, Peter Shier,
Ricardo Koller, Oliver Upton, Reiji Watanabe, Jing Zhang,
Raghavendra Rao Anata, linux-arm-kernel, kvmarm, linux-kernel,
kvm
The psuedo-firmware registers, KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1
and KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2, can be scopped as per-VM
registers. Hence, during the KVM_GET_REG_LIST call, encode
KVM_REG_ARM_SCOPE_VM into the registers, but during
KVM_[GET|SET]_ONE_REG calls, clear the scope information such that
they can be processed like before.
For future expansion, helper functions such as
kvm_arm_reg_id_encode_scope() and kvm_arm_reg_id_clear_scope()
are introduced.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
arch/arm64/include/asm/kvm_host.h | 2 +
arch/arm64/kvm/guest.c | 77 +++++++++++++++++++++++++++++++
arch/arm64/kvm/hypercalls.c | 31 +++++++++----
3 files changed, 100 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 8132de6bd718..657733554d98 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -794,6 +794,8 @@ bool kvm_arm_vcpu_is_finalized(struct kvm_vcpu *vcpu);
(test_bit(KVM_ARM_VCPU_PMU_V3, (vcpu)->arch.features))
int kvm_trng_call(struct kvm_vcpu *vcpu);
+int kvm_arm_reg_id_encode_scope(struct kvm_vcpu *vcpu, u64 *reg_id);
+void kvm_arm_reg_id_clear_scope(struct kvm_vcpu *vcpu, u64 *reg_id);
#ifdef CONFIG_KVM
extern phys_addr_t hyp_mem_base;
extern phys_addr_t hyp_mem_size;
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index 8238e52d890d..eb061e64a7a5 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -61,6 +61,83 @@ const struct kvm_stats_header kvm_vcpu_stats_header = {
sizeof(kvm_vcpu_stats_desc),
};
+/* Registers that are VM scopped */
+static const u64 kvm_arm_vm_scope_fw_regs[] = {
+ KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
+ KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
+};
+
+/**
+ * kvm_arm_reg_id_encode_scope - Encode the KVM_REG_ARM_SCOPE info into the
+ * register-id
+ * @vcpu: The vcpu pointer
+ * @reg_id: Pointer to the register
+ *
+ * The function adds the register's scoping information into its encoding.
+ * If it's explicitly marked as a per-VM register, it's encoded with
+ * KVM_REG_ARM_SCOPE_VM. Else, it's marked as KVM_REG_ARM_SCOPE_VCPU, which
+ * is also the default if KVM_CAP_ARM_REG_SCOPE is disabled.
+ *
+ * For any error cases, the function returns an error code, else it returns
+ * the integer value of the encoding.
+ */
+int kvm_arm_reg_id_encode_scope(struct kvm_vcpu *vcpu, u64 *reg_id)
+{
+ const u64 *vm_scope_reg_arr;
+ unsigned int arr_size, idx;
+
+ if (!READ_ONCE(vcpu->kvm->arch.reg_scope_enabled))
+ return KVM_REG_ARM_SCOPE_VCPU;
+
+ if (!reg_id)
+ return -EINVAL;
+
+ switch (*reg_id & KVM_REG_ARM_COPROC_MASK) {
+ case KVM_REG_ARM_FW:
+ vm_scope_reg_arr = kvm_arm_vm_scope_fw_regs;
+ arr_size = ARRAY_SIZE(kvm_arm_vm_scope_fw_regs);
+ break;
+ default:
+ /* All the other register classes are currently
+ * treated as per-vCPU registers.
+ */
+ return KVM_REG_ARM_SCOPE_VCPU;
+ }
+
+ /* By default, all the registers encodings are scoped as vCPU.
+ * Modify the scope only if a register is marked as per-VM.
+ */
+ for (idx = 0; idx < arr_size; idx++) {
+ if (vm_scope_reg_arr[idx] == *reg_id) {
+ *reg_id |=
+ KVM_REG_ARM_SCOPE_VM << KVM_REG_ARM_SCOPE_SHIFT;
+ return KVM_REG_ARM_SCOPE_VM;
+ }
+ }
+
+ return KVM_REG_ARM_SCOPE_VCPU;
+}
+
+/**
+ * kvm_arm_reg_id_clear_scope - Clear the KVM_REG_ARM_SCOPE info from the
+ * register-id
+ * @vcpu: The vcpu pointer
+ * @reg_id: Pointer to the register
+ *
+ * The function clears the register's scoping information, which ultimately
+ * is the raw encoding of the register. Note that the result is same as that
+ * of re-encoding the register as KVM_REG_ARM_SCOPE_VCPU.
+ * The function can be helpful to the existing code that uses the original
+ * register encoding to operate on the register.
+ */
+void kvm_arm_reg_id_clear_scope(struct kvm_vcpu *vcpu, u64 *reg_id)
+{
+ if (!READ_ONCE(vcpu->kvm->arch.reg_scope_enabled) || !reg_id)
+ return;
+
+ *reg_id &= ~(1 << KVM_REG_ARM_SCOPE_SHIFT);
+}
+
static bool core_reg_offset_is_vreg(u64 off)
{
return off >= KVM_REG_ARM_CORE_REG(fp_regs.vregs) &&
diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
index 3c2fcf31ad3d..8624e6964940 100644
--- a/arch/arm64/kvm/hypercalls.c
+++ b/arch/arm64/kvm/hypercalls.c
@@ -160,10 +160,17 @@ int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
{
- int i;
+ int i, ret;
+ u64 reg_id;
for (i = 0; i < ARRAY_SIZE(kvm_arm_fw_reg_ids); i++) {
- if (put_user(kvm_arm_fw_reg_ids[i], uindices++))
+ reg_id = kvm_arm_fw_reg_ids[i];
+
+ ret = kvm_arm_reg_id_encode_scope(vcpu, ®_id);
+ if (ret < 0)
+ return ret;
+
+ if (put_user(reg_id, uindices++))
return -EFAULT;
}
@@ -214,21 +221,23 @@ static int get_kernel_wa_level(u64 regid)
int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
{
void __user *uaddr = (void __user *)(long)reg->addr;
- u64 val;
+ u64 val, reg_id = reg->id;
- switch (reg->id) {
+ kvm_arm_reg_id_clear_scope(vcpu, ®_id);
+
+ switch (reg_id) {
case KVM_REG_ARM_PSCI_VERSION:
val = kvm_psci_version(vcpu, vcpu->kvm);
break;
case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
- val = get_kernel_wa_level(reg->id) & KVM_REG_FEATURE_LEVEL_MASK;
+ val = get_kernel_wa_level(reg_id) & KVM_REG_FEATURE_LEVEL_MASK;
break;
default:
return -ENOENT;
}
- if (copy_to_user(uaddr, &val, KVM_REG_SIZE(reg->id)))
+ if (copy_to_user(uaddr, &val, KVM_REG_SIZE(reg_id)))
return -EFAULT;
return 0;
@@ -237,13 +246,15 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
{
void __user *uaddr = (void __user *)(long)reg->addr;
- u64 val;
+ u64 val, reg_id = reg->id;
int wa_level;
if (copy_from_user(&val, uaddr, KVM_REG_SIZE(reg->id)))
return -EFAULT;
- switch (reg->id) {
+ kvm_arm_reg_id_clear_scope(vcpu, ®_id);
+
+ switch (reg_id) {
case KVM_REG_ARM_PSCI_VERSION:
{
bool wants_02;
@@ -270,7 +281,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
if (val & ~KVM_REG_FEATURE_LEVEL_MASK)
return -EINVAL;
- if (get_kernel_wa_level(reg->id) < val)
+ if (get_kernel_wa_level(reg_id) < val)
return -EINVAL;
return 0;
@@ -306,7 +317,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
* We can deal with NOT_AVAIL on NOT_REQUIRED, but not the
* other way around.
*/
- if (get_kernel_wa_level(reg->id) < wa_level)
+ if (get_kernel_wa_level(reg_id) < wa_level)
return -EINVAL;
return 0;
--
2.35.1.473.g83b2b277ed-goog
^ permalink raw reply related [flat|nested] 117+ messages in thread* [PATCH v4 03/13] KVM: arm64: Encode the scope for firmware registers
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: Paolo Bonzini, Catalin Marinas, Will Deacon, Peter Shier,
Ricardo Koller, Oliver Upton, Reiji Watanabe, Jing Zhang,
Raghavendra Rao Anata, linux-arm-kernel, kvmarm, linux-kernel,
kvm
The psuedo-firmware registers, KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1
and KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2, can be scopped as per-VM
registers. Hence, during the KVM_GET_REG_LIST call, encode
KVM_REG_ARM_SCOPE_VM into the registers, but during
KVM_[GET|SET]_ONE_REG calls, clear the scope information such that
they can be processed like before.
For future expansion, helper functions such as
kvm_arm_reg_id_encode_scope() and kvm_arm_reg_id_clear_scope()
are introduced.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
arch/arm64/include/asm/kvm_host.h | 2 +
arch/arm64/kvm/guest.c | 77 +++++++++++++++++++++++++++++++
arch/arm64/kvm/hypercalls.c | 31 +++++++++----
3 files changed, 100 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 8132de6bd718..657733554d98 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -794,6 +794,8 @@ bool kvm_arm_vcpu_is_finalized(struct kvm_vcpu *vcpu);
(test_bit(KVM_ARM_VCPU_PMU_V3, (vcpu)->arch.features))
int kvm_trng_call(struct kvm_vcpu *vcpu);
+int kvm_arm_reg_id_encode_scope(struct kvm_vcpu *vcpu, u64 *reg_id);
+void kvm_arm_reg_id_clear_scope(struct kvm_vcpu *vcpu, u64 *reg_id);
#ifdef CONFIG_KVM
extern phys_addr_t hyp_mem_base;
extern phys_addr_t hyp_mem_size;
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index 8238e52d890d..eb061e64a7a5 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -61,6 +61,83 @@ const struct kvm_stats_header kvm_vcpu_stats_header = {
sizeof(kvm_vcpu_stats_desc),
};
+/* Registers that are VM scopped */
+static const u64 kvm_arm_vm_scope_fw_regs[] = {
+ KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
+ KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
+};
+
+/**
+ * kvm_arm_reg_id_encode_scope - Encode the KVM_REG_ARM_SCOPE info into the
+ * register-id
+ * @vcpu: The vcpu pointer
+ * @reg_id: Pointer to the register
+ *
+ * The function adds the register's scoping information into its encoding.
+ * If it's explicitly marked as a per-VM register, it's encoded with
+ * KVM_REG_ARM_SCOPE_VM. Else, it's marked as KVM_REG_ARM_SCOPE_VCPU, which
+ * is also the default if KVM_CAP_ARM_REG_SCOPE is disabled.
+ *
+ * For any error cases, the function returns an error code, else it returns
+ * the integer value of the encoding.
+ */
+int kvm_arm_reg_id_encode_scope(struct kvm_vcpu *vcpu, u64 *reg_id)
+{
+ const u64 *vm_scope_reg_arr;
+ unsigned int arr_size, idx;
+
+ if (!READ_ONCE(vcpu->kvm->arch.reg_scope_enabled))
+ return KVM_REG_ARM_SCOPE_VCPU;
+
+ if (!reg_id)
+ return -EINVAL;
+
+ switch (*reg_id & KVM_REG_ARM_COPROC_MASK) {
+ case KVM_REG_ARM_FW:
+ vm_scope_reg_arr = kvm_arm_vm_scope_fw_regs;
+ arr_size = ARRAY_SIZE(kvm_arm_vm_scope_fw_regs);
+ break;
+ default:
+ /* All the other register classes are currently
+ * treated as per-vCPU registers.
+ */
+ return KVM_REG_ARM_SCOPE_VCPU;
+ }
+
+ /* By default, all the registers encodings are scoped as vCPU.
+ * Modify the scope only if a register is marked as per-VM.
+ */
+ for (idx = 0; idx < arr_size; idx++) {
+ if (vm_scope_reg_arr[idx] == *reg_id) {
+ *reg_id |=
+ KVM_REG_ARM_SCOPE_VM << KVM_REG_ARM_SCOPE_SHIFT;
+ return KVM_REG_ARM_SCOPE_VM;
+ }
+ }
+
+ return KVM_REG_ARM_SCOPE_VCPU;
+}
+
+/**
+ * kvm_arm_reg_id_clear_scope - Clear the KVM_REG_ARM_SCOPE info from the
+ * register-id
+ * @vcpu: The vcpu pointer
+ * @reg_id: Pointer to the register
+ *
+ * The function clears the register's scoping information, which ultimately
+ * is the raw encoding of the register. Note that the result is same as that
+ * of re-encoding the register as KVM_REG_ARM_SCOPE_VCPU.
+ * The function can be helpful to the existing code that uses the original
+ * register encoding to operate on the register.
+ */
+void kvm_arm_reg_id_clear_scope(struct kvm_vcpu *vcpu, u64 *reg_id)
+{
+ if (!READ_ONCE(vcpu->kvm->arch.reg_scope_enabled) || !reg_id)
+ return;
+
+ *reg_id &= ~(1 << KVM_REG_ARM_SCOPE_SHIFT);
+}
+
static bool core_reg_offset_is_vreg(u64 off)
{
return off >= KVM_REG_ARM_CORE_REG(fp_regs.vregs) &&
diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
index 3c2fcf31ad3d..8624e6964940 100644
--- a/arch/arm64/kvm/hypercalls.c
+++ b/arch/arm64/kvm/hypercalls.c
@@ -160,10 +160,17 @@ int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
{
- int i;
+ int i, ret;
+ u64 reg_id;
for (i = 0; i < ARRAY_SIZE(kvm_arm_fw_reg_ids); i++) {
- if (put_user(kvm_arm_fw_reg_ids[i], uindices++))
+ reg_id = kvm_arm_fw_reg_ids[i];
+
+ ret = kvm_arm_reg_id_encode_scope(vcpu, ®_id);
+ if (ret < 0)
+ return ret;
+
+ if (put_user(reg_id, uindices++))
return -EFAULT;
}
@@ -214,21 +221,23 @@ static int get_kernel_wa_level(u64 regid)
int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
{
void __user *uaddr = (void __user *)(long)reg->addr;
- u64 val;
+ u64 val, reg_id = reg->id;
- switch (reg->id) {
+ kvm_arm_reg_id_clear_scope(vcpu, ®_id);
+
+ switch (reg_id) {
case KVM_REG_ARM_PSCI_VERSION:
val = kvm_psci_version(vcpu, vcpu->kvm);
break;
case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
- val = get_kernel_wa_level(reg->id) & KVM_REG_FEATURE_LEVEL_MASK;
+ val = get_kernel_wa_level(reg_id) & KVM_REG_FEATURE_LEVEL_MASK;
break;
default:
return -ENOENT;
}
- if (copy_to_user(uaddr, &val, KVM_REG_SIZE(reg->id)))
+ if (copy_to_user(uaddr, &val, KVM_REG_SIZE(reg_id)))
return -EFAULT;
return 0;
@@ -237,13 +246,15 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
{
void __user *uaddr = (void __user *)(long)reg->addr;
- u64 val;
+ u64 val, reg_id = reg->id;
int wa_level;
if (copy_from_user(&val, uaddr, KVM_REG_SIZE(reg->id)))
return -EFAULT;
- switch (reg->id) {
+ kvm_arm_reg_id_clear_scope(vcpu, ®_id);
+
+ switch (reg_id) {
case KVM_REG_ARM_PSCI_VERSION:
{
bool wants_02;
@@ -270,7 +281,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
if (val & ~KVM_REG_FEATURE_LEVEL_MASK)
return -EINVAL;
- if (get_kernel_wa_level(reg->id) < val)
+ if (get_kernel_wa_level(reg_id) < val)
return -EINVAL;
return 0;
@@ -306,7 +317,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
* We can deal with NOT_AVAIL on NOT_REQUIRED, but not the
* other way around.
*/
- if (get_kernel_wa_level(reg->id) < wa_level)
+ if (get_kernel_wa_level(reg_id) < wa_level)
return -EINVAL;
return 0;
--
2.35.1.473.g83b2b277ed-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 117+ messages in thread* Re: [PATCH v4 03/13] KVM: arm64: Encode the scope for firmware registers
2022-02-24 17:25 ` Raghavendra Rao Ananta
(?)
@ 2022-03-14 19:16 ` Oliver Upton
-1 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-14 19:16 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: kvm, Will Deacon, Marc Zyngier, Peter Shier, linux-kernel,
Catalin Marinas, Paolo Bonzini, kvmarm, linux-arm-kernel
Hi Raghu,
On Thu, Feb 24, 2022 at 05:25:49PM +0000, Raghavendra Rao Ananta wrote:
> The psuedo-firmware registers, KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1
> and KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2, can be scopped as per-VM
> registers. Hence, during the KVM_GET_REG_LIST call, encode
> KVM_REG_ARM_SCOPE_VM into the registers, but during
> KVM_[GET|SET]_ONE_REG calls, clear the scope information such that
> they can be processed like before.
>
> For future expansion, helper functions such as
> kvm_arm_reg_id_encode_scope() and kvm_arm_reg_id_clear_scope()
> are introduced.
>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> ---
> arch/arm64/include/asm/kvm_host.h | 2 +
> arch/arm64/kvm/guest.c | 77 +++++++++++++++++++++++++++++++
> arch/arm64/kvm/hypercalls.c | 31 +++++++++----
> 3 files changed, 100 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 8132de6bd718..657733554d98 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -794,6 +794,8 @@ bool kvm_arm_vcpu_is_finalized(struct kvm_vcpu *vcpu);
> (test_bit(KVM_ARM_VCPU_PMU_V3, (vcpu)->arch.features))
>
> int kvm_trng_call(struct kvm_vcpu *vcpu);
> +int kvm_arm_reg_id_encode_scope(struct kvm_vcpu *vcpu, u64 *reg_id);
> +void kvm_arm_reg_id_clear_scope(struct kvm_vcpu *vcpu, u64 *reg_id);
> #ifdef CONFIG_KVM
> extern phys_addr_t hyp_mem_base;
> extern phys_addr_t hyp_mem_size;
> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> index 8238e52d890d..eb061e64a7a5 100644
> --- a/arch/arm64/kvm/guest.c
> +++ b/arch/arm64/kvm/guest.c
> @@ -61,6 +61,83 @@ const struct kvm_stats_header kvm_vcpu_stats_header = {
> sizeof(kvm_vcpu_stats_desc),
> };
>
> +/* Registers that are VM scopped */
> +static const u64 kvm_arm_vm_scope_fw_regs[] = {
> + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> +};
Is there a reason that KVM_REG_ARM_PSCI_VERSION is omitted? I know that
we have KVM_ARM_VCPU_PSCI_0_2, but we really don't allow for asymmetry
in the PSCI implementation between vCPUs. Logically, this is a
system-wide property. That's a complete wreck if KVM_ARM_VCPU_PSCI_0_2
isn't required to be set/clear for all vCPUs in a VM.
> +
> +/**
> + * kvm_arm_reg_id_encode_scope - Encode the KVM_REG_ARM_SCOPE info into the
> + * register-id
> + * @vcpu: The vcpu pointer
> + * @reg_id: Pointer to the register
> + *
> + * The function adds the register's scoping information into its encoding.
> + * If it's explicitly marked as a per-VM register, it's encoded with
> + * KVM_REG_ARM_SCOPE_VM. Else, it's marked as KVM_REG_ARM_SCOPE_VCPU, which
> + * is also the default if KVM_CAP_ARM_REG_SCOPE is disabled.
> + *
> + * For any error cases, the function returns an error code, else it returns
> + * the integer value of the encoding.
> + */
> +int kvm_arm_reg_id_encode_scope(struct kvm_vcpu *vcpu, u64 *reg_id)
> +{
> + const u64 *vm_scope_reg_arr;
> + unsigned int arr_size, idx;
> +
> + if (!READ_ONCE(vcpu->kvm->arch.reg_scope_enabled))
> + return KVM_REG_ARM_SCOPE_VCPU;
> +
> + if (!reg_id)
> + return -EINVAL;
> +
> + switch (*reg_id & KVM_REG_ARM_COPROC_MASK) {
> + case KVM_REG_ARM_FW:
> + vm_scope_reg_arr = kvm_arm_vm_scope_fw_regs;
> + arr_size = ARRAY_SIZE(kvm_arm_vm_scope_fw_regs);
> + break;
> + default:
> + /* All the other register classes are currently
> + * treated as per-vCPU registers.
> + */
> + return KVM_REG_ARM_SCOPE_VCPU;
> + }
> +
> + /* By default, all the registers encodings are scoped as vCPU.
> + * Modify the scope only if a register is marked as per-VM.
> + */
> + for (idx = 0; idx < arr_size; idx++) {
> + if (vm_scope_reg_arr[idx] == *reg_id) {
> + *reg_id |=
> + KVM_REG_ARM_SCOPE_VM << KVM_REG_ARM_SCOPE_SHIFT;
> + return KVM_REG_ARM_SCOPE_VM;
> + }
> + }
> +
> + return KVM_REG_ARM_SCOPE_VCPU;
> +}
> +
> +/**
> + * kvm_arm_reg_id_clear_scope - Clear the KVM_REG_ARM_SCOPE info from the
> + * register-id
> + * @vcpu: The vcpu pointer
> + * @reg_id: Pointer to the register
> + *
> + * The function clears the register's scoping information, which ultimately
> + * is the raw encoding of the register. Note that the result is same as that
> + * of re-encoding the register as KVM_REG_ARM_SCOPE_VCPU.
> + * The function can be helpful to the existing code that uses the original
> + * register encoding to operate on the register.
> + */
> +void kvm_arm_reg_id_clear_scope(struct kvm_vcpu *vcpu, u64 *reg_id)
How about just taking the reg_id by value and returning it? You could
probably just bundle this up in a macro
> +{
> + if (!READ_ONCE(vcpu->kvm->arch.reg_scope_enabled) || !reg_id)
Shouldn't masking these bits work regardless? They must be zero without
the CAP.
> + return;
> +
> + *reg_id &= ~(1 << KVM_REG_ARM_SCOPE_SHIFT);
define a _MASK for KVM_REG_ARM_SCOPE and just use that.
> +}
> +
> static bool core_reg_offset_is_vreg(u64 off)
> {
> return off >= KVM_REG_ARM_CORE_REG(fp_regs.vregs) &&
> diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> index 3c2fcf31ad3d..8624e6964940 100644
> --- a/arch/arm64/kvm/hypercalls.c
> +++ b/arch/arm64/kvm/hypercalls.c
> @@ -160,10 +160,17 @@ int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
>
> int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
> {
> - int i;
> + int i, ret;
> + u64 reg_id;
>
> for (i = 0; i < ARRAY_SIZE(kvm_arm_fw_reg_ids); i++) {
> - if (put_user(kvm_arm_fw_reg_ids[i], uindices++))
> + reg_id = kvm_arm_fw_reg_ids[i];
> +
> + ret = kvm_arm_reg_id_encode_scope(vcpu, ®_id);
> + if (ret < 0)
> + return ret;
You could also store the register IDs with the scope already encoded and
simply mask those bits off if the CAP is disabled. That way, its
immediately obvious what the scope of any given register is just by
looking at the register table.
> + if (put_user(reg_id, uindices++))
> return -EFAULT;
> }
>
> @@ -214,21 +221,23 @@ static int get_kernel_wa_level(u64 regid)
> int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> {
> void __user *uaddr = (void __user *)(long)reg->addr;
> - u64 val;
> + u64 val, reg_id = reg->id;
>
> - switch (reg->id) {
> + kvm_arm_reg_id_clear_scope(vcpu, ®_id);
> +
> + switch (reg_id) {
> case KVM_REG_ARM_PSCI_VERSION:
> val = kvm_psci_version(vcpu, vcpu->kvm);
> break;
> case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> - val = get_kernel_wa_level(reg->id) & KVM_REG_FEATURE_LEVEL_MASK;
> + val = get_kernel_wa_level(reg_id) & KVM_REG_FEATURE_LEVEL_MASK;
> break;
> default:
> return -ENOENT;
> }
>
> - if (copy_to_user(uaddr, &val, KVM_REG_SIZE(reg->id)))
> + if (copy_to_user(uaddr, &val, KVM_REG_SIZE(reg_id)))
> return -EFAULT;
>
> return 0;
> @@ -237,13 +246,15 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> {
> void __user *uaddr = (void __user *)(long)reg->addr;
> - u64 val;
> + u64 val, reg_id = reg->id;
> int wa_level;
>
> if (copy_from_user(&val, uaddr, KVM_REG_SIZE(reg->id)))
> return -EFAULT;
>
> - switch (reg->id) {
> + kvm_arm_reg_id_clear_scope(vcpu, ®_id);
> +
> + switch (reg_id) {
> case KVM_REG_ARM_PSCI_VERSION:
> {
> bool wants_02;
> @@ -270,7 +281,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> if (val & ~KVM_REG_FEATURE_LEVEL_MASK)
> return -EINVAL;
>
> - if (get_kernel_wa_level(reg->id) < val)
> + if (get_kernel_wa_level(reg_id) < val)
> return -EINVAL;
>
> return 0;
> @@ -306,7 +317,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> * We can deal with NOT_AVAIL on NOT_REQUIRED, but not the
> * other way around.
> */
> - if (get_kernel_wa_level(reg->id) < wa_level)
> + if (get_kernel_wa_level(reg_id) < wa_level)
> return -EINVAL;
>
> return 0;
> --
> 2.35.1.473.g83b2b277ed-goog
>
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 03/13] KVM: arm64: Encode the scope for firmware registers
@ 2022-03-14 19:16 ` Oliver Upton
0 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-14 19:16 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
Hi Raghu,
On Thu, Feb 24, 2022 at 05:25:49PM +0000, Raghavendra Rao Ananta wrote:
> The psuedo-firmware registers, KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1
> and KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2, can be scopped as per-VM
> registers. Hence, during the KVM_GET_REG_LIST call, encode
> KVM_REG_ARM_SCOPE_VM into the registers, but during
> KVM_[GET|SET]_ONE_REG calls, clear the scope information such that
> they can be processed like before.
>
> For future expansion, helper functions such as
> kvm_arm_reg_id_encode_scope() and kvm_arm_reg_id_clear_scope()
> are introduced.
>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> ---
> arch/arm64/include/asm/kvm_host.h | 2 +
> arch/arm64/kvm/guest.c | 77 +++++++++++++++++++++++++++++++
> arch/arm64/kvm/hypercalls.c | 31 +++++++++----
> 3 files changed, 100 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 8132de6bd718..657733554d98 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -794,6 +794,8 @@ bool kvm_arm_vcpu_is_finalized(struct kvm_vcpu *vcpu);
> (test_bit(KVM_ARM_VCPU_PMU_V3, (vcpu)->arch.features))
>
> int kvm_trng_call(struct kvm_vcpu *vcpu);
> +int kvm_arm_reg_id_encode_scope(struct kvm_vcpu *vcpu, u64 *reg_id);
> +void kvm_arm_reg_id_clear_scope(struct kvm_vcpu *vcpu, u64 *reg_id);
> #ifdef CONFIG_KVM
> extern phys_addr_t hyp_mem_base;
> extern phys_addr_t hyp_mem_size;
> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> index 8238e52d890d..eb061e64a7a5 100644
> --- a/arch/arm64/kvm/guest.c
> +++ b/arch/arm64/kvm/guest.c
> @@ -61,6 +61,83 @@ const struct kvm_stats_header kvm_vcpu_stats_header = {
> sizeof(kvm_vcpu_stats_desc),
> };
>
> +/* Registers that are VM scopped */
> +static const u64 kvm_arm_vm_scope_fw_regs[] = {
> + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> +};
Is there a reason that KVM_REG_ARM_PSCI_VERSION is omitted? I know that
we have KVM_ARM_VCPU_PSCI_0_2, but we really don't allow for asymmetry
in the PSCI implementation between vCPUs. Logically, this is a
system-wide property. That's a complete wreck if KVM_ARM_VCPU_PSCI_0_2
isn't required to be set/clear for all vCPUs in a VM.
> +
> +/**
> + * kvm_arm_reg_id_encode_scope - Encode the KVM_REG_ARM_SCOPE info into the
> + * register-id
> + * @vcpu: The vcpu pointer
> + * @reg_id: Pointer to the register
> + *
> + * The function adds the register's scoping information into its encoding.
> + * If it's explicitly marked as a per-VM register, it's encoded with
> + * KVM_REG_ARM_SCOPE_VM. Else, it's marked as KVM_REG_ARM_SCOPE_VCPU, which
> + * is also the default if KVM_CAP_ARM_REG_SCOPE is disabled.
> + *
> + * For any error cases, the function returns an error code, else it returns
> + * the integer value of the encoding.
> + */
> +int kvm_arm_reg_id_encode_scope(struct kvm_vcpu *vcpu, u64 *reg_id)
> +{
> + const u64 *vm_scope_reg_arr;
> + unsigned int arr_size, idx;
> +
> + if (!READ_ONCE(vcpu->kvm->arch.reg_scope_enabled))
> + return KVM_REG_ARM_SCOPE_VCPU;
> +
> + if (!reg_id)
> + return -EINVAL;
> +
> + switch (*reg_id & KVM_REG_ARM_COPROC_MASK) {
> + case KVM_REG_ARM_FW:
> + vm_scope_reg_arr = kvm_arm_vm_scope_fw_regs;
> + arr_size = ARRAY_SIZE(kvm_arm_vm_scope_fw_regs);
> + break;
> + default:
> + /* All the other register classes are currently
> + * treated as per-vCPU registers.
> + */
> + return KVM_REG_ARM_SCOPE_VCPU;
> + }
> +
> + /* By default, all the registers encodings are scoped as vCPU.
> + * Modify the scope only if a register is marked as per-VM.
> + */
> + for (idx = 0; idx < arr_size; idx++) {
> + if (vm_scope_reg_arr[idx] == *reg_id) {
> + *reg_id |=
> + KVM_REG_ARM_SCOPE_VM << KVM_REG_ARM_SCOPE_SHIFT;
> + return KVM_REG_ARM_SCOPE_VM;
> + }
> + }
> +
> + return KVM_REG_ARM_SCOPE_VCPU;
> +}
> +
> +/**
> + * kvm_arm_reg_id_clear_scope - Clear the KVM_REG_ARM_SCOPE info from the
> + * register-id
> + * @vcpu: The vcpu pointer
> + * @reg_id: Pointer to the register
> + *
> + * The function clears the register's scoping information, which ultimately
> + * is the raw encoding of the register. Note that the result is same as that
> + * of re-encoding the register as KVM_REG_ARM_SCOPE_VCPU.
> + * The function can be helpful to the existing code that uses the original
> + * register encoding to operate on the register.
> + */
> +void kvm_arm_reg_id_clear_scope(struct kvm_vcpu *vcpu, u64 *reg_id)
How about just taking the reg_id by value and returning it? You could
probably just bundle this up in a macro
> +{
> + if (!READ_ONCE(vcpu->kvm->arch.reg_scope_enabled) || !reg_id)
Shouldn't masking these bits work regardless? They must be zero without
the CAP.
> + return;
> +
> + *reg_id &= ~(1 << KVM_REG_ARM_SCOPE_SHIFT);
define a _MASK for KVM_REG_ARM_SCOPE and just use that.
> +}
> +
> static bool core_reg_offset_is_vreg(u64 off)
> {
> return off >= KVM_REG_ARM_CORE_REG(fp_regs.vregs) &&
> diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> index 3c2fcf31ad3d..8624e6964940 100644
> --- a/arch/arm64/kvm/hypercalls.c
> +++ b/arch/arm64/kvm/hypercalls.c
> @@ -160,10 +160,17 @@ int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
>
> int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
> {
> - int i;
> + int i, ret;
> + u64 reg_id;
>
> for (i = 0; i < ARRAY_SIZE(kvm_arm_fw_reg_ids); i++) {
> - if (put_user(kvm_arm_fw_reg_ids[i], uindices++))
> + reg_id = kvm_arm_fw_reg_ids[i];
> +
> + ret = kvm_arm_reg_id_encode_scope(vcpu, ®_id);
> + if (ret < 0)
> + return ret;
You could also store the register IDs with the scope already encoded and
simply mask those bits off if the CAP is disabled. That way, its
immediately obvious what the scope of any given register is just by
looking at the register table.
> + if (put_user(reg_id, uindices++))
> return -EFAULT;
> }
>
> @@ -214,21 +221,23 @@ static int get_kernel_wa_level(u64 regid)
> int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> {
> void __user *uaddr = (void __user *)(long)reg->addr;
> - u64 val;
> + u64 val, reg_id = reg->id;
>
> - switch (reg->id) {
> + kvm_arm_reg_id_clear_scope(vcpu, ®_id);
> +
> + switch (reg_id) {
> case KVM_REG_ARM_PSCI_VERSION:
> val = kvm_psci_version(vcpu, vcpu->kvm);
> break;
> case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> - val = get_kernel_wa_level(reg->id) & KVM_REG_FEATURE_LEVEL_MASK;
> + val = get_kernel_wa_level(reg_id) & KVM_REG_FEATURE_LEVEL_MASK;
> break;
> default:
> return -ENOENT;
> }
>
> - if (copy_to_user(uaddr, &val, KVM_REG_SIZE(reg->id)))
> + if (copy_to_user(uaddr, &val, KVM_REG_SIZE(reg_id)))
> return -EFAULT;
>
> return 0;
> @@ -237,13 +246,15 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> {
> void __user *uaddr = (void __user *)(long)reg->addr;
> - u64 val;
> + u64 val, reg_id = reg->id;
> int wa_level;
>
> if (copy_from_user(&val, uaddr, KVM_REG_SIZE(reg->id)))
> return -EFAULT;
>
> - switch (reg->id) {
> + kvm_arm_reg_id_clear_scope(vcpu, ®_id);
> +
> + switch (reg_id) {
> case KVM_REG_ARM_PSCI_VERSION:
> {
> bool wants_02;
> @@ -270,7 +281,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> if (val & ~KVM_REG_FEATURE_LEVEL_MASK)
> return -EINVAL;
>
> - if (get_kernel_wa_level(reg->id) < val)
> + if (get_kernel_wa_level(reg_id) < val)
> return -EINVAL;
>
> return 0;
> @@ -306,7 +317,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> * We can deal with NOT_AVAIL on NOT_REQUIRED, but not the
> * other way around.
> */
> - if (get_kernel_wa_level(reg->id) < wa_level)
> + if (get_kernel_wa_level(reg_id) < wa_level)
> return -EINVAL;
>
> return 0;
> --
> 2.35.1.473.g83b2b277ed-goog
>
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 03/13] KVM: arm64: Encode the scope for firmware registers
@ 2022-03-14 19:16 ` Oliver Upton
0 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-14 19:16 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
Hi Raghu,
On Thu, Feb 24, 2022 at 05:25:49PM +0000, Raghavendra Rao Ananta wrote:
> The psuedo-firmware registers, KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1
> and KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2, can be scopped as per-VM
> registers. Hence, during the KVM_GET_REG_LIST call, encode
> KVM_REG_ARM_SCOPE_VM into the registers, but during
> KVM_[GET|SET]_ONE_REG calls, clear the scope information such that
> they can be processed like before.
>
> For future expansion, helper functions such as
> kvm_arm_reg_id_encode_scope() and kvm_arm_reg_id_clear_scope()
> are introduced.
>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> ---
> arch/arm64/include/asm/kvm_host.h | 2 +
> arch/arm64/kvm/guest.c | 77 +++++++++++++++++++++++++++++++
> arch/arm64/kvm/hypercalls.c | 31 +++++++++----
> 3 files changed, 100 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 8132de6bd718..657733554d98 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -794,6 +794,8 @@ bool kvm_arm_vcpu_is_finalized(struct kvm_vcpu *vcpu);
> (test_bit(KVM_ARM_VCPU_PMU_V3, (vcpu)->arch.features))
>
> int kvm_trng_call(struct kvm_vcpu *vcpu);
> +int kvm_arm_reg_id_encode_scope(struct kvm_vcpu *vcpu, u64 *reg_id);
> +void kvm_arm_reg_id_clear_scope(struct kvm_vcpu *vcpu, u64 *reg_id);
> #ifdef CONFIG_KVM
> extern phys_addr_t hyp_mem_base;
> extern phys_addr_t hyp_mem_size;
> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> index 8238e52d890d..eb061e64a7a5 100644
> --- a/arch/arm64/kvm/guest.c
> +++ b/arch/arm64/kvm/guest.c
> @@ -61,6 +61,83 @@ const struct kvm_stats_header kvm_vcpu_stats_header = {
> sizeof(kvm_vcpu_stats_desc),
> };
>
> +/* Registers that are VM scopped */
> +static const u64 kvm_arm_vm_scope_fw_regs[] = {
> + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> +};
Is there a reason that KVM_REG_ARM_PSCI_VERSION is omitted? I know that
we have KVM_ARM_VCPU_PSCI_0_2, but we really don't allow for asymmetry
in the PSCI implementation between vCPUs. Logically, this is a
system-wide property. That's a complete wreck if KVM_ARM_VCPU_PSCI_0_2
isn't required to be set/clear for all vCPUs in a VM.
> +
> +/**
> + * kvm_arm_reg_id_encode_scope - Encode the KVM_REG_ARM_SCOPE info into the
> + * register-id
> + * @vcpu: The vcpu pointer
> + * @reg_id: Pointer to the register
> + *
> + * The function adds the register's scoping information into its encoding.
> + * If it's explicitly marked as a per-VM register, it's encoded with
> + * KVM_REG_ARM_SCOPE_VM. Else, it's marked as KVM_REG_ARM_SCOPE_VCPU, which
> + * is also the default if KVM_CAP_ARM_REG_SCOPE is disabled.
> + *
> + * For any error cases, the function returns an error code, else it returns
> + * the integer value of the encoding.
> + */
> +int kvm_arm_reg_id_encode_scope(struct kvm_vcpu *vcpu, u64 *reg_id)
> +{
> + const u64 *vm_scope_reg_arr;
> + unsigned int arr_size, idx;
> +
> + if (!READ_ONCE(vcpu->kvm->arch.reg_scope_enabled))
> + return KVM_REG_ARM_SCOPE_VCPU;
> +
> + if (!reg_id)
> + return -EINVAL;
> +
> + switch (*reg_id & KVM_REG_ARM_COPROC_MASK) {
> + case KVM_REG_ARM_FW:
> + vm_scope_reg_arr = kvm_arm_vm_scope_fw_regs;
> + arr_size = ARRAY_SIZE(kvm_arm_vm_scope_fw_regs);
> + break;
> + default:
> + /* All the other register classes are currently
> + * treated as per-vCPU registers.
> + */
> + return KVM_REG_ARM_SCOPE_VCPU;
> + }
> +
> + /* By default, all the registers encodings are scoped as vCPU.
> + * Modify the scope only if a register is marked as per-VM.
> + */
> + for (idx = 0; idx < arr_size; idx++) {
> + if (vm_scope_reg_arr[idx] == *reg_id) {
> + *reg_id |=
> + KVM_REG_ARM_SCOPE_VM << KVM_REG_ARM_SCOPE_SHIFT;
> + return KVM_REG_ARM_SCOPE_VM;
> + }
> + }
> +
> + return KVM_REG_ARM_SCOPE_VCPU;
> +}
> +
> +/**
> + * kvm_arm_reg_id_clear_scope - Clear the KVM_REG_ARM_SCOPE info from the
> + * register-id
> + * @vcpu: The vcpu pointer
> + * @reg_id: Pointer to the register
> + *
> + * The function clears the register's scoping information, which ultimately
> + * is the raw encoding of the register. Note that the result is same as that
> + * of re-encoding the register as KVM_REG_ARM_SCOPE_VCPU.
> + * The function can be helpful to the existing code that uses the original
> + * register encoding to operate on the register.
> + */
> +void kvm_arm_reg_id_clear_scope(struct kvm_vcpu *vcpu, u64 *reg_id)
How about just taking the reg_id by value and returning it? You could
probably just bundle this up in a macro
> +{
> + if (!READ_ONCE(vcpu->kvm->arch.reg_scope_enabled) || !reg_id)
Shouldn't masking these bits work regardless? They must be zero without
the CAP.
> + return;
> +
> + *reg_id &= ~(1 << KVM_REG_ARM_SCOPE_SHIFT);
define a _MASK for KVM_REG_ARM_SCOPE and just use that.
> +}
> +
> static bool core_reg_offset_is_vreg(u64 off)
> {
> return off >= KVM_REG_ARM_CORE_REG(fp_regs.vregs) &&
> diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> index 3c2fcf31ad3d..8624e6964940 100644
> --- a/arch/arm64/kvm/hypercalls.c
> +++ b/arch/arm64/kvm/hypercalls.c
> @@ -160,10 +160,17 @@ int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
>
> int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
> {
> - int i;
> + int i, ret;
> + u64 reg_id;
>
> for (i = 0; i < ARRAY_SIZE(kvm_arm_fw_reg_ids); i++) {
> - if (put_user(kvm_arm_fw_reg_ids[i], uindices++))
> + reg_id = kvm_arm_fw_reg_ids[i];
> +
> + ret = kvm_arm_reg_id_encode_scope(vcpu, ®_id);
> + if (ret < 0)
> + return ret;
You could also store the register IDs with the scope already encoded and
simply mask those bits off if the CAP is disabled. That way, its
immediately obvious what the scope of any given register is just by
looking at the register table.
> + if (put_user(reg_id, uindices++))
> return -EFAULT;
> }
>
> @@ -214,21 +221,23 @@ static int get_kernel_wa_level(u64 regid)
> int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> {
> void __user *uaddr = (void __user *)(long)reg->addr;
> - u64 val;
> + u64 val, reg_id = reg->id;
>
> - switch (reg->id) {
> + kvm_arm_reg_id_clear_scope(vcpu, ®_id);
> +
> + switch (reg_id) {
> case KVM_REG_ARM_PSCI_VERSION:
> val = kvm_psci_version(vcpu, vcpu->kvm);
> break;
> case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
> case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> - val = get_kernel_wa_level(reg->id) & KVM_REG_FEATURE_LEVEL_MASK;
> + val = get_kernel_wa_level(reg_id) & KVM_REG_FEATURE_LEVEL_MASK;
> break;
> default:
> return -ENOENT;
> }
>
> - if (copy_to_user(uaddr, &val, KVM_REG_SIZE(reg->id)))
> + if (copy_to_user(uaddr, &val, KVM_REG_SIZE(reg_id)))
> return -EFAULT;
>
> return 0;
> @@ -237,13 +246,15 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> {
> void __user *uaddr = (void __user *)(long)reg->addr;
> - u64 val;
> + u64 val, reg_id = reg->id;
> int wa_level;
>
> if (copy_from_user(&val, uaddr, KVM_REG_SIZE(reg->id)))
> return -EFAULT;
>
> - switch (reg->id) {
> + kvm_arm_reg_id_clear_scope(vcpu, ®_id);
> +
> + switch (reg_id) {
> case KVM_REG_ARM_PSCI_VERSION:
> {
> bool wants_02;
> @@ -270,7 +281,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> if (val & ~KVM_REG_FEATURE_LEVEL_MASK)
> return -EINVAL;
>
> - if (get_kernel_wa_level(reg->id) < val)
> + if (get_kernel_wa_level(reg_id) < val)
> return -EINVAL;
>
> return 0;
> @@ -306,7 +317,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> * We can deal with NOT_AVAIL on NOT_REQUIRED, but not the
> * other way around.
> */
> - if (get_kernel_wa_level(reg->id) < wa_level)
> + if (get_kernel_wa_level(reg_id) < wa_level)
> return -EINVAL;
>
> return 0;
> --
> 2.35.1.473.g83b2b277ed-goog
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 117+ messages in thread
* [PATCH v4 04/13] KVM: arm64: Capture VM's first run
2022-02-24 17:25 ` Raghavendra Rao Ananta
(?)
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
-1 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: kvm, Catalin Marinas, Peter Shier, linux-kernel, Paolo Bonzini,
Will Deacon, kvmarm, linux-arm-kernel
Capture the first run of the KVM VM, which is basically the
first KVM_RUN issued for any vCPU. This state of the VM is
helpful in the upcoming patches to prevent user-space from
configuring certain VM features, such as the feature bitmap
exposed by the psuedo-firmware registers, after the VM has
started running.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
arch/arm64/include/asm/kvm_host.h | 9 +++++++++
arch/arm64/kvm/arm.c | 2 ++
2 files changed, 11 insertions(+)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 657733554d98..e823571e50cc 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -139,6 +139,9 @@ struct kvm_arch {
/* Register scoping enabled for KVM registers */
bool reg_scope_enabled;
+
+ /* Capture first run of the VM */
+ bool has_run_once;
};
struct kvm_vcpu_fault_info {
@@ -796,6 +799,12 @@ bool kvm_arm_vcpu_is_finalized(struct kvm_vcpu *vcpu);
int kvm_trng_call(struct kvm_vcpu *vcpu);
int kvm_arm_reg_id_encode_scope(struct kvm_vcpu *vcpu, u64 *reg_id);
void kvm_arm_reg_id_clear_scope(struct kvm_vcpu *vcpu, u64 *reg_id);
+
+static inline bool kvm_arm_vm_has_run_once(struct kvm_arch *kvm_arch)
+{
+ return kvm_arch->has_run_once;
+}
+
#ifdef CONFIG_KVM
extern phys_addr_t hyp_mem_base;
extern phys_addr_t hyp_mem_size;
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 107977c82c6c..f61cd8d57eae 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -635,6 +635,8 @@ int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu)
if (kvm_vm_is_protected(kvm))
kvm_call_hyp_nvhe(__pkvm_vcpu_init_traps, vcpu);
+ kvm->arch.has_run_once = true;
+
return ret;
}
--
2.35.1.473.g83b2b277ed-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 117+ messages in thread* [PATCH v4 04/13] KVM: arm64: Capture VM's first run
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: Paolo Bonzini, Catalin Marinas, Will Deacon, Peter Shier,
Ricardo Koller, Oliver Upton, Reiji Watanabe, Jing Zhang,
Raghavendra Rao Anata, linux-arm-kernel, kvmarm, linux-kernel,
kvm
Capture the first run of the KVM VM, which is basically the
first KVM_RUN issued for any vCPU. This state of the VM is
helpful in the upcoming patches to prevent user-space from
configuring certain VM features, such as the feature bitmap
exposed by the psuedo-firmware registers, after the VM has
started running.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
arch/arm64/include/asm/kvm_host.h | 9 +++++++++
arch/arm64/kvm/arm.c | 2 ++
2 files changed, 11 insertions(+)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 657733554d98..e823571e50cc 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -139,6 +139,9 @@ struct kvm_arch {
/* Register scoping enabled for KVM registers */
bool reg_scope_enabled;
+
+ /* Capture first run of the VM */
+ bool has_run_once;
};
struct kvm_vcpu_fault_info {
@@ -796,6 +799,12 @@ bool kvm_arm_vcpu_is_finalized(struct kvm_vcpu *vcpu);
int kvm_trng_call(struct kvm_vcpu *vcpu);
int kvm_arm_reg_id_encode_scope(struct kvm_vcpu *vcpu, u64 *reg_id);
void kvm_arm_reg_id_clear_scope(struct kvm_vcpu *vcpu, u64 *reg_id);
+
+static inline bool kvm_arm_vm_has_run_once(struct kvm_arch *kvm_arch)
+{
+ return kvm_arch->has_run_once;
+}
+
#ifdef CONFIG_KVM
extern phys_addr_t hyp_mem_base;
extern phys_addr_t hyp_mem_size;
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 107977c82c6c..f61cd8d57eae 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -635,6 +635,8 @@ int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu)
if (kvm_vm_is_protected(kvm))
kvm_call_hyp_nvhe(__pkvm_vcpu_init_traps, vcpu);
+ kvm->arch.has_run_once = true;
+
return ret;
}
--
2.35.1.473.g83b2b277ed-goog
^ permalink raw reply related [flat|nested] 117+ messages in thread* [PATCH v4 04/13] KVM: arm64: Capture VM's first run
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: Paolo Bonzini, Catalin Marinas, Will Deacon, Peter Shier,
Ricardo Koller, Oliver Upton, Reiji Watanabe, Jing Zhang,
Raghavendra Rao Anata, linux-arm-kernel, kvmarm, linux-kernel,
kvm
Capture the first run of the KVM VM, which is basically the
first KVM_RUN issued for any vCPU. This state of the VM is
helpful in the upcoming patches to prevent user-space from
configuring certain VM features, such as the feature bitmap
exposed by the psuedo-firmware registers, after the VM has
started running.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
arch/arm64/include/asm/kvm_host.h | 9 +++++++++
arch/arm64/kvm/arm.c | 2 ++
2 files changed, 11 insertions(+)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 657733554d98..e823571e50cc 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -139,6 +139,9 @@ struct kvm_arch {
/* Register scoping enabled for KVM registers */
bool reg_scope_enabled;
+
+ /* Capture first run of the VM */
+ bool has_run_once;
};
struct kvm_vcpu_fault_info {
@@ -796,6 +799,12 @@ bool kvm_arm_vcpu_is_finalized(struct kvm_vcpu *vcpu);
int kvm_trng_call(struct kvm_vcpu *vcpu);
int kvm_arm_reg_id_encode_scope(struct kvm_vcpu *vcpu, u64 *reg_id);
void kvm_arm_reg_id_clear_scope(struct kvm_vcpu *vcpu, u64 *reg_id);
+
+static inline bool kvm_arm_vm_has_run_once(struct kvm_arch *kvm_arch)
+{
+ return kvm_arch->has_run_once;
+}
+
#ifdef CONFIG_KVM
extern phys_addr_t hyp_mem_base;
extern phys_addr_t hyp_mem_size;
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 107977c82c6c..f61cd8d57eae 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -635,6 +635,8 @@ int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu)
if (kvm_vm_is_protected(kvm))
kvm_call_hyp_nvhe(__pkvm_vcpu_init_traps, vcpu);
+ kvm->arch.has_run_once = true;
+
return ret;
}
--
2.35.1.473.g83b2b277ed-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 117+ messages in thread* Re: [PATCH v4 04/13] KVM: arm64: Capture VM's first run
2022-02-24 17:25 ` Raghavendra Rao Ananta
(?)
@ 2022-03-14 18:02 ` Oliver Upton
-1 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-14 18:02 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: kvm, Will Deacon, Marc Zyngier, Peter Shier, linux-kernel,
Catalin Marinas, Paolo Bonzini, kvmarm, linux-arm-kernel
Hi Raghavendra,
On Thu, Feb 24, 2022 at 05:25:50PM +0000, Raghavendra Rao Ananta wrote:
> Capture the first run of the KVM VM, which is basically the
> first KVM_RUN issued for any vCPU. This state of the VM is
> helpful in the upcoming patches to prevent user-space from
> configuring certain VM features, such as the feature bitmap
> exposed by the psuedo-firmware registers, after the VM has
> started running.
>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
I believe this patch is superseded by commit:
5177fe91e4cf ("KVM: arm64: Do not change the PMU event filter after a VCPU has run")
on kvmarm/next.
--
Thanks,
Oliver
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 04/13] KVM: arm64: Capture VM's first run
@ 2022-03-14 18:02 ` Oliver Upton
0 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-14 18:02 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
Hi Raghavendra,
On Thu, Feb 24, 2022 at 05:25:50PM +0000, Raghavendra Rao Ananta wrote:
> Capture the first run of the KVM VM, which is basically the
> first KVM_RUN issued for any vCPU. This state of the VM is
> helpful in the upcoming patches to prevent user-space from
> configuring certain VM features, such as the feature bitmap
> exposed by the psuedo-firmware registers, after the VM has
> started running.
>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
I believe this patch is superseded by commit:
5177fe91e4cf ("KVM: arm64: Do not change the PMU event filter after a VCPU has run")
on kvmarm/next.
--
Thanks,
Oliver
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 04/13] KVM: arm64: Capture VM's first run
@ 2022-03-14 18:02 ` Oliver Upton
0 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-14 18:02 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
Hi Raghavendra,
On Thu, Feb 24, 2022 at 05:25:50PM +0000, Raghavendra Rao Ananta wrote:
> Capture the first run of the KVM VM, which is basically the
> first KVM_RUN issued for any vCPU. This state of the VM is
> helpful in the upcoming patches to prevent user-space from
> configuring certain VM features, such as the feature bitmap
> exposed by the psuedo-firmware registers, after the VM has
> started running.
>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
I believe this patch is superseded by commit:
5177fe91e4cf ("KVM: arm64: Do not change the PMU event filter after a VCPU has run")
on kvmarm/next.
--
Thanks,
Oliver
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 04/13] KVM: arm64: Capture VM's first run
2022-03-14 18:02 ` Oliver Upton
(?)
@ 2022-03-14 23:12 ` Raghavendra Rao Ananta
-1 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-03-14 23:12 UTC (permalink / raw)
To: Oliver Upton
Cc: kvm, Will Deacon, Marc Zyngier, Peter Shier, linux-kernel,
Catalin Marinas, Paolo Bonzini, kvmarm, linux-arm-kernel
On Mon, Mar 14, 2022 at 11:02 AM Oliver Upton <oupton@google.com> wrote:
Hi Oliver,
>
> Hi Raghavendra,
>
> On Thu, Feb 24, 2022 at 05:25:50PM +0000, Raghavendra Rao Ananta wrote:
> > Capture the first run of the KVM VM, which is basically the
> > first KVM_RUN issued for any vCPU. This state of the VM is
> > helpful in the upcoming patches to prevent user-space from
> > configuring certain VM features, such as the feature bitmap
> > exposed by the psuedo-firmware registers, after the VM has
> > started running.
> >
> > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
>
> I believe this patch is superseded by commit:
>
> 5177fe91e4cf ("KVM: arm64: Do not change the PMU event filter after a VCPU has run")
>
> on kvmarm/next.
>
Perfect! Just what we needed. I'll drop this patch.
Regards,
Raghavendra
>
> --
> Thanks,
> Oliver
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 04/13] KVM: arm64: Capture VM's first run
@ 2022-03-14 23:12 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-03-14 23:12 UTC (permalink / raw)
To: Oliver Upton
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Mon, Mar 14, 2022 at 11:02 AM Oliver Upton <oupton@google.com> wrote:
Hi Oliver,
>
> Hi Raghavendra,
>
> On Thu, Feb 24, 2022 at 05:25:50PM +0000, Raghavendra Rao Ananta wrote:
> > Capture the first run of the KVM VM, which is basically the
> > first KVM_RUN issued for any vCPU. This state of the VM is
> > helpful in the upcoming patches to prevent user-space from
> > configuring certain VM features, such as the feature bitmap
> > exposed by the psuedo-firmware registers, after the VM has
> > started running.
> >
> > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
>
> I believe this patch is superseded by commit:
>
> 5177fe91e4cf ("KVM: arm64: Do not change the PMU event filter after a VCPU has run")
>
> on kvmarm/next.
>
Perfect! Just what we needed. I'll drop this patch.
Regards,
Raghavendra
>
> --
> Thanks,
> Oliver
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 04/13] KVM: arm64: Capture VM's first run
@ 2022-03-14 23:12 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-03-14 23:12 UTC (permalink / raw)
To: Oliver Upton
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Mon, Mar 14, 2022 at 11:02 AM Oliver Upton <oupton@google.com> wrote:
Hi Oliver,
>
> Hi Raghavendra,
>
> On Thu, Feb 24, 2022 at 05:25:50PM +0000, Raghavendra Rao Ananta wrote:
> > Capture the first run of the KVM VM, which is basically the
> > first KVM_RUN issued for any vCPU. This state of the VM is
> > helpful in the upcoming patches to prevent user-space from
> > configuring certain VM features, such as the feature bitmap
> > exposed by the psuedo-firmware registers, after the VM has
> > started running.
> >
> > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
>
> I believe this patch is superseded by commit:
>
> 5177fe91e4cf ("KVM: arm64: Do not change the PMU event filter after a VCPU has run")
>
> on kvmarm/next.
>
Perfect! Just what we needed. I'll drop this patch.
Regards,
Raghavendra
>
> --
> Thanks,
> Oliver
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 117+ messages in thread
* [PATCH v4 05/13] KVM: arm64: Setup a framework for hypercall bitmap firmware registers
2022-02-24 17:25 ` Raghavendra Rao Ananta
(?)
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
-1 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: kvm, Catalin Marinas, Peter Shier, linux-kernel, Paolo Bonzini,
Will Deacon, kvmarm, linux-arm-kernel
KVM regularly introduces new hypercall services to the guests without
any consent from the userspace. This means, the guests can observe
hypercall services in and out as they migrate across various host
kernel versions. This could be a major problem if the guest
discovered a hypercall, started using it, and after getting migrated
to an older kernel realizes that it's no longer available. Depending
on how the guest handles the change, there's a potential chance that
the guest would just panic.
As a result, there's a need for the userspace to elect the services
that it wishes the guest to discover. It can elect these services
based on the kernels spread across its (migration) fleet. To remedy
this, extend the existing firmware psuedo-registers, such as
KVM_REG_ARM_PSCI_VERSION, for all the hypercall services available.
These firmware registers are categorized based on the service call
owners, and unlike the existing firmware psuedo-registers, they hold
the features supported in the form of a bitmap.
During the VM initialization, the registers holds an upper-limit of
the features supported by the corresponding registers. It's expected
that the VMMs discover the features provided by each register via
GET_ONE_REG, and writeback the desired values using SET_ONE_REG.
KVM allows this modification only until the VM has started.
Older userspace code can simply ignore the capability and the
hypercall services will be exposed unconditionally to the guests, thus
ensuring backward compatibility.
In this patch, the framework adds the register only for ARM's standard
secure services (owner value 4). Currently, this includes support only
for ARM True Random Number Generator (TRNG) service, with bit-0 of the
register representing mandatory features of v1.0. The register is also
added to the kvm_arm_vm_scope_fw_regs[] list as it maintains its state
per-VM. Other services are momentarily added in the upcoming patches.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
arch/arm64/include/asm/kvm_host.h | 12 +++++
arch/arm64/include/uapi/asm/kvm.h | 8 ++++
arch/arm64/kvm/arm.c | 8 ++++
arch/arm64/kvm/guest.c | 1 +
arch/arm64/kvm/hypercalls.c | 78 +++++++++++++++++++++++++++++++
include/kvm/arm_hypercalls.h | 4 ++
6 files changed, 111 insertions(+)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index e823571e50cc..1909ced3208f 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -101,6 +101,15 @@ struct kvm_s2_mmu {
struct kvm_arch_memory_slot {
};
+/**
+ * struct kvm_hvc_desc: KVM ARM64 hypercall descriptor
+ *
+ * @hvc_std_bmap: Bitmap of standard secure service calls
+ */
+struct kvm_hvc_desc {
+ u64 hvc_std_bmap;
+};
+
struct kvm_arch {
struct kvm_s2_mmu mmu;
@@ -142,6 +151,9 @@ struct kvm_arch {
/* Capture first run of the VM */
bool has_run_once;
+
+ /* Hypercall firmware register' descriptor */
+ struct kvm_hvc_desc hvc_desc;
};
struct kvm_vcpu_fault_info {
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index c35447cc0e0c..2decc30d6b84 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -287,6 +287,14 @@ struct kvm_arm_copy_mte_tags {
#define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED 3
#define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED (1U << 4)
+/* Bitmap firmware registers, extension to the existing psuedo-register space */
+#define KVM_REG_ARM_FW_BMAP KVM_REG_ARM_FW_REG(0xff00)
+#define KVM_REG_ARM_FW_BMAP_REG(r) (KVM_REG_ARM_FW_BMAP | (r))
+
+#define KVM_REG_ARM_STD_BMAP KVM_REG_ARM_FW_BMAP_REG(0)
+#define KVM_REG_ARM_STD_BIT_TRNG_V1_0 BIT(0)
+#define KVM_REG_ARM_STD_BMAP_BIT_MAX 0 /* Last valid bit */
+
/* SVE registers */
#define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index f61cd8d57eae..e9f9edb1cf55 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -156,6 +156,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
kvm->arch.max_vcpus = kvm_arm_default_max_vcpus();
set_default_spectre(kvm);
+ kvm_arm_init_hypercalls(kvm);
return ret;
out_free_stage2_pgd:
@@ -635,7 +636,14 @@ int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu)
if (kvm_vm_is_protected(kvm))
kvm_call_hyp_nvhe(__pkvm_vcpu_init_traps, vcpu);
+ /*
+ * Grab kvm->lock such that the reader of has_run_once can finish
+ * the necessary operation atomically, such as deciding whether to
+ * block the writes to the firmware registers if the VM has run once.
+ */
+ mutex_lock(&kvm->lock);
kvm->arch.has_run_once = true;
+ mutex_unlock(&kvm->lock);
return ret;
}
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index eb061e64a7a5..d66e6c742bbe 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -65,6 +65,7 @@ const struct kvm_stats_header kvm_vcpu_stats_header = {
static const u64 kvm_arm_vm_scope_fw_regs[] = {
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
+ KVM_REG_ARM_STD_BMAP,
};
/**
diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
index 8624e6964940..48c126c3da72 100644
--- a/arch/arm64/kvm/hypercalls.c
+++ b/arch/arm64/kvm/hypercalls.c
@@ -58,6 +58,29 @@ static void kvm_ptp_get_time(struct kvm_vcpu *vcpu, u64 *val)
val[3] = lower_32_bits(cycles);
}
+static bool kvm_arm_fw_reg_feat_enabled(u64 reg_bmap, u64 feat_bit)
+{
+ return reg_bmap & feat_bit;
+}
+
+static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
+{
+ struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
+
+ switch (func_id) {
+ case ARM_SMCCC_TRNG_VERSION:
+ case ARM_SMCCC_TRNG_FEATURES:
+ case ARM_SMCCC_TRNG_GET_UUID:
+ case ARM_SMCCC_TRNG_RND32:
+ case ARM_SMCCC_TRNG_RND64:
+ return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_bmap,
+ KVM_REG_ARM_STD_BIT_TRNG_V1_0);
+ default:
+ /* By default, allow the services that aren't listed here */
+ return true;
+ }
+}
+
int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
{
u32 func_id = smccc_get_function(vcpu);
@@ -65,6 +88,9 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
u32 feature;
gpa_t gpa;
+ if (!kvm_hvc_call_supported(vcpu, func_id))
+ goto out;
+
switch (func_id) {
case ARM_SMCCC_VERSION_FUNC_ID:
val[0] = ARM_SMCCC_VERSION_1_1;
@@ -143,6 +169,7 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
return kvm_psci_call(vcpu);
}
+out:
smccc_set_retval(vcpu, val[0], val[1], val[2], val[3]);
return 1;
}
@@ -151,8 +178,16 @@ static const u64 kvm_arm_fw_reg_ids[] = {
KVM_REG_ARM_PSCI_VERSION,
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
+ KVM_REG_ARM_STD_BMAP,
};
+void kvm_arm_init_hypercalls(struct kvm *kvm)
+{
+ struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
+
+ hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
+}
+
int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
{
return ARRAY_SIZE(kvm_arm_fw_reg_ids);
@@ -220,6 +255,7 @@ static int get_kernel_wa_level(u64 regid)
int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
{
+ struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
void __user *uaddr = (void __user *)(long)reg->addr;
u64 val, reg_id = reg->id;
@@ -233,6 +269,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
val = get_kernel_wa_level(reg_id) & KVM_REG_FEATURE_LEVEL_MASK;
break;
+ case KVM_REG_ARM_STD_BMAP:
+ val = READ_ONCE(hvc_desc->hvc_std_bmap);
+ break;
default:
return -ENOENT;
}
@@ -243,6 +282,43 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
return 0;
}
+static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
+{
+ int ret = 0;
+ struct kvm *kvm = vcpu->kvm;
+ struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
+ u64 *fw_reg_bmap, fw_reg_features;
+
+ switch (reg_id) {
+ case KVM_REG_ARM_STD_BMAP:
+ fw_reg_bmap = &hvc_desc->hvc_std_bmap;
+ fw_reg_features = ARM_SMCCC_STD_FEATURES;
+ break;
+ default:
+ return -ENOENT;
+ }
+
+ /* Check for unsupported bit */
+ if (val & ~fw_reg_features)
+ return -EINVAL;
+
+ mutex_lock(&kvm->lock);
+
+ /*
+ * If the VM (any vCPU) has already started running, return success
+ * if there's no change in the value. Else, return -EBUSY.
+ */
+ if (kvm_arm_vm_has_run_once(&kvm->arch)) {
+ ret = *fw_reg_bmap != val ? -EBUSY : 0;
+ goto out;
+ }
+
+ WRITE_ONCE(*fw_reg_bmap, val);
+out:
+ mutex_unlock(&kvm->lock);
+ return ret;
+}
+
int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
{
void __user *uaddr = (void __user *)(long)reg->addr;
@@ -321,6 +397,8 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
return -EINVAL;
return 0;
+ case KVM_REG_ARM_STD_BMAP:
+ return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
default:
return -ENOENT;
}
diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
index 5d38628a8d04..64d30b452809 100644
--- a/include/kvm/arm_hypercalls.h
+++ b/include/kvm/arm_hypercalls.h
@@ -6,6 +6,9 @@
#include <asm/kvm_emulate.h>
+#define ARM_SMCCC_STD_FEATURES \
+ GENMASK_ULL(KVM_REG_ARM_STD_BMAP_BIT_MAX, 0)
+
int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
@@ -42,6 +45,7 @@ static inline void smccc_set_retval(struct kvm_vcpu *vcpu,
struct kvm_one_reg;
+void kvm_arm_init_hypercalls(struct kvm *kvm);
int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
--
2.35.1.473.g83b2b277ed-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 117+ messages in thread* [PATCH v4 05/13] KVM: arm64: Setup a framework for hypercall bitmap firmware registers
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: Paolo Bonzini, Catalin Marinas, Will Deacon, Peter Shier,
Ricardo Koller, Oliver Upton, Reiji Watanabe, Jing Zhang,
Raghavendra Rao Anata, linux-arm-kernel, kvmarm, linux-kernel,
kvm
KVM regularly introduces new hypercall services to the guests without
any consent from the userspace. This means, the guests can observe
hypercall services in and out as they migrate across various host
kernel versions. This could be a major problem if the guest
discovered a hypercall, started using it, and after getting migrated
to an older kernel realizes that it's no longer available. Depending
on how the guest handles the change, there's a potential chance that
the guest would just panic.
As a result, there's a need for the userspace to elect the services
that it wishes the guest to discover. It can elect these services
based on the kernels spread across its (migration) fleet. To remedy
this, extend the existing firmware psuedo-registers, such as
KVM_REG_ARM_PSCI_VERSION, for all the hypercall services available.
These firmware registers are categorized based on the service call
owners, and unlike the existing firmware psuedo-registers, they hold
the features supported in the form of a bitmap.
During the VM initialization, the registers holds an upper-limit of
the features supported by the corresponding registers. It's expected
that the VMMs discover the features provided by each register via
GET_ONE_REG, and writeback the desired values using SET_ONE_REG.
KVM allows this modification only until the VM has started.
Older userspace code can simply ignore the capability and the
hypercall services will be exposed unconditionally to the guests, thus
ensuring backward compatibility.
In this patch, the framework adds the register only for ARM's standard
secure services (owner value 4). Currently, this includes support only
for ARM True Random Number Generator (TRNG) service, with bit-0 of the
register representing mandatory features of v1.0. The register is also
added to the kvm_arm_vm_scope_fw_regs[] list as it maintains its state
per-VM. Other services are momentarily added in the upcoming patches.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
arch/arm64/include/asm/kvm_host.h | 12 +++++
arch/arm64/include/uapi/asm/kvm.h | 8 ++++
arch/arm64/kvm/arm.c | 8 ++++
arch/arm64/kvm/guest.c | 1 +
arch/arm64/kvm/hypercalls.c | 78 +++++++++++++++++++++++++++++++
include/kvm/arm_hypercalls.h | 4 ++
6 files changed, 111 insertions(+)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index e823571e50cc..1909ced3208f 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -101,6 +101,15 @@ struct kvm_s2_mmu {
struct kvm_arch_memory_slot {
};
+/**
+ * struct kvm_hvc_desc: KVM ARM64 hypercall descriptor
+ *
+ * @hvc_std_bmap: Bitmap of standard secure service calls
+ */
+struct kvm_hvc_desc {
+ u64 hvc_std_bmap;
+};
+
struct kvm_arch {
struct kvm_s2_mmu mmu;
@@ -142,6 +151,9 @@ struct kvm_arch {
/* Capture first run of the VM */
bool has_run_once;
+
+ /* Hypercall firmware register' descriptor */
+ struct kvm_hvc_desc hvc_desc;
};
struct kvm_vcpu_fault_info {
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index c35447cc0e0c..2decc30d6b84 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -287,6 +287,14 @@ struct kvm_arm_copy_mte_tags {
#define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED 3
#define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED (1U << 4)
+/* Bitmap firmware registers, extension to the existing psuedo-register space */
+#define KVM_REG_ARM_FW_BMAP KVM_REG_ARM_FW_REG(0xff00)
+#define KVM_REG_ARM_FW_BMAP_REG(r) (KVM_REG_ARM_FW_BMAP | (r))
+
+#define KVM_REG_ARM_STD_BMAP KVM_REG_ARM_FW_BMAP_REG(0)
+#define KVM_REG_ARM_STD_BIT_TRNG_V1_0 BIT(0)
+#define KVM_REG_ARM_STD_BMAP_BIT_MAX 0 /* Last valid bit */
+
/* SVE registers */
#define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index f61cd8d57eae..e9f9edb1cf55 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -156,6 +156,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
kvm->arch.max_vcpus = kvm_arm_default_max_vcpus();
set_default_spectre(kvm);
+ kvm_arm_init_hypercalls(kvm);
return ret;
out_free_stage2_pgd:
@@ -635,7 +636,14 @@ int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu)
if (kvm_vm_is_protected(kvm))
kvm_call_hyp_nvhe(__pkvm_vcpu_init_traps, vcpu);
+ /*
+ * Grab kvm->lock such that the reader of has_run_once can finish
+ * the necessary operation atomically, such as deciding whether to
+ * block the writes to the firmware registers if the VM has run once.
+ */
+ mutex_lock(&kvm->lock);
kvm->arch.has_run_once = true;
+ mutex_unlock(&kvm->lock);
return ret;
}
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index eb061e64a7a5..d66e6c742bbe 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -65,6 +65,7 @@ const struct kvm_stats_header kvm_vcpu_stats_header = {
static const u64 kvm_arm_vm_scope_fw_regs[] = {
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
+ KVM_REG_ARM_STD_BMAP,
};
/**
diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
index 8624e6964940..48c126c3da72 100644
--- a/arch/arm64/kvm/hypercalls.c
+++ b/arch/arm64/kvm/hypercalls.c
@@ -58,6 +58,29 @@ static void kvm_ptp_get_time(struct kvm_vcpu *vcpu, u64 *val)
val[3] = lower_32_bits(cycles);
}
+static bool kvm_arm_fw_reg_feat_enabled(u64 reg_bmap, u64 feat_bit)
+{
+ return reg_bmap & feat_bit;
+}
+
+static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
+{
+ struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
+
+ switch (func_id) {
+ case ARM_SMCCC_TRNG_VERSION:
+ case ARM_SMCCC_TRNG_FEATURES:
+ case ARM_SMCCC_TRNG_GET_UUID:
+ case ARM_SMCCC_TRNG_RND32:
+ case ARM_SMCCC_TRNG_RND64:
+ return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_bmap,
+ KVM_REG_ARM_STD_BIT_TRNG_V1_0);
+ default:
+ /* By default, allow the services that aren't listed here */
+ return true;
+ }
+}
+
int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
{
u32 func_id = smccc_get_function(vcpu);
@@ -65,6 +88,9 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
u32 feature;
gpa_t gpa;
+ if (!kvm_hvc_call_supported(vcpu, func_id))
+ goto out;
+
switch (func_id) {
case ARM_SMCCC_VERSION_FUNC_ID:
val[0] = ARM_SMCCC_VERSION_1_1;
@@ -143,6 +169,7 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
return kvm_psci_call(vcpu);
}
+out:
smccc_set_retval(vcpu, val[0], val[1], val[2], val[3]);
return 1;
}
@@ -151,8 +178,16 @@ static const u64 kvm_arm_fw_reg_ids[] = {
KVM_REG_ARM_PSCI_VERSION,
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
+ KVM_REG_ARM_STD_BMAP,
};
+void kvm_arm_init_hypercalls(struct kvm *kvm)
+{
+ struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
+
+ hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
+}
+
int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
{
return ARRAY_SIZE(kvm_arm_fw_reg_ids);
@@ -220,6 +255,7 @@ static int get_kernel_wa_level(u64 regid)
int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
{
+ struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
void __user *uaddr = (void __user *)(long)reg->addr;
u64 val, reg_id = reg->id;
@@ -233,6 +269,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
val = get_kernel_wa_level(reg_id) & KVM_REG_FEATURE_LEVEL_MASK;
break;
+ case KVM_REG_ARM_STD_BMAP:
+ val = READ_ONCE(hvc_desc->hvc_std_bmap);
+ break;
default:
return -ENOENT;
}
@@ -243,6 +282,43 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
return 0;
}
+static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
+{
+ int ret = 0;
+ struct kvm *kvm = vcpu->kvm;
+ struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
+ u64 *fw_reg_bmap, fw_reg_features;
+
+ switch (reg_id) {
+ case KVM_REG_ARM_STD_BMAP:
+ fw_reg_bmap = &hvc_desc->hvc_std_bmap;
+ fw_reg_features = ARM_SMCCC_STD_FEATURES;
+ break;
+ default:
+ return -ENOENT;
+ }
+
+ /* Check for unsupported bit */
+ if (val & ~fw_reg_features)
+ return -EINVAL;
+
+ mutex_lock(&kvm->lock);
+
+ /*
+ * If the VM (any vCPU) has already started running, return success
+ * if there's no change in the value. Else, return -EBUSY.
+ */
+ if (kvm_arm_vm_has_run_once(&kvm->arch)) {
+ ret = *fw_reg_bmap != val ? -EBUSY : 0;
+ goto out;
+ }
+
+ WRITE_ONCE(*fw_reg_bmap, val);
+out:
+ mutex_unlock(&kvm->lock);
+ return ret;
+}
+
int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
{
void __user *uaddr = (void __user *)(long)reg->addr;
@@ -321,6 +397,8 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
return -EINVAL;
return 0;
+ case KVM_REG_ARM_STD_BMAP:
+ return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
default:
return -ENOENT;
}
diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
index 5d38628a8d04..64d30b452809 100644
--- a/include/kvm/arm_hypercalls.h
+++ b/include/kvm/arm_hypercalls.h
@@ -6,6 +6,9 @@
#include <asm/kvm_emulate.h>
+#define ARM_SMCCC_STD_FEATURES \
+ GENMASK_ULL(KVM_REG_ARM_STD_BMAP_BIT_MAX, 0)
+
int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
@@ -42,6 +45,7 @@ static inline void smccc_set_retval(struct kvm_vcpu *vcpu,
struct kvm_one_reg;
+void kvm_arm_init_hypercalls(struct kvm *kvm);
int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
--
2.35.1.473.g83b2b277ed-goog
^ permalink raw reply related [flat|nested] 117+ messages in thread* [PATCH v4 05/13] KVM: arm64: Setup a framework for hypercall bitmap firmware registers
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: Paolo Bonzini, Catalin Marinas, Will Deacon, Peter Shier,
Ricardo Koller, Oliver Upton, Reiji Watanabe, Jing Zhang,
Raghavendra Rao Anata, linux-arm-kernel, kvmarm, linux-kernel,
kvm
KVM regularly introduces new hypercall services to the guests without
any consent from the userspace. This means, the guests can observe
hypercall services in and out as they migrate across various host
kernel versions. This could be a major problem if the guest
discovered a hypercall, started using it, and after getting migrated
to an older kernel realizes that it's no longer available. Depending
on how the guest handles the change, there's a potential chance that
the guest would just panic.
As a result, there's a need for the userspace to elect the services
that it wishes the guest to discover. It can elect these services
based on the kernels spread across its (migration) fleet. To remedy
this, extend the existing firmware psuedo-registers, such as
KVM_REG_ARM_PSCI_VERSION, for all the hypercall services available.
These firmware registers are categorized based on the service call
owners, and unlike the existing firmware psuedo-registers, they hold
the features supported in the form of a bitmap.
During the VM initialization, the registers holds an upper-limit of
the features supported by the corresponding registers. It's expected
that the VMMs discover the features provided by each register via
GET_ONE_REG, and writeback the desired values using SET_ONE_REG.
KVM allows this modification only until the VM has started.
Older userspace code can simply ignore the capability and the
hypercall services will be exposed unconditionally to the guests, thus
ensuring backward compatibility.
In this patch, the framework adds the register only for ARM's standard
secure services (owner value 4). Currently, this includes support only
for ARM True Random Number Generator (TRNG) service, with bit-0 of the
register representing mandatory features of v1.0. The register is also
added to the kvm_arm_vm_scope_fw_regs[] list as it maintains its state
per-VM. Other services are momentarily added in the upcoming patches.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
arch/arm64/include/asm/kvm_host.h | 12 +++++
arch/arm64/include/uapi/asm/kvm.h | 8 ++++
arch/arm64/kvm/arm.c | 8 ++++
arch/arm64/kvm/guest.c | 1 +
arch/arm64/kvm/hypercalls.c | 78 +++++++++++++++++++++++++++++++
include/kvm/arm_hypercalls.h | 4 ++
6 files changed, 111 insertions(+)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index e823571e50cc..1909ced3208f 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -101,6 +101,15 @@ struct kvm_s2_mmu {
struct kvm_arch_memory_slot {
};
+/**
+ * struct kvm_hvc_desc: KVM ARM64 hypercall descriptor
+ *
+ * @hvc_std_bmap: Bitmap of standard secure service calls
+ */
+struct kvm_hvc_desc {
+ u64 hvc_std_bmap;
+};
+
struct kvm_arch {
struct kvm_s2_mmu mmu;
@@ -142,6 +151,9 @@ struct kvm_arch {
/* Capture first run of the VM */
bool has_run_once;
+
+ /* Hypercall firmware register' descriptor */
+ struct kvm_hvc_desc hvc_desc;
};
struct kvm_vcpu_fault_info {
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index c35447cc0e0c..2decc30d6b84 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -287,6 +287,14 @@ struct kvm_arm_copy_mte_tags {
#define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED 3
#define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED (1U << 4)
+/* Bitmap firmware registers, extension to the existing psuedo-register space */
+#define KVM_REG_ARM_FW_BMAP KVM_REG_ARM_FW_REG(0xff00)
+#define KVM_REG_ARM_FW_BMAP_REG(r) (KVM_REG_ARM_FW_BMAP | (r))
+
+#define KVM_REG_ARM_STD_BMAP KVM_REG_ARM_FW_BMAP_REG(0)
+#define KVM_REG_ARM_STD_BIT_TRNG_V1_0 BIT(0)
+#define KVM_REG_ARM_STD_BMAP_BIT_MAX 0 /* Last valid bit */
+
/* SVE registers */
#define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index f61cd8d57eae..e9f9edb1cf55 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -156,6 +156,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
kvm->arch.max_vcpus = kvm_arm_default_max_vcpus();
set_default_spectre(kvm);
+ kvm_arm_init_hypercalls(kvm);
return ret;
out_free_stage2_pgd:
@@ -635,7 +636,14 @@ int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu)
if (kvm_vm_is_protected(kvm))
kvm_call_hyp_nvhe(__pkvm_vcpu_init_traps, vcpu);
+ /*
+ * Grab kvm->lock such that the reader of has_run_once can finish
+ * the necessary operation atomically, such as deciding whether to
+ * block the writes to the firmware registers if the VM has run once.
+ */
+ mutex_lock(&kvm->lock);
kvm->arch.has_run_once = true;
+ mutex_unlock(&kvm->lock);
return ret;
}
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index eb061e64a7a5..d66e6c742bbe 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -65,6 +65,7 @@ const struct kvm_stats_header kvm_vcpu_stats_header = {
static const u64 kvm_arm_vm_scope_fw_regs[] = {
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
+ KVM_REG_ARM_STD_BMAP,
};
/**
diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
index 8624e6964940..48c126c3da72 100644
--- a/arch/arm64/kvm/hypercalls.c
+++ b/arch/arm64/kvm/hypercalls.c
@@ -58,6 +58,29 @@ static void kvm_ptp_get_time(struct kvm_vcpu *vcpu, u64 *val)
val[3] = lower_32_bits(cycles);
}
+static bool kvm_arm_fw_reg_feat_enabled(u64 reg_bmap, u64 feat_bit)
+{
+ return reg_bmap & feat_bit;
+}
+
+static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
+{
+ struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
+
+ switch (func_id) {
+ case ARM_SMCCC_TRNG_VERSION:
+ case ARM_SMCCC_TRNG_FEATURES:
+ case ARM_SMCCC_TRNG_GET_UUID:
+ case ARM_SMCCC_TRNG_RND32:
+ case ARM_SMCCC_TRNG_RND64:
+ return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_bmap,
+ KVM_REG_ARM_STD_BIT_TRNG_V1_0);
+ default:
+ /* By default, allow the services that aren't listed here */
+ return true;
+ }
+}
+
int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
{
u32 func_id = smccc_get_function(vcpu);
@@ -65,6 +88,9 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
u32 feature;
gpa_t gpa;
+ if (!kvm_hvc_call_supported(vcpu, func_id))
+ goto out;
+
switch (func_id) {
case ARM_SMCCC_VERSION_FUNC_ID:
val[0] = ARM_SMCCC_VERSION_1_1;
@@ -143,6 +169,7 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
return kvm_psci_call(vcpu);
}
+out:
smccc_set_retval(vcpu, val[0], val[1], val[2], val[3]);
return 1;
}
@@ -151,8 +178,16 @@ static const u64 kvm_arm_fw_reg_ids[] = {
KVM_REG_ARM_PSCI_VERSION,
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
+ KVM_REG_ARM_STD_BMAP,
};
+void kvm_arm_init_hypercalls(struct kvm *kvm)
+{
+ struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
+
+ hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
+}
+
int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
{
return ARRAY_SIZE(kvm_arm_fw_reg_ids);
@@ -220,6 +255,7 @@ static int get_kernel_wa_level(u64 regid)
int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
{
+ struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
void __user *uaddr = (void __user *)(long)reg->addr;
u64 val, reg_id = reg->id;
@@ -233,6 +269,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
val = get_kernel_wa_level(reg_id) & KVM_REG_FEATURE_LEVEL_MASK;
break;
+ case KVM_REG_ARM_STD_BMAP:
+ val = READ_ONCE(hvc_desc->hvc_std_bmap);
+ break;
default:
return -ENOENT;
}
@@ -243,6 +282,43 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
return 0;
}
+static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
+{
+ int ret = 0;
+ struct kvm *kvm = vcpu->kvm;
+ struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
+ u64 *fw_reg_bmap, fw_reg_features;
+
+ switch (reg_id) {
+ case KVM_REG_ARM_STD_BMAP:
+ fw_reg_bmap = &hvc_desc->hvc_std_bmap;
+ fw_reg_features = ARM_SMCCC_STD_FEATURES;
+ break;
+ default:
+ return -ENOENT;
+ }
+
+ /* Check for unsupported bit */
+ if (val & ~fw_reg_features)
+ return -EINVAL;
+
+ mutex_lock(&kvm->lock);
+
+ /*
+ * If the VM (any vCPU) has already started running, return success
+ * if there's no change in the value. Else, return -EBUSY.
+ */
+ if (kvm_arm_vm_has_run_once(&kvm->arch)) {
+ ret = *fw_reg_bmap != val ? -EBUSY : 0;
+ goto out;
+ }
+
+ WRITE_ONCE(*fw_reg_bmap, val);
+out:
+ mutex_unlock(&kvm->lock);
+ return ret;
+}
+
int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
{
void __user *uaddr = (void __user *)(long)reg->addr;
@@ -321,6 +397,8 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
return -EINVAL;
return 0;
+ case KVM_REG_ARM_STD_BMAP:
+ return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
default:
return -ENOENT;
}
diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
index 5d38628a8d04..64d30b452809 100644
--- a/include/kvm/arm_hypercalls.h
+++ b/include/kvm/arm_hypercalls.h
@@ -6,6 +6,9 @@
#include <asm/kvm_emulate.h>
+#define ARM_SMCCC_STD_FEATURES \
+ GENMASK_ULL(KVM_REG_ARM_STD_BMAP_BIT_MAX, 0)
+
int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
@@ -42,6 +45,7 @@ static inline void smccc_set_retval(struct kvm_vcpu *vcpu,
struct kvm_one_reg;
+void kvm_arm_init_hypercalls(struct kvm *kvm);
int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
--
2.35.1.473.g83b2b277ed-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 117+ messages in thread* Re: [PATCH v4 05/13] KVM: arm64: Setup a framework for hypercall bitmap firmware registers
2022-02-24 17:25 ` Raghavendra Rao Ananta
(?)
@ 2022-03-14 19:41 ` Oliver Upton
-1 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-14 19:41 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: kvm, Will Deacon, Marc Zyngier, Peter Shier, linux-kernel,
Catalin Marinas, Paolo Bonzini, kvmarm, linux-arm-kernel
On Thu, Feb 24, 2022 at 05:25:51PM +0000, Raghavendra Rao Ananta wrote:
> KVM regularly introduces new hypercall services to the guests without
> any consent from the userspace. This means, the guests can observe
> hypercall services in and out as they migrate across various host
> kernel versions. This could be a major problem if the guest
> discovered a hypercall, started using it, and after getting migrated
> to an older kernel realizes that it's no longer available. Depending
> on how the guest handles the change, there's a potential chance that
> the guest would just panic.
>
> As a result, there's a need for the userspace to elect the services
> that it wishes the guest to discover. It can elect these services
> based on the kernels spread across its (migration) fleet. To remedy
> this, extend the existing firmware psuedo-registers, such as
> KVM_REG_ARM_PSCI_VERSION, for all the hypercall services available.
>
> These firmware registers are categorized based on the service call
> owners, and unlike the existing firmware psuedo-registers, they hold
> the features supported in the form of a bitmap.
>
> During the VM initialization, the registers holds an upper-limit of
> the features supported by the corresponding registers. It's expected
> that the VMMs discover the features provided by each register via
> GET_ONE_REG, and writeback the desired values using SET_ONE_REG.
> KVM allows this modification only until the VM has started.
>
> Older userspace code can simply ignore the capability and the
> hypercall services will be exposed unconditionally to the guests, thus
> ensuring backward compatibility.
>
> In this patch, the framework adds the register only for ARM's standard
> secure services (owner value 4). Currently, this includes support only
> for ARM True Random Number Generator (TRNG) service, with bit-0 of the
> register representing mandatory features of v1.0. The register is also
> added to the kvm_arm_vm_scope_fw_regs[] list as it maintains its state
> per-VM. Other services are momentarily added in the upcoming patches.
>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> ---
> arch/arm64/include/asm/kvm_host.h | 12 +++++
> arch/arm64/include/uapi/asm/kvm.h | 8 ++++
> arch/arm64/kvm/arm.c | 8 ++++
> arch/arm64/kvm/guest.c | 1 +
> arch/arm64/kvm/hypercalls.c | 78 +++++++++++++++++++++++++++++++
> include/kvm/arm_hypercalls.h | 4 ++
> 6 files changed, 111 insertions(+)
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index e823571e50cc..1909ced3208f 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -101,6 +101,15 @@ struct kvm_s2_mmu {
> struct kvm_arch_memory_slot {
> };
>
> +/**
> + * struct kvm_hvc_desc: KVM ARM64 hypercall descriptor
> + *
> + * @hvc_std_bmap: Bitmap of standard secure service calls
> + */
> +struct kvm_hvc_desc {
nit: maybe call this structure kvm_hypercall_features? When nested comes
along guests will need to use the SVC conduit as HVC traps are always
taken to EL2. Same will need to be true for virtual EL2.
> + u64 hvc_std_bmap;
> +};
> +
> struct kvm_arch {
> struct kvm_s2_mmu mmu;
>
> @@ -142,6 +151,9 @@ struct kvm_arch {
>
> /* Capture first run of the VM */
> bool has_run_once;
> +
> + /* Hypercall firmware register' descriptor */
> + struct kvm_hvc_desc hvc_desc;
> };
>
> struct kvm_vcpu_fault_info {
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index c35447cc0e0c..2decc30d6b84 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -287,6 +287,14 @@ struct kvm_arm_copy_mte_tags {
> #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED 3
> #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED (1U << 4)
>
> +/* Bitmap firmware registers, extension to the existing psuedo-register space */
> +#define KVM_REG_ARM_FW_BMAP KVM_REG_ARM_FW_REG(0xff00)
What is the motivation for moving the bitmap register indices so far
away from the rest of the firmware regs?
> +#define KVM_REG_ARM_FW_BMAP_REG(r) (KVM_REG_ARM_FW_BMAP | (r))
If you are still going to use the index offset, just pass 'r' through to
the other macro:
#define KVM_REG_ARM_FW_BMAP_REG(r) KVM_REG_ARM_FW_REG(0xff00 + r)
> +#define KVM_REG_ARM_STD_BMAP KVM_REG_ARM_FW_BMAP_REG(0)
> +#define KVM_REG_ARM_STD_BIT_TRNG_V1_0 BIT(0)
> +#define KVM_REG_ARM_STD_BMAP_BIT_MAX 0 /* Last valid bit */
Implementation details such as this probably shouldn't live in UAPI
headers. We'll likely need to bump the value in the future.
> +
> /* SVE registers */
> #define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
>
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index f61cd8d57eae..e9f9edb1cf55 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -156,6 +156,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> kvm->arch.max_vcpus = kvm_arm_default_max_vcpus();
>
> set_default_spectre(kvm);
> + kvm_arm_init_hypercalls(kvm);
>
> return ret;
> out_free_stage2_pgd:
> @@ -635,7 +636,14 @@ int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu)
> if (kvm_vm_is_protected(kvm))
> kvm_call_hyp_nvhe(__pkvm_vcpu_init_traps, vcpu);
>
> + /*
> + * Grab kvm->lock such that the reader of has_run_once can finish
> + * the necessary operation atomically, such as deciding whether to
> + * block the writes to the firmware registers if the VM has run once.
> + */
> + mutex_lock(&kvm->lock);
> kvm->arch.has_run_once = true;
> + mutex_unlock(&kvm->lock);
Shouldn't this have just grabbed the kvm lock in patch 04/13?
> return ret;
> }
> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> index eb061e64a7a5..d66e6c742bbe 100644
> --- a/arch/arm64/kvm/guest.c
> +++ b/arch/arm64/kvm/guest.c
> @@ -65,6 +65,7 @@ const struct kvm_stats_header kvm_vcpu_stats_header = {
> static const u64 kvm_arm_vm_scope_fw_regs[] = {
> KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> + KVM_REG_ARM_STD_BMAP,
> };
>
> /**
> diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> index 8624e6964940..48c126c3da72 100644
> --- a/arch/arm64/kvm/hypercalls.c
> +++ b/arch/arm64/kvm/hypercalls.c
> @@ -58,6 +58,29 @@ static void kvm_ptp_get_time(struct kvm_vcpu *vcpu, u64 *val)
> val[3] = lower_32_bits(cycles);
> }
>
> +static bool kvm_arm_fw_reg_feat_enabled(u64 reg_bmap, u64 feat_bit)
> +{
> + return reg_bmap & feat_bit;
> +}
> +
> +static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> +{
> + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> +
> + switch (func_id) {
> + case ARM_SMCCC_TRNG_VERSION:
> + case ARM_SMCCC_TRNG_FEATURES:
> + case ARM_SMCCC_TRNG_GET_UUID:
> + case ARM_SMCCC_TRNG_RND32:
> + case ARM_SMCCC_TRNG_RND64:
> + return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_bmap,
> + KVM_REG_ARM_STD_BIT_TRNG_V1_0);
> + default:
> + /* By default, allow the services that aren't listed here */
> + return true;
I think your default case should really return false. It keeps people
honest when they add new patches to set up a new hypercall bit (no bit?
no call!)
That of course requires that you only return false once all of the
preexisting hypercalls are enumerated, otherwise such a patch would
cause a regression in isolation.
> + }
> +}
> +
> int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> {
> u32 func_id = smccc_get_function(vcpu);
> @@ -65,6 +88,9 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> u32 feature;
> gpa_t gpa;
>
> + if (!kvm_hvc_call_supported(vcpu, func_id))
> + goto out;
> +
> switch (func_id) {
> case ARM_SMCCC_VERSION_FUNC_ID:
> val[0] = ARM_SMCCC_VERSION_1_1;
> @@ -143,6 +169,7 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> return kvm_psci_call(vcpu);
> }
>
> +out:
> smccc_set_retval(vcpu, val[0], val[1], val[2], val[3]);
> return 1;
> }
> @@ -151,8 +178,16 @@ static const u64 kvm_arm_fw_reg_ids[] = {
> KVM_REG_ARM_PSCI_VERSION,
> KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> + KVM_REG_ARM_STD_BMAP,
> };
>
> +void kvm_arm_init_hypercalls(struct kvm *kvm)
> +{
> + struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
> +
> + hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
> +}
> +
> int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> {
> return ARRAY_SIZE(kvm_arm_fw_reg_ids);
> @@ -220,6 +255,7 @@ static int get_kernel_wa_level(u64 regid)
>
> int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> {
> + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> void __user *uaddr = (void __user *)(long)reg->addr;
> u64 val, reg_id = reg->id;
>
> @@ -233,6 +269,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> val = get_kernel_wa_level(reg_id) & KVM_REG_FEATURE_LEVEL_MASK;
> break;
> + case KVM_REG_ARM_STD_BMAP:
> + val = READ_ONCE(hvc_desc->hvc_std_bmap);
> + break;
> default:
> return -ENOENT;
> }
> @@ -243,6 +282,43 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> return 0;
> }
>
> +static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
> +{
> + int ret = 0;
> + struct kvm *kvm = vcpu->kvm;
> + struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
> + u64 *fw_reg_bmap, fw_reg_features;
nit: use reverse fir tree ordering for locals (longest line first,
shortest last).
> + switch (reg_id) {
> + case KVM_REG_ARM_STD_BMAP:
> + fw_reg_bmap = &hvc_desc->hvc_std_bmap;
> + fw_reg_features = ARM_SMCCC_STD_FEATURES;
> + break;
> + default:
> + return -ENOENT;
> + }
> +
> + /* Check for unsupported bit */
> + if (val & ~fw_reg_features)
> + return -EINVAL;
> +
> + mutex_lock(&kvm->lock);
> +
> + /*
> + * If the VM (any vCPU) has already started running, return success
> + * if there's no change in the value. Else, return -EBUSY.
How about returning -EINVAL instead? We already do this for
KVM_ARM_VCPU_INIT if userspace uses a different target than the one
previously set.
> + */
> + if (kvm_arm_vm_has_run_once(&kvm->arch)) {
> + ret = *fw_reg_bmap != val ? -EBUSY : 0;
> + goto out;
> + }
> +
> + WRITE_ONCE(*fw_reg_bmap, val);
> +out:
> + mutex_unlock(&kvm->lock);
> + return ret;
> +}
> +
> int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> {
> void __user *uaddr = (void __user *)(long)reg->addr;
> @@ -321,6 +397,8 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> return -EINVAL;
>
> return 0;
> + case KVM_REG_ARM_STD_BMAP:
> + return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
> default:
> return -ENOENT;
> }
> diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> index 5d38628a8d04..64d30b452809 100644
> --- a/include/kvm/arm_hypercalls.h
> +++ b/include/kvm/arm_hypercalls.h
> @@ -6,6 +6,9 @@
>
> #include <asm/kvm_emulate.h>
>
> +#define ARM_SMCCC_STD_FEATURES \
> + GENMASK_ULL(KVM_REG_ARM_STD_BMAP_BIT_MAX, 0)
> +
This probably needs KVM_ somewhere in its name for the sake of scoping.
> int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
>
> static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
> @@ -42,6 +45,7 @@ static inline void smccc_set_retval(struct kvm_vcpu *vcpu,
>
> struct kvm_one_reg;
>
> +void kvm_arm_init_hypercalls(struct kvm *kvm);
> int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
> int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
> int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> --
> 2.35.1.473.g83b2b277ed-goog
>
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 05/13] KVM: arm64: Setup a framework for hypercall bitmap firmware registers
@ 2022-03-14 19:41 ` Oliver Upton
0 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-14 19:41 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Thu, Feb 24, 2022 at 05:25:51PM +0000, Raghavendra Rao Ananta wrote:
> KVM regularly introduces new hypercall services to the guests without
> any consent from the userspace. This means, the guests can observe
> hypercall services in and out as they migrate across various host
> kernel versions. This could be a major problem if the guest
> discovered a hypercall, started using it, and after getting migrated
> to an older kernel realizes that it's no longer available. Depending
> on how the guest handles the change, there's a potential chance that
> the guest would just panic.
>
> As a result, there's a need for the userspace to elect the services
> that it wishes the guest to discover. It can elect these services
> based on the kernels spread across its (migration) fleet. To remedy
> this, extend the existing firmware psuedo-registers, such as
> KVM_REG_ARM_PSCI_VERSION, for all the hypercall services available.
>
> These firmware registers are categorized based on the service call
> owners, and unlike the existing firmware psuedo-registers, they hold
> the features supported in the form of a bitmap.
>
> During the VM initialization, the registers holds an upper-limit of
> the features supported by the corresponding registers. It's expected
> that the VMMs discover the features provided by each register via
> GET_ONE_REG, and writeback the desired values using SET_ONE_REG.
> KVM allows this modification only until the VM has started.
>
> Older userspace code can simply ignore the capability and the
> hypercall services will be exposed unconditionally to the guests, thus
> ensuring backward compatibility.
>
> In this patch, the framework adds the register only for ARM's standard
> secure services (owner value 4). Currently, this includes support only
> for ARM True Random Number Generator (TRNG) service, with bit-0 of the
> register representing mandatory features of v1.0. The register is also
> added to the kvm_arm_vm_scope_fw_regs[] list as it maintains its state
> per-VM. Other services are momentarily added in the upcoming patches.
>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> ---
> arch/arm64/include/asm/kvm_host.h | 12 +++++
> arch/arm64/include/uapi/asm/kvm.h | 8 ++++
> arch/arm64/kvm/arm.c | 8 ++++
> arch/arm64/kvm/guest.c | 1 +
> arch/arm64/kvm/hypercalls.c | 78 +++++++++++++++++++++++++++++++
> include/kvm/arm_hypercalls.h | 4 ++
> 6 files changed, 111 insertions(+)
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index e823571e50cc..1909ced3208f 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -101,6 +101,15 @@ struct kvm_s2_mmu {
> struct kvm_arch_memory_slot {
> };
>
> +/**
> + * struct kvm_hvc_desc: KVM ARM64 hypercall descriptor
> + *
> + * @hvc_std_bmap: Bitmap of standard secure service calls
> + */
> +struct kvm_hvc_desc {
nit: maybe call this structure kvm_hypercall_features? When nested comes
along guests will need to use the SVC conduit as HVC traps are always
taken to EL2. Same will need to be true for virtual EL2.
> + u64 hvc_std_bmap;
> +};
> +
> struct kvm_arch {
> struct kvm_s2_mmu mmu;
>
> @@ -142,6 +151,9 @@ struct kvm_arch {
>
> /* Capture first run of the VM */
> bool has_run_once;
> +
> + /* Hypercall firmware register' descriptor */
> + struct kvm_hvc_desc hvc_desc;
> };
>
> struct kvm_vcpu_fault_info {
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index c35447cc0e0c..2decc30d6b84 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -287,6 +287,14 @@ struct kvm_arm_copy_mte_tags {
> #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED 3
> #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED (1U << 4)
>
> +/* Bitmap firmware registers, extension to the existing psuedo-register space */
> +#define KVM_REG_ARM_FW_BMAP KVM_REG_ARM_FW_REG(0xff00)
What is the motivation for moving the bitmap register indices so far
away from the rest of the firmware regs?
> +#define KVM_REG_ARM_FW_BMAP_REG(r) (KVM_REG_ARM_FW_BMAP | (r))
If you are still going to use the index offset, just pass 'r' through to
the other macro:
#define KVM_REG_ARM_FW_BMAP_REG(r) KVM_REG_ARM_FW_REG(0xff00 + r)
> +#define KVM_REG_ARM_STD_BMAP KVM_REG_ARM_FW_BMAP_REG(0)
> +#define KVM_REG_ARM_STD_BIT_TRNG_V1_0 BIT(0)
> +#define KVM_REG_ARM_STD_BMAP_BIT_MAX 0 /* Last valid bit */
Implementation details such as this probably shouldn't live in UAPI
headers. We'll likely need to bump the value in the future.
> +
> /* SVE registers */
> #define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
>
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index f61cd8d57eae..e9f9edb1cf55 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -156,6 +156,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> kvm->arch.max_vcpus = kvm_arm_default_max_vcpus();
>
> set_default_spectre(kvm);
> + kvm_arm_init_hypercalls(kvm);
>
> return ret;
> out_free_stage2_pgd:
> @@ -635,7 +636,14 @@ int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu)
> if (kvm_vm_is_protected(kvm))
> kvm_call_hyp_nvhe(__pkvm_vcpu_init_traps, vcpu);
>
> + /*
> + * Grab kvm->lock such that the reader of has_run_once can finish
> + * the necessary operation atomically, such as deciding whether to
> + * block the writes to the firmware registers if the VM has run once.
> + */
> + mutex_lock(&kvm->lock);
> kvm->arch.has_run_once = true;
> + mutex_unlock(&kvm->lock);
Shouldn't this have just grabbed the kvm lock in patch 04/13?
> return ret;
> }
> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> index eb061e64a7a5..d66e6c742bbe 100644
> --- a/arch/arm64/kvm/guest.c
> +++ b/arch/arm64/kvm/guest.c
> @@ -65,6 +65,7 @@ const struct kvm_stats_header kvm_vcpu_stats_header = {
> static const u64 kvm_arm_vm_scope_fw_regs[] = {
> KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> + KVM_REG_ARM_STD_BMAP,
> };
>
> /**
> diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> index 8624e6964940..48c126c3da72 100644
> --- a/arch/arm64/kvm/hypercalls.c
> +++ b/arch/arm64/kvm/hypercalls.c
> @@ -58,6 +58,29 @@ static void kvm_ptp_get_time(struct kvm_vcpu *vcpu, u64 *val)
> val[3] = lower_32_bits(cycles);
> }
>
> +static bool kvm_arm_fw_reg_feat_enabled(u64 reg_bmap, u64 feat_bit)
> +{
> + return reg_bmap & feat_bit;
> +}
> +
> +static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> +{
> + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> +
> + switch (func_id) {
> + case ARM_SMCCC_TRNG_VERSION:
> + case ARM_SMCCC_TRNG_FEATURES:
> + case ARM_SMCCC_TRNG_GET_UUID:
> + case ARM_SMCCC_TRNG_RND32:
> + case ARM_SMCCC_TRNG_RND64:
> + return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_bmap,
> + KVM_REG_ARM_STD_BIT_TRNG_V1_0);
> + default:
> + /* By default, allow the services that aren't listed here */
> + return true;
I think your default case should really return false. It keeps people
honest when they add new patches to set up a new hypercall bit (no bit?
no call!)
That of course requires that you only return false once all of the
preexisting hypercalls are enumerated, otherwise such a patch would
cause a regression in isolation.
> + }
> +}
> +
> int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> {
> u32 func_id = smccc_get_function(vcpu);
> @@ -65,6 +88,9 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> u32 feature;
> gpa_t gpa;
>
> + if (!kvm_hvc_call_supported(vcpu, func_id))
> + goto out;
> +
> switch (func_id) {
> case ARM_SMCCC_VERSION_FUNC_ID:
> val[0] = ARM_SMCCC_VERSION_1_1;
> @@ -143,6 +169,7 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> return kvm_psci_call(vcpu);
> }
>
> +out:
> smccc_set_retval(vcpu, val[0], val[1], val[2], val[3]);
> return 1;
> }
> @@ -151,8 +178,16 @@ static const u64 kvm_arm_fw_reg_ids[] = {
> KVM_REG_ARM_PSCI_VERSION,
> KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> + KVM_REG_ARM_STD_BMAP,
> };
>
> +void kvm_arm_init_hypercalls(struct kvm *kvm)
> +{
> + struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
> +
> + hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
> +}
> +
> int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> {
> return ARRAY_SIZE(kvm_arm_fw_reg_ids);
> @@ -220,6 +255,7 @@ static int get_kernel_wa_level(u64 regid)
>
> int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> {
> + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> void __user *uaddr = (void __user *)(long)reg->addr;
> u64 val, reg_id = reg->id;
>
> @@ -233,6 +269,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> val = get_kernel_wa_level(reg_id) & KVM_REG_FEATURE_LEVEL_MASK;
> break;
> + case KVM_REG_ARM_STD_BMAP:
> + val = READ_ONCE(hvc_desc->hvc_std_bmap);
> + break;
> default:
> return -ENOENT;
> }
> @@ -243,6 +282,43 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> return 0;
> }
>
> +static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
> +{
> + int ret = 0;
> + struct kvm *kvm = vcpu->kvm;
> + struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
> + u64 *fw_reg_bmap, fw_reg_features;
nit: use reverse fir tree ordering for locals (longest line first,
shortest last).
> + switch (reg_id) {
> + case KVM_REG_ARM_STD_BMAP:
> + fw_reg_bmap = &hvc_desc->hvc_std_bmap;
> + fw_reg_features = ARM_SMCCC_STD_FEATURES;
> + break;
> + default:
> + return -ENOENT;
> + }
> +
> + /* Check for unsupported bit */
> + if (val & ~fw_reg_features)
> + return -EINVAL;
> +
> + mutex_lock(&kvm->lock);
> +
> + /*
> + * If the VM (any vCPU) has already started running, return success
> + * if there's no change in the value. Else, return -EBUSY.
How about returning -EINVAL instead? We already do this for
KVM_ARM_VCPU_INIT if userspace uses a different target than the one
previously set.
> + */
> + if (kvm_arm_vm_has_run_once(&kvm->arch)) {
> + ret = *fw_reg_bmap != val ? -EBUSY : 0;
> + goto out;
> + }
> +
> + WRITE_ONCE(*fw_reg_bmap, val);
> +out:
> + mutex_unlock(&kvm->lock);
> + return ret;
> +}
> +
> int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> {
> void __user *uaddr = (void __user *)(long)reg->addr;
> @@ -321,6 +397,8 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> return -EINVAL;
>
> return 0;
> + case KVM_REG_ARM_STD_BMAP:
> + return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
> default:
> return -ENOENT;
> }
> diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> index 5d38628a8d04..64d30b452809 100644
> --- a/include/kvm/arm_hypercalls.h
> +++ b/include/kvm/arm_hypercalls.h
> @@ -6,6 +6,9 @@
>
> #include <asm/kvm_emulate.h>
>
> +#define ARM_SMCCC_STD_FEATURES \
> + GENMASK_ULL(KVM_REG_ARM_STD_BMAP_BIT_MAX, 0)
> +
This probably needs KVM_ somewhere in its name for the sake of scoping.
> int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
>
> static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
> @@ -42,6 +45,7 @@ static inline void smccc_set_retval(struct kvm_vcpu *vcpu,
>
> struct kvm_one_reg;
>
> +void kvm_arm_init_hypercalls(struct kvm *kvm);
> int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
> int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
> int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> --
> 2.35.1.473.g83b2b277ed-goog
>
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 05/13] KVM: arm64: Setup a framework for hypercall bitmap firmware registers
@ 2022-03-14 19:41 ` Oliver Upton
0 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-14 19:41 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Thu, Feb 24, 2022 at 05:25:51PM +0000, Raghavendra Rao Ananta wrote:
> KVM regularly introduces new hypercall services to the guests without
> any consent from the userspace. This means, the guests can observe
> hypercall services in and out as they migrate across various host
> kernel versions. This could be a major problem if the guest
> discovered a hypercall, started using it, and after getting migrated
> to an older kernel realizes that it's no longer available. Depending
> on how the guest handles the change, there's a potential chance that
> the guest would just panic.
>
> As a result, there's a need for the userspace to elect the services
> that it wishes the guest to discover. It can elect these services
> based on the kernels spread across its (migration) fleet. To remedy
> this, extend the existing firmware psuedo-registers, such as
> KVM_REG_ARM_PSCI_VERSION, for all the hypercall services available.
>
> These firmware registers are categorized based on the service call
> owners, and unlike the existing firmware psuedo-registers, they hold
> the features supported in the form of a bitmap.
>
> During the VM initialization, the registers holds an upper-limit of
> the features supported by the corresponding registers. It's expected
> that the VMMs discover the features provided by each register via
> GET_ONE_REG, and writeback the desired values using SET_ONE_REG.
> KVM allows this modification only until the VM has started.
>
> Older userspace code can simply ignore the capability and the
> hypercall services will be exposed unconditionally to the guests, thus
> ensuring backward compatibility.
>
> In this patch, the framework adds the register only for ARM's standard
> secure services (owner value 4). Currently, this includes support only
> for ARM True Random Number Generator (TRNG) service, with bit-0 of the
> register representing mandatory features of v1.0. The register is also
> added to the kvm_arm_vm_scope_fw_regs[] list as it maintains its state
> per-VM. Other services are momentarily added in the upcoming patches.
>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> ---
> arch/arm64/include/asm/kvm_host.h | 12 +++++
> arch/arm64/include/uapi/asm/kvm.h | 8 ++++
> arch/arm64/kvm/arm.c | 8 ++++
> arch/arm64/kvm/guest.c | 1 +
> arch/arm64/kvm/hypercalls.c | 78 +++++++++++++++++++++++++++++++
> include/kvm/arm_hypercalls.h | 4 ++
> 6 files changed, 111 insertions(+)
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index e823571e50cc..1909ced3208f 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -101,6 +101,15 @@ struct kvm_s2_mmu {
> struct kvm_arch_memory_slot {
> };
>
> +/**
> + * struct kvm_hvc_desc: KVM ARM64 hypercall descriptor
> + *
> + * @hvc_std_bmap: Bitmap of standard secure service calls
> + */
> +struct kvm_hvc_desc {
nit: maybe call this structure kvm_hypercall_features? When nested comes
along guests will need to use the SVC conduit as HVC traps are always
taken to EL2. Same will need to be true for virtual EL2.
> + u64 hvc_std_bmap;
> +};
> +
> struct kvm_arch {
> struct kvm_s2_mmu mmu;
>
> @@ -142,6 +151,9 @@ struct kvm_arch {
>
> /* Capture first run of the VM */
> bool has_run_once;
> +
> + /* Hypercall firmware register' descriptor */
> + struct kvm_hvc_desc hvc_desc;
> };
>
> struct kvm_vcpu_fault_info {
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index c35447cc0e0c..2decc30d6b84 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -287,6 +287,14 @@ struct kvm_arm_copy_mte_tags {
> #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED 3
> #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED (1U << 4)
>
> +/* Bitmap firmware registers, extension to the existing psuedo-register space */
> +#define KVM_REG_ARM_FW_BMAP KVM_REG_ARM_FW_REG(0xff00)
What is the motivation for moving the bitmap register indices so far
away from the rest of the firmware regs?
> +#define KVM_REG_ARM_FW_BMAP_REG(r) (KVM_REG_ARM_FW_BMAP | (r))
If you are still going to use the index offset, just pass 'r' through to
the other macro:
#define KVM_REG_ARM_FW_BMAP_REG(r) KVM_REG_ARM_FW_REG(0xff00 + r)
> +#define KVM_REG_ARM_STD_BMAP KVM_REG_ARM_FW_BMAP_REG(0)
> +#define KVM_REG_ARM_STD_BIT_TRNG_V1_0 BIT(0)
> +#define KVM_REG_ARM_STD_BMAP_BIT_MAX 0 /* Last valid bit */
Implementation details such as this probably shouldn't live in UAPI
headers. We'll likely need to bump the value in the future.
> +
> /* SVE registers */
> #define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
>
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index f61cd8d57eae..e9f9edb1cf55 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -156,6 +156,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> kvm->arch.max_vcpus = kvm_arm_default_max_vcpus();
>
> set_default_spectre(kvm);
> + kvm_arm_init_hypercalls(kvm);
>
> return ret;
> out_free_stage2_pgd:
> @@ -635,7 +636,14 @@ int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu)
> if (kvm_vm_is_protected(kvm))
> kvm_call_hyp_nvhe(__pkvm_vcpu_init_traps, vcpu);
>
> + /*
> + * Grab kvm->lock such that the reader of has_run_once can finish
> + * the necessary operation atomically, such as deciding whether to
> + * block the writes to the firmware registers if the VM has run once.
> + */
> + mutex_lock(&kvm->lock);
> kvm->arch.has_run_once = true;
> + mutex_unlock(&kvm->lock);
Shouldn't this have just grabbed the kvm lock in patch 04/13?
> return ret;
> }
> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> index eb061e64a7a5..d66e6c742bbe 100644
> --- a/arch/arm64/kvm/guest.c
> +++ b/arch/arm64/kvm/guest.c
> @@ -65,6 +65,7 @@ const struct kvm_stats_header kvm_vcpu_stats_header = {
> static const u64 kvm_arm_vm_scope_fw_regs[] = {
> KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> + KVM_REG_ARM_STD_BMAP,
> };
>
> /**
> diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> index 8624e6964940..48c126c3da72 100644
> --- a/arch/arm64/kvm/hypercalls.c
> +++ b/arch/arm64/kvm/hypercalls.c
> @@ -58,6 +58,29 @@ static void kvm_ptp_get_time(struct kvm_vcpu *vcpu, u64 *val)
> val[3] = lower_32_bits(cycles);
> }
>
> +static bool kvm_arm_fw_reg_feat_enabled(u64 reg_bmap, u64 feat_bit)
> +{
> + return reg_bmap & feat_bit;
> +}
> +
> +static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> +{
> + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> +
> + switch (func_id) {
> + case ARM_SMCCC_TRNG_VERSION:
> + case ARM_SMCCC_TRNG_FEATURES:
> + case ARM_SMCCC_TRNG_GET_UUID:
> + case ARM_SMCCC_TRNG_RND32:
> + case ARM_SMCCC_TRNG_RND64:
> + return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_bmap,
> + KVM_REG_ARM_STD_BIT_TRNG_V1_0);
> + default:
> + /* By default, allow the services that aren't listed here */
> + return true;
I think your default case should really return false. It keeps people
honest when they add new patches to set up a new hypercall bit (no bit?
no call!)
That of course requires that you only return false once all of the
preexisting hypercalls are enumerated, otherwise such a patch would
cause a regression in isolation.
> + }
> +}
> +
> int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> {
> u32 func_id = smccc_get_function(vcpu);
> @@ -65,6 +88,9 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> u32 feature;
> gpa_t gpa;
>
> + if (!kvm_hvc_call_supported(vcpu, func_id))
> + goto out;
> +
> switch (func_id) {
> case ARM_SMCCC_VERSION_FUNC_ID:
> val[0] = ARM_SMCCC_VERSION_1_1;
> @@ -143,6 +169,7 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> return kvm_psci_call(vcpu);
> }
>
> +out:
> smccc_set_retval(vcpu, val[0], val[1], val[2], val[3]);
> return 1;
> }
> @@ -151,8 +178,16 @@ static const u64 kvm_arm_fw_reg_ids[] = {
> KVM_REG_ARM_PSCI_VERSION,
> KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> + KVM_REG_ARM_STD_BMAP,
> };
>
> +void kvm_arm_init_hypercalls(struct kvm *kvm)
> +{
> + struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
> +
> + hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
> +}
> +
> int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> {
> return ARRAY_SIZE(kvm_arm_fw_reg_ids);
> @@ -220,6 +255,7 @@ static int get_kernel_wa_level(u64 regid)
>
> int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> {
> + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> void __user *uaddr = (void __user *)(long)reg->addr;
> u64 val, reg_id = reg->id;
>
> @@ -233,6 +269,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> val = get_kernel_wa_level(reg_id) & KVM_REG_FEATURE_LEVEL_MASK;
> break;
> + case KVM_REG_ARM_STD_BMAP:
> + val = READ_ONCE(hvc_desc->hvc_std_bmap);
> + break;
> default:
> return -ENOENT;
> }
> @@ -243,6 +282,43 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> return 0;
> }
>
> +static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
> +{
> + int ret = 0;
> + struct kvm *kvm = vcpu->kvm;
> + struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
> + u64 *fw_reg_bmap, fw_reg_features;
nit: use reverse fir tree ordering for locals (longest line first,
shortest last).
> + switch (reg_id) {
> + case KVM_REG_ARM_STD_BMAP:
> + fw_reg_bmap = &hvc_desc->hvc_std_bmap;
> + fw_reg_features = ARM_SMCCC_STD_FEATURES;
> + break;
> + default:
> + return -ENOENT;
> + }
> +
> + /* Check for unsupported bit */
> + if (val & ~fw_reg_features)
> + return -EINVAL;
> +
> + mutex_lock(&kvm->lock);
> +
> + /*
> + * If the VM (any vCPU) has already started running, return success
> + * if there's no change in the value. Else, return -EBUSY.
How about returning -EINVAL instead? We already do this for
KVM_ARM_VCPU_INIT if userspace uses a different target than the one
previously set.
> + */
> + if (kvm_arm_vm_has_run_once(&kvm->arch)) {
> + ret = *fw_reg_bmap != val ? -EBUSY : 0;
> + goto out;
> + }
> +
> + WRITE_ONCE(*fw_reg_bmap, val);
> +out:
> + mutex_unlock(&kvm->lock);
> + return ret;
> +}
> +
> int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> {
> void __user *uaddr = (void __user *)(long)reg->addr;
> @@ -321,6 +397,8 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> return -EINVAL;
>
> return 0;
> + case KVM_REG_ARM_STD_BMAP:
> + return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
> default:
> return -ENOENT;
> }
> diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> index 5d38628a8d04..64d30b452809 100644
> --- a/include/kvm/arm_hypercalls.h
> +++ b/include/kvm/arm_hypercalls.h
> @@ -6,6 +6,9 @@
>
> #include <asm/kvm_emulate.h>
>
> +#define ARM_SMCCC_STD_FEATURES \
> + GENMASK_ULL(KVM_REG_ARM_STD_BMAP_BIT_MAX, 0)
> +
This probably needs KVM_ somewhere in its name for the sake of scoping.
> int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
>
> static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
> @@ -42,6 +45,7 @@ static inline void smccc_set_retval(struct kvm_vcpu *vcpu,
>
> struct kvm_one_reg;
>
> +void kvm_arm_init_hypercalls(struct kvm *kvm);
> int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
> int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
> int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> --
> 2.35.1.473.g83b2b277ed-goog
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 05/13] KVM: arm64: Setup a framework for hypercall bitmap firmware registers
2022-03-14 19:41 ` Oliver Upton
(?)
@ 2022-03-14 20:25 ` Oliver Upton
-1 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-14 20:25 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: kvm, Will Deacon, Marc Zyngier, Peter Shier, linux-kernel,
Catalin Marinas, Paolo Bonzini, kvmarm, linux-arm-kernel
On Mon, Mar 14, 2022 at 12:41 PM Oliver Upton <oupton@google.com> wrote:
>
> On Thu, Feb 24, 2022 at 05:25:51PM +0000, Raghavendra Rao Ananta wrote:
> > KVM regularly introduces new hypercall services to the guests without
> > any consent from the userspace. This means, the guests can observe
> > hypercall services in and out as they migrate across various host
> > kernel versions. This could be a major problem if the guest
> > discovered a hypercall, started using it, and after getting migrated
> > to an older kernel realizes that it's no longer available. Depending
> > on how the guest handles the change, there's a potential chance that
> > the guest would just panic.
> >
> > As a result, there's a need for the userspace to elect the services
> > that it wishes the guest to discover. It can elect these services
> > based on the kernels spread across its (migration) fleet. To remedy
> > this, extend the existing firmware psuedo-registers, such as
> > KVM_REG_ARM_PSCI_VERSION, for all the hypercall services available.
> >
> > These firmware registers are categorized based on the service call
> > owners, and unlike the existing firmware psuedo-registers, they hold
> > the features supported in the form of a bitmap.
> >
> > During the VM initialization, the registers holds an upper-limit of
> > the features supported by the corresponding registers. It's expected
> > that the VMMs discover the features provided by each register via
> > GET_ONE_REG, and writeback the desired values using SET_ONE_REG.
> > KVM allows this modification only until the VM has started.
> >
> > Older userspace code can simply ignore the capability and the
> > hypercall services will be exposed unconditionally to the guests, thus
> > ensuring backward compatibility.
> >
> > In this patch, the framework adds the register only for ARM's standard
> > secure services (owner value 4). Currently, this includes support only
> > for ARM True Random Number Generator (TRNG) service, with bit-0 of the
> > register representing mandatory features of v1.0. The register is also
> > added to the kvm_arm_vm_scope_fw_regs[] list as it maintains its state
> > per-VM. Other services are momentarily added in the upcoming patches.
> >
> > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > ---
> > arch/arm64/include/asm/kvm_host.h | 12 +++++
> > arch/arm64/include/uapi/asm/kvm.h | 8 ++++
> > arch/arm64/kvm/arm.c | 8 ++++
> > arch/arm64/kvm/guest.c | 1 +
> > arch/arm64/kvm/hypercalls.c | 78 +++++++++++++++++++++++++++++++
> > include/kvm/arm_hypercalls.h | 4 ++
> > 6 files changed, 111 insertions(+)
> >
> > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > index e823571e50cc..1909ced3208f 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -101,6 +101,15 @@ struct kvm_s2_mmu {
> > struct kvm_arch_memory_slot {
> > };
> >
> > +/**
> > + * struct kvm_hvc_desc: KVM ARM64 hypercall descriptor
> > + *
> > + * @hvc_std_bmap: Bitmap of standard secure service calls
> > + */
> > +struct kvm_hvc_desc {
>
> nit: maybe call this structure kvm_hypercall_features? When nested comes
> along guests will need to use the SVC conduit as HVC traps are always
> taken to EL2. Same will need to be true for virtual EL2.
actually, I'd recommend using SMCCC as the token instead, so
kvm_smccc_features. It is the one constant between HVC and SMC calls
and governs our whole hypercall ABI anyway.
> > + u64 hvc_std_bmap;
> > +};
> > +
> > struct kvm_arch {
> > struct kvm_s2_mmu mmu;
> >
> > @@ -142,6 +151,9 @@ struct kvm_arch {
> >
> > /* Capture first run of the VM */
> > bool has_run_once;
> > +
> > + /* Hypercall firmware register' descriptor */
> > + struct kvm_hvc_desc hvc_desc;
> > };
> >
> > struct kvm_vcpu_fault_info {
> > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > index c35447cc0e0c..2decc30d6b84 100644
> > --- a/arch/arm64/include/uapi/asm/kvm.h
> > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > @@ -287,6 +287,14 @@ struct kvm_arm_copy_mte_tags {
> > #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED 3
> > #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED (1U << 4)
> >
> > +/* Bitmap firmware registers, extension to the existing psuedo-register space */
> > +#define KVM_REG_ARM_FW_BMAP KVM_REG_ARM_FW_REG(0xff00)
>
> What is the motivation for moving the bitmap register indices so far
> away from the rest of the firmware regs?
>
> > +#define KVM_REG_ARM_FW_BMAP_REG(r) (KVM_REG_ARM_FW_BMAP | (r))
>
> If you are still going to use the index offset, just pass 'r' through to
> the other macro:
>
> #define KVM_REG_ARM_FW_BMAP_REG(r) KVM_REG_ARM_FW_REG(0xff00 + r)
>
> > +#define KVM_REG_ARM_STD_BMAP KVM_REG_ARM_FW_BMAP_REG(0)
> > +#define KVM_REG_ARM_STD_BIT_TRNG_V1_0 BIT(0)
> > +#define KVM_REG_ARM_STD_BMAP_BIT_MAX 0 /* Last valid bit */
>
> Implementation details such as this probably shouldn't live in UAPI
> headers. We'll likely need to bump the value in the future.
>
> > +
> > /* SVE registers */
> > #define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
> >
> > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > index f61cd8d57eae..e9f9edb1cf55 100644
> > --- a/arch/arm64/kvm/arm.c
> > +++ b/arch/arm64/kvm/arm.c
> > @@ -156,6 +156,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> > kvm->arch.max_vcpus = kvm_arm_default_max_vcpus();
> >
> > set_default_spectre(kvm);
> > + kvm_arm_init_hypercalls(kvm);
> >
> > return ret;
> > out_free_stage2_pgd:
> > @@ -635,7 +636,14 @@ int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu)
> > if (kvm_vm_is_protected(kvm))
> > kvm_call_hyp_nvhe(__pkvm_vcpu_init_traps, vcpu);
> >
> > + /*
> > + * Grab kvm->lock such that the reader of has_run_once can finish
> > + * the necessary operation atomically, such as deciding whether to
> > + * block the writes to the firmware registers if the VM has run once.
> > + */
> > + mutex_lock(&kvm->lock);
> > kvm->arch.has_run_once = true;
> > + mutex_unlock(&kvm->lock);
>
> Shouldn't this have just grabbed the kvm lock in patch 04/13?
>
> > return ret;
> > }
> > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> > index eb061e64a7a5..d66e6c742bbe 100644
> > --- a/arch/arm64/kvm/guest.c
> > +++ b/arch/arm64/kvm/guest.c
> > @@ -65,6 +65,7 @@ const struct kvm_stats_header kvm_vcpu_stats_header = {
> > static const u64 kvm_arm_vm_scope_fw_regs[] = {
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > + KVM_REG_ARM_STD_BMAP,
> > };
> >
> > /**
> > diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> > index 8624e6964940..48c126c3da72 100644
> > --- a/arch/arm64/kvm/hypercalls.c
> > +++ b/arch/arm64/kvm/hypercalls.c
> > @@ -58,6 +58,29 @@ static void kvm_ptp_get_time(struct kvm_vcpu *vcpu, u64 *val)
> > val[3] = lower_32_bits(cycles);
> > }
> >
> > +static bool kvm_arm_fw_reg_feat_enabled(u64 reg_bmap, u64 feat_bit)
> > +{
> > + return reg_bmap & feat_bit;
> > +}
> > +
> > +static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> > +{
> > + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> > +
> > + switch (func_id) {
> > + case ARM_SMCCC_TRNG_VERSION:
> > + case ARM_SMCCC_TRNG_FEATURES:
> > + case ARM_SMCCC_TRNG_GET_UUID:
> > + case ARM_SMCCC_TRNG_RND32:
> > + case ARM_SMCCC_TRNG_RND64:
> > + return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_bmap,
> > + KVM_REG_ARM_STD_BIT_TRNG_V1_0);
> > + default:
> > + /* By default, allow the services that aren't listed here */
> > + return true;
>
> I think your default case should really return false. It keeps people
> honest when they add new patches to set up a new hypercall bit (no bit?
> no call!)
>
> That of course requires that you only return false once all of the
> preexisting hypercalls are enumerated, otherwise such a patch would
> cause a regression in isolation.
>
> > + }
> > +}
> > +
> > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > {
> > u32 func_id = smccc_get_function(vcpu);
> > @@ -65,6 +88,9 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > u32 feature;
> > gpa_t gpa;
> >
> > + if (!kvm_hvc_call_supported(vcpu, func_id))
> > + goto out;
> > +
> > switch (func_id) {
> > case ARM_SMCCC_VERSION_FUNC_ID:
> > val[0] = ARM_SMCCC_VERSION_1_1;
> > @@ -143,6 +169,7 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > return kvm_psci_call(vcpu);
> > }
> >
> > +out:
> > smccc_set_retval(vcpu, val[0], val[1], val[2], val[3]);
> > return 1;
> > }
> > @@ -151,8 +178,16 @@ static const u64 kvm_arm_fw_reg_ids[] = {
> > KVM_REG_ARM_PSCI_VERSION,
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > + KVM_REG_ARM_STD_BMAP,
> > };
> >
> > +void kvm_arm_init_hypercalls(struct kvm *kvm)
> > +{
> > + struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
> > +
> > + hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
> > +}
> > +
> > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> > {
> > return ARRAY_SIZE(kvm_arm_fw_reg_ids);
> > @@ -220,6 +255,7 @@ static int get_kernel_wa_level(u64 regid)
> >
> > int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > {
> > + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> > void __user *uaddr = (void __user *)(long)reg->addr;
> > u64 val, reg_id = reg->id;
> >
> > @@ -233,6 +269,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> > val = get_kernel_wa_level(reg_id) & KVM_REG_FEATURE_LEVEL_MASK;
> > break;
> > + case KVM_REG_ARM_STD_BMAP:
> > + val = READ_ONCE(hvc_desc->hvc_std_bmap);
> > + break;
> > default:
> > return -ENOENT;
> > }
> > @@ -243,6 +282,43 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > return 0;
> > }
> >
> > +static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
> > +{
> > + int ret = 0;
> > + struct kvm *kvm = vcpu->kvm;
> > + struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
> > + u64 *fw_reg_bmap, fw_reg_features;
>
> nit: use reverse fir tree ordering for locals (longest line first,
> shortest last).
>
> > + switch (reg_id) {
> > + case KVM_REG_ARM_STD_BMAP:
> > + fw_reg_bmap = &hvc_desc->hvc_std_bmap;
> > + fw_reg_features = ARM_SMCCC_STD_FEATURES;
> > + break;
> > + default:
> > + return -ENOENT;
> > + }
> > +
> > + /* Check for unsupported bit */
> > + if (val & ~fw_reg_features)
> > + return -EINVAL;
> > +
> > + mutex_lock(&kvm->lock);
> > +
> > + /*
> > + * If the VM (any vCPU) has already started running, return success
> > + * if there's no change in the value. Else, return -EBUSY.
>
> How about returning -EINVAL instead? We already do this for
> KVM_ARM_VCPU_INIT if userspace uses a different target than the one
> previously set.
>
> > + */
> > + if (kvm_arm_vm_has_run_once(&kvm->arch)) {
> > + ret = *fw_reg_bmap != val ? -EBUSY : 0;
> > + goto out;
> > + }
> > +
> > + WRITE_ONCE(*fw_reg_bmap, val);
> > +out:
> > + mutex_unlock(&kvm->lock);
> > + return ret;
> > +}
> > +
> > int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > {
> > void __user *uaddr = (void __user *)(long)reg->addr;
> > @@ -321,6 +397,8 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > return -EINVAL;
> >
> > return 0;
> > + case KVM_REG_ARM_STD_BMAP:
> > + return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
> > default:
> > return -ENOENT;
> > }
> > diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> > index 5d38628a8d04..64d30b452809 100644
> > --- a/include/kvm/arm_hypercalls.h
> > +++ b/include/kvm/arm_hypercalls.h
> > @@ -6,6 +6,9 @@
> >
> > #include <asm/kvm_emulate.h>
> >
> > +#define ARM_SMCCC_STD_FEATURES \
> > + GENMASK_ULL(KVM_REG_ARM_STD_BMAP_BIT_MAX, 0)
> > +
>
> This probably needs KVM_ somewhere in its name for the sake of scoping.
>
> > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
> >
> > static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
> > @@ -42,6 +45,7 @@ static inline void smccc_set_retval(struct kvm_vcpu *vcpu,
> >
> > struct kvm_one_reg;
> >
> > +void kvm_arm_init_hypercalls(struct kvm *kvm);
> > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
> > int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
> > int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> > --
> > 2.35.1.473.g83b2b277ed-goog
> >
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 05/13] KVM: arm64: Setup a framework for hypercall bitmap firmware registers
@ 2022-03-14 20:25 ` Oliver Upton
0 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-14 20:25 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Mon, Mar 14, 2022 at 12:41 PM Oliver Upton <oupton@google.com> wrote:
>
> On Thu, Feb 24, 2022 at 05:25:51PM +0000, Raghavendra Rao Ananta wrote:
> > KVM regularly introduces new hypercall services to the guests without
> > any consent from the userspace. This means, the guests can observe
> > hypercall services in and out as they migrate across various host
> > kernel versions. This could be a major problem if the guest
> > discovered a hypercall, started using it, and after getting migrated
> > to an older kernel realizes that it's no longer available. Depending
> > on how the guest handles the change, there's a potential chance that
> > the guest would just panic.
> >
> > As a result, there's a need for the userspace to elect the services
> > that it wishes the guest to discover. It can elect these services
> > based on the kernels spread across its (migration) fleet. To remedy
> > this, extend the existing firmware psuedo-registers, such as
> > KVM_REG_ARM_PSCI_VERSION, for all the hypercall services available.
> >
> > These firmware registers are categorized based on the service call
> > owners, and unlike the existing firmware psuedo-registers, they hold
> > the features supported in the form of a bitmap.
> >
> > During the VM initialization, the registers holds an upper-limit of
> > the features supported by the corresponding registers. It's expected
> > that the VMMs discover the features provided by each register via
> > GET_ONE_REG, and writeback the desired values using SET_ONE_REG.
> > KVM allows this modification only until the VM has started.
> >
> > Older userspace code can simply ignore the capability and the
> > hypercall services will be exposed unconditionally to the guests, thus
> > ensuring backward compatibility.
> >
> > In this patch, the framework adds the register only for ARM's standard
> > secure services (owner value 4). Currently, this includes support only
> > for ARM True Random Number Generator (TRNG) service, with bit-0 of the
> > register representing mandatory features of v1.0. The register is also
> > added to the kvm_arm_vm_scope_fw_regs[] list as it maintains its state
> > per-VM. Other services are momentarily added in the upcoming patches.
> >
> > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > ---
> > arch/arm64/include/asm/kvm_host.h | 12 +++++
> > arch/arm64/include/uapi/asm/kvm.h | 8 ++++
> > arch/arm64/kvm/arm.c | 8 ++++
> > arch/arm64/kvm/guest.c | 1 +
> > arch/arm64/kvm/hypercalls.c | 78 +++++++++++++++++++++++++++++++
> > include/kvm/arm_hypercalls.h | 4 ++
> > 6 files changed, 111 insertions(+)
> >
> > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > index e823571e50cc..1909ced3208f 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -101,6 +101,15 @@ struct kvm_s2_mmu {
> > struct kvm_arch_memory_slot {
> > };
> >
> > +/**
> > + * struct kvm_hvc_desc: KVM ARM64 hypercall descriptor
> > + *
> > + * @hvc_std_bmap: Bitmap of standard secure service calls
> > + */
> > +struct kvm_hvc_desc {
>
> nit: maybe call this structure kvm_hypercall_features? When nested comes
> along guests will need to use the SVC conduit as HVC traps are always
> taken to EL2. Same will need to be true for virtual EL2.
actually, I'd recommend using SMCCC as the token instead, so
kvm_smccc_features. It is the one constant between HVC and SMC calls
and governs our whole hypercall ABI anyway.
> > + u64 hvc_std_bmap;
> > +};
> > +
> > struct kvm_arch {
> > struct kvm_s2_mmu mmu;
> >
> > @@ -142,6 +151,9 @@ struct kvm_arch {
> >
> > /* Capture first run of the VM */
> > bool has_run_once;
> > +
> > + /* Hypercall firmware register' descriptor */
> > + struct kvm_hvc_desc hvc_desc;
> > };
> >
> > struct kvm_vcpu_fault_info {
> > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > index c35447cc0e0c..2decc30d6b84 100644
> > --- a/arch/arm64/include/uapi/asm/kvm.h
> > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > @@ -287,6 +287,14 @@ struct kvm_arm_copy_mte_tags {
> > #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED 3
> > #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED (1U << 4)
> >
> > +/* Bitmap firmware registers, extension to the existing psuedo-register space */
> > +#define KVM_REG_ARM_FW_BMAP KVM_REG_ARM_FW_REG(0xff00)
>
> What is the motivation for moving the bitmap register indices so far
> away from the rest of the firmware regs?
>
> > +#define KVM_REG_ARM_FW_BMAP_REG(r) (KVM_REG_ARM_FW_BMAP | (r))
>
> If you are still going to use the index offset, just pass 'r' through to
> the other macro:
>
> #define KVM_REG_ARM_FW_BMAP_REG(r) KVM_REG_ARM_FW_REG(0xff00 + r)
>
> > +#define KVM_REG_ARM_STD_BMAP KVM_REG_ARM_FW_BMAP_REG(0)
> > +#define KVM_REG_ARM_STD_BIT_TRNG_V1_0 BIT(0)
> > +#define KVM_REG_ARM_STD_BMAP_BIT_MAX 0 /* Last valid bit */
>
> Implementation details such as this probably shouldn't live in UAPI
> headers. We'll likely need to bump the value in the future.
>
> > +
> > /* SVE registers */
> > #define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
> >
> > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > index f61cd8d57eae..e9f9edb1cf55 100644
> > --- a/arch/arm64/kvm/arm.c
> > +++ b/arch/arm64/kvm/arm.c
> > @@ -156,6 +156,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> > kvm->arch.max_vcpus = kvm_arm_default_max_vcpus();
> >
> > set_default_spectre(kvm);
> > + kvm_arm_init_hypercalls(kvm);
> >
> > return ret;
> > out_free_stage2_pgd:
> > @@ -635,7 +636,14 @@ int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu)
> > if (kvm_vm_is_protected(kvm))
> > kvm_call_hyp_nvhe(__pkvm_vcpu_init_traps, vcpu);
> >
> > + /*
> > + * Grab kvm->lock such that the reader of has_run_once can finish
> > + * the necessary operation atomically, such as deciding whether to
> > + * block the writes to the firmware registers if the VM has run once.
> > + */
> > + mutex_lock(&kvm->lock);
> > kvm->arch.has_run_once = true;
> > + mutex_unlock(&kvm->lock);
>
> Shouldn't this have just grabbed the kvm lock in patch 04/13?
>
> > return ret;
> > }
> > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> > index eb061e64a7a5..d66e6c742bbe 100644
> > --- a/arch/arm64/kvm/guest.c
> > +++ b/arch/arm64/kvm/guest.c
> > @@ -65,6 +65,7 @@ const struct kvm_stats_header kvm_vcpu_stats_header = {
> > static const u64 kvm_arm_vm_scope_fw_regs[] = {
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > + KVM_REG_ARM_STD_BMAP,
> > };
> >
> > /**
> > diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> > index 8624e6964940..48c126c3da72 100644
> > --- a/arch/arm64/kvm/hypercalls.c
> > +++ b/arch/arm64/kvm/hypercalls.c
> > @@ -58,6 +58,29 @@ static void kvm_ptp_get_time(struct kvm_vcpu *vcpu, u64 *val)
> > val[3] = lower_32_bits(cycles);
> > }
> >
> > +static bool kvm_arm_fw_reg_feat_enabled(u64 reg_bmap, u64 feat_bit)
> > +{
> > + return reg_bmap & feat_bit;
> > +}
> > +
> > +static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> > +{
> > + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> > +
> > + switch (func_id) {
> > + case ARM_SMCCC_TRNG_VERSION:
> > + case ARM_SMCCC_TRNG_FEATURES:
> > + case ARM_SMCCC_TRNG_GET_UUID:
> > + case ARM_SMCCC_TRNG_RND32:
> > + case ARM_SMCCC_TRNG_RND64:
> > + return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_bmap,
> > + KVM_REG_ARM_STD_BIT_TRNG_V1_0);
> > + default:
> > + /* By default, allow the services that aren't listed here */
> > + return true;
>
> I think your default case should really return false. It keeps people
> honest when they add new patches to set up a new hypercall bit (no bit?
> no call!)
>
> That of course requires that you only return false once all of the
> preexisting hypercalls are enumerated, otherwise such a patch would
> cause a regression in isolation.
>
> > + }
> > +}
> > +
> > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > {
> > u32 func_id = smccc_get_function(vcpu);
> > @@ -65,6 +88,9 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > u32 feature;
> > gpa_t gpa;
> >
> > + if (!kvm_hvc_call_supported(vcpu, func_id))
> > + goto out;
> > +
> > switch (func_id) {
> > case ARM_SMCCC_VERSION_FUNC_ID:
> > val[0] = ARM_SMCCC_VERSION_1_1;
> > @@ -143,6 +169,7 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > return kvm_psci_call(vcpu);
> > }
> >
> > +out:
> > smccc_set_retval(vcpu, val[0], val[1], val[2], val[3]);
> > return 1;
> > }
> > @@ -151,8 +178,16 @@ static const u64 kvm_arm_fw_reg_ids[] = {
> > KVM_REG_ARM_PSCI_VERSION,
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > + KVM_REG_ARM_STD_BMAP,
> > };
> >
> > +void kvm_arm_init_hypercalls(struct kvm *kvm)
> > +{
> > + struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
> > +
> > + hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
> > +}
> > +
> > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> > {
> > return ARRAY_SIZE(kvm_arm_fw_reg_ids);
> > @@ -220,6 +255,7 @@ static int get_kernel_wa_level(u64 regid)
> >
> > int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > {
> > + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> > void __user *uaddr = (void __user *)(long)reg->addr;
> > u64 val, reg_id = reg->id;
> >
> > @@ -233,6 +269,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> > val = get_kernel_wa_level(reg_id) & KVM_REG_FEATURE_LEVEL_MASK;
> > break;
> > + case KVM_REG_ARM_STD_BMAP:
> > + val = READ_ONCE(hvc_desc->hvc_std_bmap);
> > + break;
> > default:
> > return -ENOENT;
> > }
> > @@ -243,6 +282,43 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > return 0;
> > }
> >
> > +static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
> > +{
> > + int ret = 0;
> > + struct kvm *kvm = vcpu->kvm;
> > + struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
> > + u64 *fw_reg_bmap, fw_reg_features;
>
> nit: use reverse fir tree ordering for locals (longest line first,
> shortest last).
>
> > + switch (reg_id) {
> > + case KVM_REG_ARM_STD_BMAP:
> > + fw_reg_bmap = &hvc_desc->hvc_std_bmap;
> > + fw_reg_features = ARM_SMCCC_STD_FEATURES;
> > + break;
> > + default:
> > + return -ENOENT;
> > + }
> > +
> > + /* Check for unsupported bit */
> > + if (val & ~fw_reg_features)
> > + return -EINVAL;
> > +
> > + mutex_lock(&kvm->lock);
> > +
> > + /*
> > + * If the VM (any vCPU) has already started running, return success
> > + * if there's no change in the value. Else, return -EBUSY.
>
> How about returning -EINVAL instead? We already do this for
> KVM_ARM_VCPU_INIT if userspace uses a different target than the one
> previously set.
>
> > + */
> > + if (kvm_arm_vm_has_run_once(&kvm->arch)) {
> > + ret = *fw_reg_bmap != val ? -EBUSY : 0;
> > + goto out;
> > + }
> > +
> > + WRITE_ONCE(*fw_reg_bmap, val);
> > +out:
> > + mutex_unlock(&kvm->lock);
> > + return ret;
> > +}
> > +
> > int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > {
> > void __user *uaddr = (void __user *)(long)reg->addr;
> > @@ -321,6 +397,8 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > return -EINVAL;
> >
> > return 0;
> > + case KVM_REG_ARM_STD_BMAP:
> > + return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
> > default:
> > return -ENOENT;
> > }
> > diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> > index 5d38628a8d04..64d30b452809 100644
> > --- a/include/kvm/arm_hypercalls.h
> > +++ b/include/kvm/arm_hypercalls.h
> > @@ -6,6 +6,9 @@
> >
> > #include <asm/kvm_emulate.h>
> >
> > +#define ARM_SMCCC_STD_FEATURES \
> > + GENMASK_ULL(KVM_REG_ARM_STD_BMAP_BIT_MAX, 0)
> > +
>
> This probably needs KVM_ somewhere in its name for the sake of scoping.
>
> > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
> >
> > static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
> > @@ -42,6 +45,7 @@ static inline void smccc_set_retval(struct kvm_vcpu *vcpu,
> >
> > struct kvm_one_reg;
> >
> > +void kvm_arm_init_hypercalls(struct kvm *kvm);
> > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
> > int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
> > int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> > --
> > 2.35.1.473.g83b2b277ed-goog
> >
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 05/13] KVM: arm64: Setup a framework for hypercall bitmap firmware registers
@ 2022-03-14 20:25 ` Oliver Upton
0 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-14 20:25 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Mon, Mar 14, 2022 at 12:41 PM Oliver Upton <oupton@google.com> wrote:
>
> On Thu, Feb 24, 2022 at 05:25:51PM +0000, Raghavendra Rao Ananta wrote:
> > KVM regularly introduces new hypercall services to the guests without
> > any consent from the userspace. This means, the guests can observe
> > hypercall services in and out as they migrate across various host
> > kernel versions. This could be a major problem if the guest
> > discovered a hypercall, started using it, and after getting migrated
> > to an older kernel realizes that it's no longer available. Depending
> > on how the guest handles the change, there's a potential chance that
> > the guest would just panic.
> >
> > As a result, there's a need for the userspace to elect the services
> > that it wishes the guest to discover. It can elect these services
> > based on the kernels spread across its (migration) fleet. To remedy
> > this, extend the existing firmware psuedo-registers, such as
> > KVM_REG_ARM_PSCI_VERSION, for all the hypercall services available.
> >
> > These firmware registers are categorized based on the service call
> > owners, and unlike the existing firmware psuedo-registers, they hold
> > the features supported in the form of a bitmap.
> >
> > During the VM initialization, the registers holds an upper-limit of
> > the features supported by the corresponding registers. It's expected
> > that the VMMs discover the features provided by each register via
> > GET_ONE_REG, and writeback the desired values using SET_ONE_REG.
> > KVM allows this modification only until the VM has started.
> >
> > Older userspace code can simply ignore the capability and the
> > hypercall services will be exposed unconditionally to the guests, thus
> > ensuring backward compatibility.
> >
> > In this patch, the framework adds the register only for ARM's standard
> > secure services (owner value 4). Currently, this includes support only
> > for ARM True Random Number Generator (TRNG) service, with bit-0 of the
> > register representing mandatory features of v1.0. The register is also
> > added to the kvm_arm_vm_scope_fw_regs[] list as it maintains its state
> > per-VM. Other services are momentarily added in the upcoming patches.
> >
> > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > ---
> > arch/arm64/include/asm/kvm_host.h | 12 +++++
> > arch/arm64/include/uapi/asm/kvm.h | 8 ++++
> > arch/arm64/kvm/arm.c | 8 ++++
> > arch/arm64/kvm/guest.c | 1 +
> > arch/arm64/kvm/hypercalls.c | 78 +++++++++++++++++++++++++++++++
> > include/kvm/arm_hypercalls.h | 4 ++
> > 6 files changed, 111 insertions(+)
> >
> > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > index e823571e50cc..1909ced3208f 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -101,6 +101,15 @@ struct kvm_s2_mmu {
> > struct kvm_arch_memory_slot {
> > };
> >
> > +/**
> > + * struct kvm_hvc_desc: KVM ARM64 hypercall descriptor
> > + *
> > + * @hvc_std_bmap: Bitmap of standard secure service calls
> > + */
> > +struct kvm_hvc_desc {
>
> nit: maybe call this structure kvm_hypercall_features? When nested comes
> along guests will need to use the SVC conduit as HVC traps are always
> taken to EL2. Same will need to be true for virtual EL2.
actually, I'd recommend using SMCCC as the token instead, so
kvm_smccc_features. It is the one constant between HVC and SMC calls
and governs our whole hypercall ABI anyway.
> > + u64 hvc_std_bmap;
> > +};
> > +
> > struct kvm_arch {
> > struct kvm_s2_mmu mmu;
> >
> > @@ -142,6 +151,9 @@ struct kvm_arch {
> >
> > /* Capture first run of the VM */
> > bool has_run_once;
> > +
> > + /* Hypercall firmware register' descriptor */
> > + struct kvm_hvc_desc hvc_desc;
> > };
> >
> > struct kvm_vcpu_fault_info {
> > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > index c35447cc0e0c..2decc30d6b84 100644
> > --- a/arch/arm64/include/uapi/asm/kvm.h
> > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > @@ -287,6 +287,14 @@ struct kvm_arm_copy_mte_tags {
> > #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED 3
> > #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED (1U << 4)
> >
> > +/* Bitmap firmware registers, extension to the existing psuedo-register space */
> > +#define KVM_REG_ARM_FW_BMAP KVM_REG_ARM_FW_REG(0xff00)
>
> What is the motivation for moving the bitmap register indices so far
> away from the rest of the firmware regs?
>
> > +#define KVM_REG_ARM_FW_BMAP_REG(r) (KVM_REG_ARM_FW_BMAP | (r))
>
> If you are still going to use the index offset, just pass 'r' through to
> the other macro:
>
> #define KVM_REG_ARM_FW_BMAP_REG(r) KVM_REG_ARM_FW_REG(0xff00 + r)
>
> > +#define KVM_REG_ARM_STD_BMAP KVM_REG_ARM_FW_BMAP_REG(0)
> > +#define KVM_REG_ARM_STD_BIT_TRNG_V1_0 BIT(0)
> > +#define KVM_REG_ARM_STD_BMAP_BIT_MAX 0 /* Last valid bit */
>
> Implementation details such as this probably shouldn't live in UAPI
> headers. We'll likely need to bump the value in the future.
>
> > +
> > /* SVE registers */
> > #define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
> >
> > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > index f61cd8d57eae..e9f9edb1cf55 100644
> > --- a/arch/arm64/kvm/arm.c
> > +++ b/arch/arm64/kvm/arm.c
> > @@ -156,6 +156,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> > kvm->arch.max_vcpus = kvm_arm_default_max_vcpus();
> >
> > set_default_spectre(kvm);
> > + kvm_arm_init_hypercalls(kvm);
> >
> > return ret;
> > out_free_stage2_pgd:
> > @@ -635,7 +636,14 @@ int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu)
> > if (kvm_vm_is_protected(kvm))
> > kvm_call_hyp_nvhe(__pkvm_vcpu_init_traps, vcpu);
> >
> > + /*
> > + * Grab kvm->lock such that the reader of has_run_once can finish
> > + * the necessary operation atomically, such as deciding whether to
> > + * block the writes to the firmware registers if the VM has run once.
> > + */
> > + mutex_lock(&kvm->lock);
> > kvm->arch.has_run_once = true;
> > + mutex_unlock(&kvm->lock);
>
> Shouldn't this have just grabbed the kvm lock in patch 04/13?
>
> > return ret;
> > }
> > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> > index eb061e64a7a5..d66e6c742bbe 100644
> > --- a/arch/arm64/kvm/guest.c
> > +++ b/arch/arm64/kvm/guest.c
> > @@ -65,6 +65,7 @@ const struct kvm_stats_header kvm_vcpu_stats_header = {
> > static const u64 kvm_arm_vm_scope_fw_regs[] = {
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > + KVM_REG_ARM_STD_BMAP,
> > };
> >
> > /**
> > diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> > index 8624e6964940..48c126c3da72 100644
> > --- a/arch/arm64/kvm/hypercalls.c
> > +++ b/arch/arm64/kvm/hypercalls.c
> > @@ -58,6 +58,29 @@ static void kvm_ptp_get_time(struct kvm_vcpu *vcpu, u64 *val)
> > val[3] = lower_32_bits(cycles);
> > }
> >
> > +static bool kvm_arm_fw_reg_feat_enabled(u64 reg_bmap, u64 feat_bit)
> > +{
> > + return reg_bmap & feat_bit;
> > +}
> > +
> > +static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> > +{
> > + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> > +
> > + switch (func_id) {
> > + case ARM_SMCCC_TRNG_VERSION:
> > + case ARM_SMCCC_TRNG_FEATURES:
> > + case ARM_SMCCC_TRNG_GET_UUID:
> > + case ARM_SMCCC_TRNG_RND32:
> > + case ARM_SMCCC_TRNG_RND64:
> > + return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_bmap,
> > + KVM_REG_ARM_STD_BIT_TRNG_V1_0);
> > + default:
> > + /* By default, allow the services that aren't listed here */
> > + return true;
>
> I think your default case should really return false. It keeps people
> honest when they add new patches to set up a new hypercall bit (no bit?
> no call!)
>
> That of course requires that you only return false once all of the
> preexisting hypercalls are enumerated, otherwise such a patch would
> cause a regression in isolation.
>
> > + }
> > +}
> > +
> > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > {
> > u32 func_id = smccc_get_function(vcpu);
> > @@ -65,6 +88,9 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > u32 feature;
> > gpa_t gpa;
> >
> > + if (!kvm_hvc_call_supported(vcpu, func_id))
> > + goto out;
> > +
> > switch (func_id) {
> > case ARM_SMCCC_VERSION_FUNC_ID:
> > val[0] = ARM_SMCCC_VERSION_1_1;
> > @@ -143,6 +169,7 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > return kvm_psci_call(vcpu);
> > }
> >
> > +out:
> > smccc_set_retval(vcpu, val[0], val[1], val[2], val[3]);
> > return 1;
> > }
> > @@ -151,8 +178,16 @@ static const u64 kvm_arm_fw_reg_ids[] = {
> > KVM_REG_ARM_PSCI_VERSION,
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > + KVM_REG_ARM_STD_BMAP,
> > };
> >
> > +void kvm_arm_init_hypercalls(struct kvm *kvm)
> > +{
> > + struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
> > +
> > + hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
> > +}
> > +
> > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> > {
> > return ARRAY_SIZE(kvm_arm_fw_reg_ids);
> > @@ -220,6 +255,7 @@ static int get_kernel_wa_level(u64 regid)
> >
> > int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > {
> > + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> > void __user *uaddr = (void __user *)(long)reg->addr;
> > u64 val, reg_id = reg->id;
> >
> > @@ -233,6 +269,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> > val = get_kernel_wa_level(reg_id) & KVM_REG_FEATURE_LEVEL_MASK;
> > break;
> > + case KVM_REG_ARM_STD_BMAP:
> > + val = READ_ONCE(hvc_desc->hvc_std_bmap);
> > + break;
> > default:
> > return -ENOENT;
> > }
> > @@ -243,6 +282,43 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > return 0;
> > }
> >
> > +static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
> > +{
> > + int ret = 0;
> > + struct kvm *kvm = vcpu->kvm;
> > + struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
> > + u64 *fw_reg_bmap, fw_reg_features;
>
> nit: use reverse fir tree ordering for locals (longest line first,
> shortest last).
>
> > + switch (reg_id) {
> > + case KVM_REG_ARM_STD_BMAP:
> > + fw_reg_bmap = &hvc_desc->hvc_std_bmap;
> > + fw_reg_features = ARM_SMCCC_STD_FEATURES;
> > + break;
> > + default:
> > + return -ENOENT;
> > + }
> > +
> > + /* Check for unsupported bit */
> > + if (val & ~fw_reg_features)
> > + return -EINVAL;
> > +
> > + mutex_lock(&kvm->lock);
> > +
> > + /*
> > + * If the VM (any vCPU) has already started running, return success
> > + * if there's no change in the value. Else, return -EBUSY.
>
> How about returning -EINVAL instead? We already do this for
> KVM_ARM_VCPU_INIT if userspace uses a different target than the one
> previously set.
>
> > + */
> > + if (kvm_arm_vm_has_run_once(&kvm->arch)) {
> > + ret = *fw_reg_bmap != val ? -EBUSY : 0;
> > + goto out;
> > + }
> > +
> > + WRITE_ONCE(*fw_reg_bmap, val);
> > +out:
> > + mutex_unlock(&kvm->lock);
> > + return ret;
> > +}
> > +
> > int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > {
> > void __user *uaddr = (void __user *)(long)reg->addr;
> > @@ -321,6 +397,8 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > return -EINVAL;
> >
> > return 0;
> > + case KVM_REG_ARM_STD_BMAP:
> > + return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
> > default:
> > return -ENOENT;
> > }
> > diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> > index 5d38628a8d04..64d30b452809 100644
> > --- a/include/kvm/arm_hypercalls.h
> > +++ b/include/kvm/arm_hypercalls.h
> > @@ -6,6 +6,9 @@
> >
> > #include <asm/kvm_emulate.h>
> >
> > +#define ARM_SMCCC_STD_FEATURES \
> > + GENMASK_ULL(KVM_REG_ARM_STD_BMAP_BIT_MAX, 0)
> > +
>
> This probably needs KVM_ somewhere in its name for the sake of scoping.
>
> > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
> >
> > static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
> > @@ -42,6 +45,7 @@ static inline void smccc_set_retval(struct kvm_vcpu *vcpu,
> >
> > struct kvm_one_reg;
> >
> > +void kvm_arm_init_hypercalls(struct kvm *kvm);
> > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
> > int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
> > int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> > --
> > 2.35.1.473.g83b2b277ed-goog
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: [PATCH v4 05/13] KVM: arm64: Setup a framework for hypercall bitmap firmware registers
2022-03-14 19:41 ` Oliver Upton
(?)
@ 2022-03-15 0:22 ` Raghavendra Rao Ananta
-1 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-03-15 0:22 UTC (permalink / raw)
To: Oliver Upton
Cc: kvm, Will Deacon, Marc Zyngier, Peter Shier, linux-kernel,
Catalin Marinas, Paolo Bonzini, kvmarm, linux-arm-kernel
Hi Oliver,
On Mon, Mar 14, 2022 at 12:41 PM Oliver Upton <oupton@google.com> wrote:
>
> On Thu, Feb 24, 2022 at 05:25:51PM +0000, Raghavendra Rao Ananta wrote:
> > KVM regularly introduces new hypercall services to the guests without
> > any consent from the userspace. This means, the guests can observe
> > hypercall services in and out as they migrate across various host
> > kernel versions. This could be a major problem if the guest
> > discovered a hypercall, started using it, and after getting migrated
> > to an older kernel realizes that it's no longer available. Depending
> > on how the guest handles the change, there's a potential chance that
> > the guest would just panic.
> >
> > As a result, there's a need for the userspace to elect the services
> > that it wishes the guest to discover. It can elect these services
> > based on the kernels spread across its (migration) fleet. To remedy
> > this, extend the existing firmware psuedo-registers, such as
> > KVM_REG_ARM_PSCI_VERSION, for all the hypercall services available.
> >
> > These firmware registers are categorized based on the service call
> > owners, and unlike the existing firmware psuedo-registers, they hold
> > the features supported in the form of a bitmap.
> >
> > During the VM initialization, the registers holds an upper-limit of
> > the features supported by the corresponding registers. It's expected
> > that the VMMs discover the features provided by each register via
> > GET_ONE_REG, and writeback the desired values using SET_ONE_REG.
> > KVM allows this modification only until the VM has started.
> >
> > Older userspace code can simply ignore the capability and the
> > hypercall services will be exposed unconditionally to the guests, thus
> > ensuring backward compatibility.
> >
> > In this patch, the framework adds the register only for ARM's standard
> > secure services (owner value 4). Currently, this includes support only
> > for ARM True Random Number Generator (TRNG) service, with bit-0 of the
> > register representing mandatory features of v1.0. The register is also
> > added to the kvm_arm_vm_scope_fw_regs[] list as it maintains its state
> > per-VM. Other services are momentarily added in the upcoming patches.
> >
> > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > ---
> > arch/arm64/include/asm/kvm_host.h | 12 +++++
> > arch/arm64/include/uapi/asm/kvm.h | 8 ++++
> > arch/arm64/kvm/arm.c | 8 ++++
> > arch/arm64/kvm/guest.c | 1 +
> > arch/arm64/kvm/hypercalls.c | 78 +++++++++++++++++++++++++++++++
> > include/kvm/arm_hypercalls.h | 4 ++
> > 6 files changed, 111 insertions(+)
> >
> > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > index e823571e50cc..1909ced3208f 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -101,6 +101,15 @@ struct kvm_s2_mmu {
> > struct kvm_arch_memory_slot {
> > };
> >
> > +/**
> > + * struct kvm_hvc_desc: KVM ARM64 hypercall descriptor
> > + *
> > + * @hvc_std_bmap: Bitmap of standard secure service calls
> > + */
> > +struct kvm_hvc_desc {
>
> nit: maybe call this structure kvm_hypercall_features? When nested comes
> along guests will need to use the SVC conduit as HVC traps are always
> taken to EL2. Same will need to be true for virtual EL2.
>
Sure, I can rename it to be more generic.
> > + u64 hvc_std_bmap;
> > +};
> > +
> > struct kvm_arch {
> > struct kvm_s2_mmu mmu;
> >
> > @@ -142,6 +151,9 @@ struct kvm_arch {
> >
> > /* Capture first run of the VM */
> > bool has_run_once;
> > +
> > + /* Hypercall firmware register' descriptor */
> > + struct kvm_hvc_desc hvc_desc;
> > };
> >
> > struct kvm_vcpu_fault_info {
> > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > index c35447cc0e0c..2decc30d6b84 100644
> > --- a/arch/arm64/include/uapi/asm/kvm.h
> > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > @@ -287,6 +287,14 @@ struct kvm_arm_copy_mte_tags {
> > #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED 3
> > #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED (1U << 4)
> >
> > +/* Bitmap firmware registers, extension to the existing psuedo-register space */
> > +#define KVM_REG_ARM_FW_BMAP KVM_REG_ARM_FW_REG(0xff00)
>
> What is the motivation for moving the bitmap register indices so far
> away from the rest of the firmware regs?
>
The original motivation to create a sub-space came from Reiji's
comment on v3 [1] so that user-space can distinguish between bitmapped
and regular fw registers.
As with the spacing, I thought a 50/50 split would do a good job of
avoiding collisions. Do you have any recommendations here?
> > +#define KVM_REG_ARM_FW_BMAP_REG(r) (KVM_REG_ARM_FW_BMAP | (r))
>
> If you are still going to use the index offset, just pass 'r' through to
> the other macro:
>
> #define KVM_REG_ARM_FW_BMAP_REG(r) KVM_REG_ARM_FW_REG(0xff00 + r)
>
I'm sorry, what's the advantage of doing this?
> > +#define KVM_REG_ARM_STD_BMAP KVM_REG_ARM_FW_BMAP_REG(0)
> > +#define KVM_REG_ARM_STD_BIT_TRNG_V1_0 BIT(0)
> > +#define KVM_REG_ARM_STD_BMAP_BIT_MAX 0 /* Last valid bit */
>
> Implementation details such as this probably shouldn't live in UAPI
> headers. We'll likely need to bump the value in the future.
>
Wouldn't the macros act as helpers to userspace as well?
I agree with your point about the limited spacing, and we may need to
expand/shrink as needed, but isn't that a general register-space
problem?
> > +
> > /* SVE registers */
> > #define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
> >
> > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > index f61cd8d57eae..e9f9edb1cf55 100644
> > --- a/arch/arm64/kvm/arm.c
> > +++ b/arch/arm64/kvm/arm.c
> > @@ -156,6 +156,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> > kvm->arch.max_vcpus = kvm_arm_default_max_vcpus();
> >
> > set_default_spectre(kvm);
> > + kvm_arm_init_hypercalls(kvm);
> >
> > return ret;
> > out_free_stage2_pgd:
> > @@ -635,7 +636,14 @@ int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu)
> > if (kvm_vm_is_protected(kvm))
> > kvm_call_hyp_nvhe(__pkvm_vcpu_init_traps, vcpu);
> >
> > + /*
> > + * Grab kvm->lock such that the reader of has_run_once can finish
> > + * the necessary operation atomically, such as deciding whether to
> > + * block the writes to the firmware registers if the VM has run once.
> > + */
> > + mutex_lock(&kvm->lock);
> > kvm->arch.has_run_once = true;
> > + mutex_unlock(&kvm->lock);
>
> Shouldn't this have just grabbed the kvm lock in patch 04/13?
>
It could have, and I agree it's a little igly. But thinking that
there's are no parallel threads/consumers when it was initially
implemented gave me no reason to grab the locks.
> > return ret;
> > }
> > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> > index eb061e64a7a5..d66e6c742bbe 100644
> > --- a/arch/arm64/kvm/guest.c
> > +++ b/arch/arm64/kvm/guest.c
> > @@ -65,6 +65,7 @@ const struct kvm_stats_header kvm_vcpu_stats_header = {
> > static const u64 kvm_arm_vm_scope_fw_regs[] = {
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > + KVM_REG_ARM_STD_BMAP,
> > };
> >
> > /**
> > diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> > index 8624e6964940..48c126c3da72 100644
> > --- a/arch/arm64/kvm/hypercalls.c
> > +++ b/arch/arm64/kvm/hypercalls.c
> > @@ -58,6 +58,29 @@ static void kvm_ptp_get_time(struct kvm_vcpu *vcpu, u64 *val)
> > val[3] = lower_32_bits(cycles);
> > }
> >
> > +static bool kvm_arm_fw_reg_feat_enabled(u64 reg_bmap, u64 feat_bit)
> > +{
> > + return reg_bmap & feat_bit;
> > +}
> > +
> > +static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> > +{
> > + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> > +
> > + switch (func_id) {
> > + case ARM_SMCCC_TRNG_VERSION:
> > + case ARM_SMCCC_TRNG_FEATURES:
> > + case ARM_SMCCC_TRNG_GET_UUID:
> > + case ARM_SMCCC_TRNG_RND32:
> > + case ARM_SMCCC_TRNG_RND64:
> > + return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_bmap,
> > + KVM_REG_ARM_STD_BIT_TRNG_V1_0);
> > + default:
> > + /* By default, allow the services that aren't listed here */
> > + return true;
>
> I think your default case should really return false. It keeps people
> honest when they add new patches to set up a new hypercall bit (no bit?
> no call!)
>
> That of course requires that you only return false once all of the
> preexisting hypercalls are enumerated, otherwise such a patch would
> cause a regression in isolation.
>
I agree, but not all hypercalls may have a bit. For example, guarding
ARM_SMCCC_VERSION_FUNC_ID doesn't make sense and may not be gated by
the bit. Hence, the idea was to do an initial check if the func_id is
in fact gated. If yes, check the bit, else let the actual
implementation take care of it.
> > +}
> > +
> > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > {
> > u32 func_id = smccc_get_function(vcpu);
> > @@ -65,6 +88,9 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > u32 feature;
> > gpa_t gpa;
> >
> > + if (!kvm_hvc_call_supported(vcpu, func_id))
> > + goto out;
> > +
> > switch (func_id) {
> > case ARM_SMCCC_VERSION_FUNC_ID:
> > val[0] = ARM_SMCCC_VERSION_1_1;
> > @@ -143,6 +169,7 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > return kvm_psci_call(vcpu);
> > }
> >
> > +out:
> > smccc_set_retval(vcpu, val[0], val[1], val[2], val[3]);
> > return 1;
> > }
> > @@ -151,8 +178,16 @@ static const u64 kvm_arm_fw_reg_ids[] = {
> > KVM_REG_ARM_PSCI_VERSION,
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > + KVM_REG_ARM_STD_BMAP,
> > };
> >
> > +void kvm_arm_init_hypercalls(struct kvm *kvm)
> > +{
> > + struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
> > +
> > + hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
> > +}
> > +
> > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> > {
> > return ARRAY_SIZE(kvm_arm_fw_reg_ids);
> > @@ -220,6 +255,7 @@ static int get_kernel_wa_level(u64 regid)
> >
> > int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > {
> > + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> > void __user *uaddr = (void __user *)(long)reg->addr;
> > u64 val, reg_id = reg->id;
> >
> > @@ -233,6 +269,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> > val = get_kernel_wa_level(reg_id) & KVM_REG_FEATURE_LEVEL_MASK;
> > break;
> > + case KVM_REG_ARM_STD_BMAP:
> > + val = READ_ONCE(hvc_desc->hvc_std_bmap);
> > + break;
> > default:
> > return -ENOENT;
> > }
> > @@ -243,6 +282,43 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > return 0;
> > }
> >
> > +static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
> > +{
> > + int ret = 0;
> > + struct kvm *kvm = vcpu->kvm;
> > + struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
> > + u64 *fw_reg_bmap, fw_reg_features;
>
> nit: use reverse fir tree ordering for locals (longest line first,
> shortest last).
>
Got it.
> > + switch (reg_id) {
> > + case KVM_REG_ARM_STD_BMAP:
> > + fw_reg_bmap = &hvc_desc->hvc_std_bmap;
> > + fw_reg_features = ARM_SMCCC_STD_FEATURES;
> > + break;
> > + default:
> > + return -ENOENT;
> > + }
> > +
> > + /* Check for unsupported bit */
> > + if (val & ~fw_reg_features)
> > + return -EINVAL;
> > +
> > + mutex_lock(&kvm->lock);
> > +
> > + /*
> > + * If the VM (any vCPU) has already started running, return success
> > + * if there's no change in the value. Else, return -EBUSY.
>
> How about returning -EINVAL instead? We already do this for
> KVM_ARM_VCPU_INIT if userspace uses a different target than the one
> previously set.
>
Returning EBUSY could help userspace distinguish the cause of failure
better as compared to EINVAL, since technically, the arguments
supplied by the user are in fact valid. It's just that the timing is
wrong.
> > + */
> > + if (kvm_arm_vm_has_run_once(&kvm->arch)) {
> > + ret = *fw_reg_bmap != val ? -EBUSY : 0;
> > + goto out;
> > + }
> > +
> > + WRITE_ONCE(*fw_reg_bmap, val);
> > +out:
> > + mutex_unlock(&kvm->lock);
> > + return ret;
> > +}
> > +
> > int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > {
> > void __user *uaddr = (void __user *)(long)reg->addr;
> > @@ -321,6 +397,8 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > return -EINVAL;
> >
> > return 0;
> > + case KVM_REG_ARM_STD_BMAP:
> > + return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
> > default:
> > return -ENOENT;
> > }
> > diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> > index 5d38628a8d04..64d30b452809 100644
> > --- a/include/kvm/arm_hypercalls.h
> > +++ b/include/kvm/arm_hypercalls.h
> > @@ -6,6 +6,9 @@
> >
> > #include <asm/kvm_emulate.h>
> >
> > +#define ARM_SMCCC_STD_FEATURES \
> > + GENMASK_ULL(KVM_REG_ARM_STD_BMAP_BIT_MAX, 0)
> > +
>
> This probably needs KVM_ somewhere in its name for the sake of scoping.
>
RIght, I can append that.
> > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
> >
> > static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
> > @@ -42,6 +45,7 @@ static inline void smccc_set_retval(struct kvm_vcpu *vcpu,
> >
> > struct kvm_one_reg;
> >
> > +void kvm_arm_init_hypercalls(struct kvm *kvm);
> > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
> > int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
> > int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> > --
> > 2.35.1.473.g83b2b277ed-goog
> >
Regards,
Raghavendra
[1]: https://lore.kernel.org/linux-arm-kernel/CAJHc60y6b-scY8zcPuLnjGtr6HzSBnmhi2mCnmkNm4nTxgMTUQ@mail.gmail.com/
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 05/13] KVM: arm64: Setup a framework for hypercall bitmap firmware registers
@ 2022-03-15 0:22 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-03-15 0:22 UTC (permalink / raw)
To: Oliver Upton
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
Hi Oliver,
On Mon, Mar 14, 2022 at 12:41 PM Oliver Upton <oupton@google.com> wrote:
>
> On Thu, Feb 24, 2022 at 05:25:51PM +0000, Raghavendra Rao Ananta wrote:
> > KVM regularly introduces new hypercall services to the guests without
> > any consent from the userspace. This means, the guests can observe
> > hypercall services in and out as they migrate across various host
> > kernel versions. This could be a major problem if the guest
> > discovered a hypercall, started using it, and after getting migrated
> > to an older kernel realizes that it's no longer available. Depending
> > on how the guest handles the change, there's a potential chance that
> > the guest would just panic.
> >
> > As a result, there's a need for the userspace to elect the services
> > that it wishes the guest to discover. It can elect these services
> > based on the kernels spread across its (migration) fleet. To remedy
> > this, extend the existing firmware psuedo-registers, such as
> > KVM_REG_ARM_PSCI_VERSION, for all the hypercall services available.
> >
> > These firmware registers are categorized based on the service call
> > owners, and unlike the existing firmware psuedo-registers, they hold
> > the features supported in the form of a bitmap.
> >
> > During the VM initialization, the registers holds an upper-limit of
> > the features supported by the corresponding registers. It's expected
> > that the VMMs discover the features provided by each register via
> > GET_ONE_REG, and writeback the desired values using SET_ONE_REG.
> > KVM allows this modification only until the VM has started.
> >
> > Older userspace code can simply ignore the capability and the
> > hypercall services will be exposed unconditionally to the guests, thus
> > ensuring backward compatibility.
> >
> > In this patch, the framework adds the register only for ARM's standard
> > secure services (owner value 4). Currently, this includes support only
> > for ARM True Random Number Generator (TRNG) service, with bit-0 of the
> > register representing mandatory features of v1.0. The register is also
> > added to the kvm_arm_vm_scope_fw_regs[] list as it maintains its state
> > per-VM. Other services are momentarily added in the upcoming patches.
> >
> > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > ---
> > arch/arm64/include/asm/kvm_host.h | 12 +++++
> > arch/arm64/include/uapi/asm/kvm.h | 8 ++++
> > arch/arm64/kvm/arm.c | 8 ++++
> > arch/arm64/kvm/guest.c | 1 +
> > arch/arm64/kvm/hypercalls.c | 78 +++++++++++++++++++++++++++++++
> > include/kvm/arm_hypercalls.h | 4 ++
> > 6 files changed, 111 insertions(+)
> >
> > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > index e823571e50cc..1909ced3208f 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -101,6 +101,15 @@ struct kvm_s2_mmu {
> > struct kvm_arch_memory_slot {
> > };
> >
> > +/**
> > + * struct kvm_hvc_desc: KVM ARM64 hypercall descriptor
> > + *
> > + * @hvc_std_bmap: Bitmap of standard secure service calls
> > + */
> > +struct kvm_hvc_desc {
>
> nit: maybe call this structure kvm_hypercall_features? When nested comes
> along guests will need to use the SVC conduit as HVC traps are always
> taken to EL2. Same will need to be true for virtual EL2.
>
Sure, I can rename it to be more generic.
> > + u64 hvc_std_bmap;
> > +};
> > +
> > struct kvm_arch {
> > struct kvm_s2_mmu mmu;
> >
> > @@ -142,6 +151,9 @@ struct kvm_arch {
> >
> > /* Capture first run of the VM */
> > bool has_run_once;
> > +
> > + /* Hypercall firmware register' descriptor */
> > + struct kvm_hvc_desc hvc_desc;
> > };
> >
> > struct kvm_vcpu_fault_info {
> > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > index c35447cc0e0c..2decc30d6b84 100644
> > --- a/arch/arm64/include/uapi/asm/kvm.h
> > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > @@ -287,6 +287,14 @@ struct kvm_arm_copy_mte_tags {
> > #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED 3
> > #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED (1U << 4)
> >
> > +/* Bitmap firmware registers, extension to the existing psuedo-register space */
> > +#define KVM_REG_ARM_FW_BMAP KVM_REG_ARM_FW_REG(0xff00)
>
> What is the motivation for moving the bitmap register indices so far
> away from the rest of the firmware regs?
>
The original motivation to create a sub-space came from Reiji's
comment on v3 [1] so that user-space can distinguish between bitmapped
and regular fw registers.
As with the spacing, I thought a 50/50 split would do a good job of
avoiding collisions. Do you have any recommendations here?
> > +#define KVM_REG_ARM_FW_BMAP_REG(r) (KVM_REG_ARM_FW_BMAP | (r))
>
> If you are still going to use the index offset, just pass 'r' through to
> the other macro:
>
> #define KVM_REG_ARM_FW_BMAP_REG(r) KVM_REG_ARM_FW_REG(0xff00 + r)
>
I'm sorry, what's the advantage of doing this?
> > +#define KVM_REG_ARM_STD_BMAP KVM_REG_ARM_FW_BMAP_REG(0)
> > +#define KVM_REG_ARM_STD_BIT_TRNG_V1_0 BIT(0)
> > +#define KVM_REG_ARM_STD_BMAP_BIT_MAX 0 /* Last valid bit */
>
> Implementation details such as this probably shouldn't live in UAPI
> headers. We'll likely need to bump the value in the future.
>
Wouldn't the macros act as helpers to userspace as well?
I agree with your point about the limited spacing, and we may need to
expand/shrink as needed, but isn't that a general register-space
problem?
> > +
> > /* SVE registers */
> > #define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
> >
> > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > index f61cd8d57eae..e9f9edb1cf55 100644
> > --- a/arch/arm64/kvm/arm.c
> > +++ b/arch/arm64/kvm/arm.c
> > @@ -156,6 +156,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> > kvm->arch.max_vcpus = kvm_arm_default_max_vcpus();
> >
> > set_default_spectre(kvm);
> > + kvm_arm_init_hypercalls(kvm);
> >
> > return ret;
> > out_free_stage2_pgd:
> > @@ -635,7 +636,14 @@ int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu)
> > if (kvm_vm_is_protected(kvm))
> > kvm_call_hyp_nvhe(__pkvm_vcpu_init_traps, vcpu);
> >
> > + /*
> > + * Grab kvm->lock such that the reader of has_run_once can finish
> > + * the necessary operation atomically, such as deciding whether to
> > + * block the writes to the firmware registers if the VM has run once.
> > + */
> > + mutex_lock(&kvm->lock);
> > kvm->arch.has_run_once = true;
> > + mutex_unlock(&kvm->lock);
>
> Shouldn't this have just grabbed the kvm lock in patch 04/13?
>
It could have, and I agree it's a little igly. But thinking that
there's are no parallel threads/consumers when it was initially
implemented gave me no reason to grab the locks.
> > return ret;
> > }
> > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> > index eb061e64a7a5..d66e6c742bbe 100644
> > --- a/arch/arm64/kvm/guest.c
> > +++ b/arch/arm64/kvm/guest.c
> > @@ -65,6 +65,7 @@ const struct kvm_stats_header kvm_vcpu_stats_header = {
> > static const u64 kvm_arm_vm_scope_fw_regs[] = {
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > + KVM_REG_ARM_STD_BMAP,
> > };
> >
> > /**
> > diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> > index 8624e6964940..48c126c3da72 100644
> > --- a/arch/arm64/kvm/hypercalls.c
> > +++ b/arch/arm64/kvm/hypercalls.c
> > @@ -58,6 +58,29 @@ static void kvm_ptp_get_time(struct kvm_vcpu *vcpu, u64 *val)
> > val[3] = lower_32_bits(cycles);
> > }
> >
> > +static bool kvm_arm_fw_reg_feat_enabled(u64 reg_bmap, u64 feat_bit)
> > +{
> > + return reg_bmap & feat_bit;
> > +}
> > +
> > +static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> > +{
> > + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> > +
> > + switch (func_id) {
> > + case ARM_SMCCC_TRNG_VERSION:
> > + case ARM_SMCCC_TRNG_FEATURES:
> > + case ARM_SMCCC_TRNG_GET_UUID:
> > + case ARM_SMCCC_TRNG_RND32:
> > + case ARM_SMCCC_TRNG_RND64:
> > + return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_bmap,
> > + KVM_REG_ARM_STD_BIT_TRNG_V1_0);
> > + default:
> > + /* By default, allow the services that aren't listed here */
> > + return true;
>
> I think your default case should really return false. It keeps people
> honest when they add new patches to set up a new hypercall bit (no bit?
> no call!)
>
> That of course requires that you only return false once all of the
> preexisting hypercalls are enumerated, otherwise such a patch would
> cause a regression in isolation.
>
I agree, but not all hypercalls may have a bit. For example, guarding
ARM_SMCCC_VERSION_FUNC_ID doesn't make sense and may not be gated by
the bit. Hence, the idea was to do an initial check if the func_id is
in fact gated. If yes, check the bit, else let the actual
implementation take care of it.
> > +}
> > +
> > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > {
> > u32 func_id = smccc_get_function(vcpu);
> > @@ -65,6 +88,9 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > u32 feature;
> > gpa_t gpa;
> >
> > + if (!kvm_hvc_call_supported(vcpu, func_id))
> > + goto out;
> > +
> > switch (func_id) {
> > case ARM_SMCCC_VERSION_FUNC_ID:
> > val[0] = ARM_SMCCC_VERSION_1_1;
> > @@ -143,6 +169,7 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > return kvm_psci_call(vcpu);
> > }
> >
> > +out:
> > smccc_set_retval(vcpu, val[0], val[1], val[2], val[3]);
> > return 1;
> > }
> > @@ -151,8 +178,16 @@ static const u64 kvm_arm_fw_reg_ids[] = {
> > KVM_REG_ARM_PSCI_VERSION,
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > + KVM_REG_ARM_STD_BMAP,
> > };
> >
> > +void kvm_arm_init_hypercalls(struct kvm *kvm)
> > +{
> > + struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
> > +
> > + hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
> > +}
> > +
> > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> > {
> > return ARRAY_SIZE(kvm_arm_fw_reg_ids);
> > @@ -220,6 +255,7 @@ static int get_kernel_wa_level(u64 regid)
> >
> > int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > {
> > + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> > void __user *uaddr = (void __user *)(long)reg->addr;
> > u64 val, reg_id = reg->id;
> >
> > @@ -233,6 +269,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> > val = get_kernel_wa_level(reg_id) & KVM_REG_FEATURE_LEVEL_MASK;
> > break;
> > + case KVM_REG_ARM_STD_BMAP:
> > + val = READ_ONCE(hvc_desc->hvc_std_bmap);
> > + break;
> > default:
> > return -ENOENT;
> > }
> > @@ -243,6 +282,43 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > return 0;
> > }
> >
> > +static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
> > +{
> > + int ret = 0;
> > + struct kvm *kvm = vcpu->kvm;
> > + struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
> > + u64 *fw_reg_bmap, fw_reg_features;
>
> nit: use reverse fir tree ordering for locals (longest line first,
> shortest last).
>
Got it.
> > + switch (reg_id) {
> > + case KVM_REG_ARM_STD_BMAP:
> > + fw_reg_bmap = &hvc_desc->hvc_std_bmap;
> > + fw_reg_features = ARM_SMCCC_STD_FEATURES;
> > + break;
> > + default:
> > + return -ENOENT;
> > + }
> > +
> > + /* Check for unsupported bit */
> > + if (val & ~fw_reg_features)
> > + return -EINVAL;
> > +
> > + mutex_lock(&kvm->lock);
> > +
> > + /*
> > + * If the VM (any vCPU) has already started running, return success
> > + * if there's no change in the value. Else, return -EBUSY.
>
> How about returning -EINVAL instead? We already do this for
> KVM_ARM_VCPU_INIT if userspace uses a different target than the one
> previously set.
>
Returning EBUSY could help userspace distinguish the cause of failure
better as compared to EINVAL, since technically, the arguments
supplied by the user are in fact valid. It's just that the timing is
wrong.
> > + */
> > + if (kvm_arm_vm_has_run_once(&kvm->arch)) {
> > + ret = *fw_reg_bmap != val ? -EBUSY : 0;
> > + goto out;
> > + }
> > +
> > + WRITE_ONCE(*fw_reg_bmap, val);
> > +out:
> > + mutex_unlock(&kvm->lock);
> > + return ret;
> > +}
> > +
> > int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > {
> > void __user *uaddr = (void __user *)(long)reg->addr;
> > @@ -321,6 +397,8 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > return -EINVAL;
> >
> > return 0;
> > + case KVM_REG_ARM_STD_BMAP:
> > + return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
> > default:
> > return -ENOENT;
> > }
> > diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> > index 5d38628a8d04..64d30b452809 100644
> > --- a/include/kvm/arm_hypercalls.h
> > +++ b/include/kvm/arm_hypercalls.h
> > @@ -6,6 +6,9 @@
> >
> > #include <asm/kvm_emulate.h>
> >
> > +#define ARM_SMCCC_STD_FEATURES \
> > + GENMASK_ULL(KVM_REG_ARM_STD_BMAP_BIT_MAX, 0)
> > +
>
> This probably needs KVM_ somewhere in its name for the sake of scoping.
>
RIght, I can append that.
> > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
> >
> > static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
> > @@ -42,6 +45,7 @@ static inline void smccc_set_retval(struct kvm_vcpu *vcpu,
> >
> > struct kvm_one_reg;
> >
> > +void kvm_arm_init_hypercalls(struct kvm *kvm);
> > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
> > int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
> > int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> > --
> > 2.35.1.473.g83b2b277ed-goog
> >
Regards,
Raghavendra
[1]: https://lore.kernel.org/linux-arm-kernel/CAJHc60y6b-scY8zcPuLnjGtr6HzSBnmhi2mCnmkNm4nTxgMTUQ@mail.gmail.com/
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 05/13] KVM: arm64: Setup a framework for hypercall bitmap firmware registers
@ 2022-03-15 0:22 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-03-15 0:22 UTC (permalink / raw)
To: Oliver Upton
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
Hi Oliver,
On Mon, Mar 14, 2022 at 12:41 PM Oliver Upton <oupton@google.com> wrote:
>
> On Thu, Feb 24, 2022 at 05:25:51PM +0000, Raghavendra Rao Ananta wrote:
> > KVM regularly introduces new hypercall services to the guests without
> > any consent from the userspace. This means, the guests can observe
> > hypercall services in and out as they migrate across various host
> > kernel versions. This could be a major problem if the guest
> > discovered a hypercall, started using it, and after getting migrated
> > to an older kernel realizes that it's no longer available. Depending
> > on how the guest handles the change, there's a potential chance that
> > the guest would just panic.
> >
> > As a result, there's a need for the userspace to elect the services
> > that it wishes the guest to discover. It can elect these services
> > based on the kernels spread across its (migration) fleet. To remedy
> > this, extend the existing firmware psuedo-registers, such as
> > KVM_REG_ARM_PSCI_VERSION, for all the hypercall services available.
> >
> > These firmware registers are categorized based on the service call
> > owners, and unlike the existing firmware psuedo-registers, they hold
> > the features supported in the form of a bitmap.
> >
> > During the VM initialization, the registers holds an upper-limit of
> > the features supported by the corresponding registers. It's expected
> > that the VMMs discover the features provided by each register via
> > GET_ONE_REG, and writeback the desired values using SET_ONE_REG.
> > KVM allows this modification only until the VM has started.
> >
> > Older userspace code can simply ignore the capability and the
> > hypercall services will be exposed unconditionally to the guests, thus
> > ensuring backward compatibility.
> >
> > In this patch, the framework adds the register only for ARM's standard
> > secure services (owner value 4). Currently, this includes support only
> > for ARM True Random Number Generator (TRNG) service, with bit-0 of the
> > register representing mandatory features of v1.0. The register is also
> > added to the kvm_arm_vm_scope_fw_regs[] list as it maintains its state
> > per-VM. Other services are momentarily added in the upcoming patches.
> >
> > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > ---
> > arch/arm64/include/asm/kvm_host.h | 12 +++++
> > arch/arm64/include/uapi/asm/kvm.h | 8 ++++
> > arch/arm64/kvm/arm.c | 8 ++++
> > arch/arm64/kvm/guest.c | 1 +
> > arch/arm64/kvm/hypercalls.c | 78 +++++++++++++++++++++++++++++++
> > include/kvm/arm_hypercalls.h | 4 ++
> > 6 files changed, 111 insertions(+)
> >
> > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > index e823571e50cc..1909ced3208f 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -101,6 +101,15 @@ struct kvm_s2_mmu {
> > struct kvm_arch_memory_slot {
> > };
> >
> > +/**
> > + * struct kvm_hvc_desc: KVM ARM64 hypercall descriptor
> > + *
> > + * @hvc_std_bmap: Bitmap of standard secure service calls
> > + */
> > +struct kvm_hvc_desc {
>
> nit: maybe call this structure kvm_hypercall_features? When nested comes
> along guests will need to use the SVC conduit as HVC traps are always
> taken to EL2. Same will need to be true for virtual EL2.
>
Sure, I can rename it to be more generic.
> > + u64 hvc_std_bmap;
> > +};
> > +
> > struct kvm_arch {
> > struct kvm_s2_mmu mmu;
> >
> > @@ -142,6 +151,9 @@ struct kvm_arch {
> >
> > /* Capture first run of the VM */
> > bool has_run_once;
> > +
> > + /* Hypercall firmware register' descriptor */
> > + struct kvm_hvc_desc hvc_desc;
> > };
> >
> > struct kvm_vcpu_fault_info {
> > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > index c35447cc0e0c..2decc30d6b84 100644
> > --- a/arch/arm64/include/uapi/asm/kvm.h
> > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > @@ -287,6 +287,14 @@ struct kvm_arm_copy_mte_tags {
> > #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED 3
> > #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED (1U << 4)
> >
> > +/* Bitmap firmware registers, extension to the existing psuedo-register space */
> > +#define KVM_REG_ARM_FW_BMAP KVM_REG_ARM_FW_REG(0xff00)
>
> What is the motivation for moving the bitmap register indices so far
> away from the rest of the firmware regs?
>
The original motivation to create a sub-space came from Reiji's
comment on v3 [1] so that user-space can distinguish between bitmapped
and regular fw registers.
As with the spacing, I thought a 50/50 split would do a good job of
avoiding collisions. Do you have any recommendations here?
> > +#define KVM_REG_ARM_FW_BMAP_REG(r) (KVM_REG_ARM_FW_BMAP | (r))
>
> If you are still going to use the index offset, just pass 'r' through to
> the other macro:
>
> #define KVM_REG_ARM_FW_BMAP_REG(r) KVM_REG_ARM_FW_REG(0xff00 + r)
>
I'm sorry, what's the advantage of doing this?
> > +#define KVM_REG_ARM_STD_BMAP KVM_REG_ARM_FW_BMAP_REG(0)
> > +#define KVM_REG_ARM_STD_BIT_TRNG_V1_0 BIT(0)
> > +#define KVM_REG_ARM_STD_BMAP_BIT_MAX 0 /* Last valid bit */
>
> Implementation details such as this probably shouldn't live in UAPI
> headers. We'll likely need to bump the value in the future.
>
Wouldn't the macros act as helpers to userspace as well?
I agree with your point about the limited spacing, and we may need to
expand/shrink as needed, but isn't that a general register-space
problem?
> > +
> > /* SVE registers */
> > #define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
> >
> > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > index f61cd8d57eae..e9f9edb1cf55 100644
> > --- a/arch/arm64/kvm/arm.c
> > +++ b/arch/arm64/kvm/arm.c
> > @@ -156,6 +156,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> > kvm->arch.max_vcpus = kvm_arm_default_max_vcpus();
> >
> > set_default_spectre(kvm);
> > + kvm_arm_init_hypercalls(kvm);
> >
> > return ret;
> > out_free_stage2_pgd:
> > @@ -635,7 +636,14 @@ int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu)
> > if (kvm_vm_is_protected(kvm))
> > kvm_call_hyp_nvhe(__pkvm_vcpu_init_traps, vcpu);
> >
> > + /*
> > + * Grab kvm->lock such that the reader of has_run_once can finish
> > + * the necessary operation atomically, such as deciding whether to
> > + * block the writes to the firmware registers if the VM has run once.
> > + */
> > + mutex_lock(&kvm->lock);
> > kvm->arch.has_run_once = true;
> > + mutex_unlock(&kvm->lock);
>
> Shouldn't this have just grabbed the kvm lock in patch 04/13?
>
It could have, and I agree it's a little igly. But thinking that
there's are no parallel threads/consumers when it was initially
implemented gave me no reason to grab the locks.
> > return ret;
> > }
> > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> > index eb061e64a7a5..d66e6c742bbe 100644
> > --- a/arch/arm64/kvm/guest.c
> > +++ b/arch/arm64/kvm/guest.c
> > @@ -65,6 +65,7 @@ const struct kvm_stats_header kvm_vcpu_stats_header = {
> > static const u64 kvm_arm_vm_scope_fw_regs[] = {
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > + KVM_REG_ARM_STD_BMAP,
> > };
> >
> > /**
> > diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> > index 8624e6964940..48c126c3da72 100644
> > --- a/arch/arm64/kvm/hypercalls.c
> > +++ b/arch/arm64/kvm/hypercalls.c
> > @@ -58,6 +58,29 @@ static void kvm_ptp_get_time(struct kvm_vcpu *vcpu, u64 *val)
> > val[3] = lower_32_bits(cycles);
> > }
> >
> > +static bool kvm_arm_fw_reg_feat_enabled(u64 reg_bmap, u64 feat_bit)
> > +{
> > + return reg_bmap & feat_bit;
> > +}
> > +
> > +static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> > +{
> > + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> > +
> > + switch (func_id) {
> > + case ARM_SMCCC_TRNG_VERSION:
> > + case ARM_SMCCC_TRNG_FEATURES:
> > + case ARM_SMCCC_TRNG_GET_UUID:
> > + case ARM_SMCCC_TRNG_RND32:
> > + case ARM_SMCCC_TRNG_RND64:
> > + return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_bmap,
> > + KVM_REG_ARM_STD_BIT_TRNG_V1_0);
> > + default:
> > + /* By default, allow the services that aren't listed here */
> > + return true;
>
> I think your default case should really return false. It keeps people
> honest when they add new patches to set up a new hypercall bit (no bit?
> no call!)
>
> That of course requires that you only return false once all of the
> preexisting hypercalls are enumerated, otherwise such a patch would
> cause a regression in isolation.
>
I agree, but not all hypercalls may have a bit. For example, guarding
ARM_SMCCC_VERSION_FUNC_ID doesn't make sense and may not be gated by
the bit. Hence, the idea was to do an initial check if the func_id is
in fact gated. If yes, check the bit, else let the actual
implementation take care of it.
> > +}
> > +
> > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > {
> > u32 func_id = smccc_get_function(vcpu);
> > @@ -65,6 +88,9 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > u32 feature;
> > gpa_t gpa;
> >
> > + if (!kvm_hvc_call_supported(vcpu, func_id))
> > + goto out;
> > +
> > switch (func_id) {
> > case ARM_SMCCC_VERSION_FUNC_ID:
> > val[0] = ARM_SMCCC_VERSION_1_1;
> > @@ -143,6 +169,7 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > return kvm_psci_call(vcpu);
> > }
> >
> > +out:
> > smccc_set_retval(vcpu, val[0], val[1], val[2], val[3]);
> > return 1;
> > }
> > @@ -151,8 +178,16 @@ static const u64 kvm_arm_fw_reg_ids[] = {
> > KVM_REG_ARM_PSCI_VERSION,
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > + KVM_REG_ARM_STD_BMAP,
> > };
> >
> > +void kvm_arm_init_hypercalls(struct kvm *kvm)
> > +{
> > + struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
> > +
> > + hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
> > +}
> > +
> > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> > {
> > return ARRAY_SIZE(kvm_arm_fw_reg_ids);
> > @@ -220,6 +255,7 @@ static int get_kernel_wa_level(u64 regid)
> >
> > int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > {
> > + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> > void __user *uaddr = (void __user *)(long)reg->addr;
> > u64 val, reg_id = reg->id;
> >
> > @@ -233,6 +269,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> > val = get_kernel_wa_level(reg_id) & KVM_REG_FEATURE_LEVEL_MASK;
> > break;
> > + case KVM_REG_ARM_STD_BMAP:
> > + val = READ_ONCE(hvc_desc->hvc_std_bmap);
> > + break;
> > default:
> > return -ENOENT;
> > }
> > @@ -243,6 +282,43 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > return 0;
> > }
> >
> > +static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
> > +{
> > + int ret = 0;
> > + struct kvm *kvm = vcpu->kvm;
> > + struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
> > + u64 *fw_reg_bmap, fw_reg_features;
>
> nit: use reverse fir tree ordering for locals (longest line first,
> shortest last).
>
Got it.
> > + switch (reg_id) {
> > + case KVM_REG_ARM_STD_BMAP:
> > + fw_reg_bmap = &hvc_desc->hvc_std_bmap;
> > + fw_reg_features = ARM_SMCCC_STD_FEATURES;
> > + break;
> > + default:
> > + return -ENOENT;
> > + }
> > +
> > + /* Check for unsupported bit */
> > + if (val & ~fw_reg_features)
> > + return -EINVAL;
> > +
> > + mutex_lock(&kvm->lock);
> > +
> > + /*
> > + * If the VM (any vCPU) has already started running, return success
> > + * if there's no change in the value. Else, return -EBUSY.
>
> How about returning -EINVAL instead? We already do this for
> KVM_ARM_VCPU_INIT if userspace uses a different target than the one
> previously set.
>
Returning EBUSY could help userspace distinguish the cause of failure
better as compared to EINVAL, since technically, the arguments
supplied by the user are in fact valid. It's just that the timing is
wrong.
> > + */
> > + if (kvm_arm_vm_has_run_once(&kvm->arch)) {
> > + ret = *fw_reg_bmap != val ? -EBUSY : 0;
> > + goto out;
> > + }
> > +
> > + WRITE_ONCE(*fw_reg_bmap, val);
> > +out:
> > + mutex_unlock(&kvm->lock);
> > + return ret;
> > +}
> > +
> > int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > {
> > void __user *uaddr = (void __user *)(long)reg->addr;
> > @@ -321,6 +397,8 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > return -EINVAL;
> >
> > return 0;
> > + case KVM_REG_ARM_STD_BMAP:
> > + return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
> > default:
> > return -ENOENT;
> > }
> > diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> > index 5d38628a8d04..64d30b452809 100644
> > --- a/include/kvm/arm_hypercalls.h
> > +++ b/include/kvm/arm_hypercalls.h
> > @@ -6,6 +6,9 @@
> >
> > #include <asm/kvm_emulate.h>
> >
> > +#define ARM_SMCCC_STD_FEATURES \
> > + GENMASK_ULL(KVM_REG_ARM_STD_BMAP_BIT_MAX, 0)
> > +
>
> This probably needs KVM_ somewhere in its name for the sake of scoping.
>
RIght, I can append that.
> > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
> >
> > static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
> > @@ -42,6 +45,7 @@ static inline void smccc_set_retval(struct kvm_vcpu *vcpu,
> >
> > struct kvm_one_reg;
> >
> > +void kvm_arm_init_hypercalls(struct kvm *kvm);
> > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
> > int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
> > int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> > --
> > 2.35.1.473.g83b2b277ed-goog
> >
Regards,
Raghavendra
[1]: https://lore.kernel.org/linux-arm-kernel/CAJHc60y6b-scY8zcPuLnjGtr6HzSBnmhi2mCnmkNm4nTxgMTUQ@mail.gmail.com/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 05/13] KVM: arm64: Setup a framework for hypercall bitmap firmware registers
2022-03-15 0:22 ` Raghavendra Rao Ananta
(?)
@ 2022-03-15 7:25 ` Oliver Upton
-1 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-15 7:25 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: kvm, Will Deacon, Marc Zyngier, Peter Shier, linux-kernel,
Catalin Marinas, Paolo Bonzini, kvmarm, linux-arm-kernel
On Mon, Mar 14, 2022 at 05:22:31PM -0700, Raghavendra Rao Ananta wrote:
> Hi Oliver,
>
> On Mon, Mar 14, 2022 at 12:41 PM Oliver Upton <oupton@google.com> wrote:
> >
> > On Thu, Feb 24, 2022 at 05:25:51PM +0000, Raghavendra Rao Ananta wrote:
> > > KVM regularly introduces new hypercall services to the guests without
> > > any consent from the userspace. This means, the guests can observe
> > > hypercall services in and out as they migrate across various host
> > > kernel versions. This could be a major problem if the guest
> > > discovered a hypercall, started using it, and after getting migrated
> > > to an older kernel realizes that it's no longer available. Depending
> > > on how the guest handles the change, there's a potential chance that
> > > the guest would just panic.
> > >
> > > As a result, there's a need for the userspace to elect the services
> > > that it wishes the guest to discover. It can elect these services
> > > based on the kernels spread across its (migration) fleet. To remedy
> > > this, extend the existing firmware psuedo-registers, such as
> > > KVM_REG_ARM_PSCI_VERSION, for all the hypercall services available.
> > >
> > > These firmware registers are categorized based on the service call
> > > owners, and unlike the existing firmware psuedo-registers, they hold
> > > the features supported in the form of a bitmap.
> > >
> > > During the VM initialization, the registers holds an upper-limit of
> > > the features supported by the corresponding registers. It's expected
> > > that the VMMs discover the features provided by each register via
> > > GET_ONE_REG, and writeback the desired values using SET_ONE_REG.
> > > KVM allows this modification only until the VM has started.
> > >
> > > Older userspace code can simply ignore the capability and the
> > > hypercall services will be exposed unconditionally to the guests, thus
> > > ensuring backward compatibility.
> > >
> > > In this patch, the framework adds the register only for ARM's standard
> > > secure services (owner value 4). Currently, this includes support only
> > > for ARM True Random Number Generator (TRNG) service, with bit-0 of the
> > > register representing mandatory features of v1.0. The register is also
> > > added to the kvm_arm_vm_scope_fw_regs[] list as it maintains its state
> > > per-VM. Other services are momentarily added in the upcoming patches.
> > >
> > > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > > ---
> > > arch/arm64/include/asm/kvm_host.h | 12 +++++
> > > arch/arm64/include/uapi/asm/kvm.h | 8 ++++
> > > arch/arm64/kvm/arm.c | 8 ++++
> > > arch/arm64/kvm/guest.c | 1 +
> > > arch/arm64/kvm/hypercalls.c | 78 +++++++++++++++++++++++++++++++
> > > include/kvm/arm_hypercalls.h | 4 ++
> > > 6 files changed, 111 insertions(+)
> > >
> > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > > index e823571e50cc..1909ced3208f 100644
> > > --- a/arch/arm64/include/asm/kvm_host.h
> > > +++ b/arch/arm64/include/asm/kvm_host.h
> > > @@ -101,6 +101,15 @@ struct kvm_s2_mmu {
> > > struct kvm_arch_memory_slot {
> > > };
> > >
> > > +/**
> > > + * struct kvm_hvc_desc: KVM ARM64 hypercall descriptor
> > > + *
> > > + * @hvc_std_bmap: Bitmap of standard secure service calls
> > > + */
> > > +struct kvm_hvc_desc {
> >
> > nit: maybe call this structure kvm_hypercall_features? When nested comes
> > along guests will need to use the SVC conduit as HVC traps are always
> > taken to EL2. Same will need to be true for virtual EL2.
> >
> Sure, I can rename it to be more generic.
>
> > > + u64 hvc_std_bmap;
> > > +};
> > > +
> > > struct kvm_arch {
> > > struct kvm_s2_mmu mmu;
> > >
> > > @@ -142,6 +151,9 @@ struct kvm_arch {
> > >
> > > /* Capture first run of the VM */
> > > bool has_run_once;
> > > +
> > > + /* Hypercall firmware register' descriptor */
> > > + struct kvm_hvc_desc hvc_desc;
> > > };
> > >
> > > struct kvm_vcpu_fault_info {
> > > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > > index c35447cc0e0c..2decc30d6b84 100644
> > > --- a/arch/arm64/include/uapi/asm/kvm.h
> > > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > > @@ -287,6 +287,14 @@ struct kvm_arm_copy_mte_tags {
> > > #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED 3
> > > #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED (1U << 4)
> > >
> > > +/* Bitmap firmware registers, extension to the existing psuedo-register space */
> > > +#define KVM_REG_ARM_FW_BMAP KVM_REG_ARM_FW_REG(0xff00)
> >
> > What is the motivation for moving the bitmap register indices so far
> > away from the rest of the firmware regs?
> >
> The original motivation to create a sub-space came from Reiji's
> comment on v3 [1] so that user-space can distinguish between bitmapped
> and regular fw registers.
> As with the spacing, I thought a 50/50 split would do a good job of
> avoiding collisions. Do you have any recommendations here?
>
I see. This is for the sake of ABI stability with future expansion,
right? A new register could be added in the future that controls more
SMCCC features, and we expect userspace to zero them if it cares about
ABI stability.
If that is all true, we probably need some strong supporting
documentation. Additionally, using a new COPROC value for the register
range might be better than partitioning the existing FW reg range.
> > > +#define KVM_REG_ARM_FW_BMAP_REG(r) (KVM_REG_ARM_FW_BMAP | (r))
> >
> > If you are still going to use the index offset, just pass 'r' through to
> > the other macro:
> >
> > #define KVM_REG_ARM_FW_BMAP_REG(r) KVM_REG_ARM_FW_REG(0xff00 + r)
> >
> I'm sorry, what's the advantage of doing this?
>
> > > +#define KVM_REG_ARM_STD_BMAP KVM_REG_ARM_FW_BMAP_REG(0)
> > > +#define KVM_REG_ARM_STD_BIT_TRNG_V1_0 BIT(0)
> > > +#define KVM_REG_ARM_STD_BMAP_BIT_MAX 0 /* Last valid bit */
> >
> > Implementation details such as this probably shouldn't live in UAPI
> > headers. We'll likely need to bump the value in the future.
> >
> Wouldn't the macros act as helpers to userspace as well?
> I agree with your point about the limited spacing, and we may need to
> expand/shrink as needed, but isn't that a general register-space
> problem?
>
I think that the kernel's responsibility to userspace starts and ends with
enumerating the register bits. Those values remain invariant on future
KVM. On the other hand, you'll need to bump the _MAX value every time
you add to the register. Between documentation and bit definitions,
userspace should have enough info to work out the rest on its own :)
> > > +
> > > /* SVE registers */
> > > #define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
> > >
> > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > > index f61cd8d57eae..e9f9edb1cf55 100644
> > > --- a/arch/arm64/kvm/arm.c
> > > +++ b/arch/arm64/kvm/arm.c
> > > @@ -156,6 +156,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> > > kvm->arch.max_vcpus = kvm_arm_default_max_vcpus();
> > >
> > > set_default_spectre(kvm);
> > > + kvm_arm_init_hypercalls(kvm);
> > >
> > > return ret;
> > > out_free_stage2_pgd:
> > > @@ -635,7 +636,14 @@ int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu)
> > > if (kvm_vm_is_protected(kvm))
> > > kvm_call_hyp_nvhe(__pkvm_vcpu_init_traps, vcpu);
> > >
> > > + /*
> > > + * Grab kvm->lock such that the reader of has_run_once can finish
> > > + * the necessary operation atomically, such as deciding whether to
> > > + * block the writes to the firmware registers if the VM has run once.
> > > + */
> > > + mutex_lock(&kvm->lock);
> > > kvm->arch.has_run_once = true;
> > > + mutex_unlock(&kvm->lock);
> >
> > Shouldn't this have just grabbed the kvm lock in patch 04/13?
> >
> It could have, and I agree it's a little igly. But thinking that
> there's are no parallel threads/consumers when it was initially
> implemented gave me no reason to grab the locks.
I see, I was just curious if there was something I had missed.
> > > return ret;
> > > }
> > > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> > > index eb061e64a7a5..d66e6c742bbe 100644
> > > --- a/arch/arm64/kvm/guest.c
> > > +++ b/arch/arm64/kvm/guest.c
> > > @@ -65,6 +65,7 @@ const struct kvm_stats_header kvm_vcpu_stats_header = {
> > > static const u64 kvm_arm_vm_scope_fw_regs[] = {
> > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > > + KVM_REG_ARM_STD_BMAP,
> > > };
> > >
> > > /**
> > > diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> > > index 8624e6964940..48c126c3da72 100644
> > > --- a/arch/arm64/kvm/hypercalls.c
> > > +++ b/arch/arm64/kvm/hypercalls.c
> > > @@ -58,6 +58,29 @@ static void kvm_ptp_get_time(struct kvm_vcpu *vcpu, u64 *val)
> > > val[3] = lower_32_bits(cycles);
> > > }
> > >
> > > +static bool kvm_arm_fw_reg_feat_enabled(u64 reg_bmap, u64 feat_bit)
> > > +{
> > > + return reg_bmap & feat_bit;
> > > +}
> > > +
> > > +static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> > > +{
> > > + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> > > +
> > > + switch (func_id) {
> > > + case ARM_SMCCC_TRNG_VERSION:
> > > + case ARM_SMCCC_TRNG_FEATURES:
> > > + case ARM_SMCCC_TRNG_GET_UUID:
> > > + case ARM_SMCCC_TRNG_RND32:
> > > + case ARM_SMCCC_TRNG_RND64:
> > > + return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_bmap,
> > > + KVM_REG_ARM_STD_BIT_TRNG_V1_0);
> > > + default:
> > > + /* By default, allow the services that aren't listed here */
> > > + return true;
> >
> > I think your default case should really return false. It keeps people
> > honest when they add new patches to set up a new hypercall bit (no bit?
> > no call!)
> >
> > That of course requires that you only return false once all of the
> > preexisting hypercalls are enumerated, otherwise such a patch would
> > cause a regression in isolation.
> >
> I agree, but not all hypercalls may have a bit. For example, guarding
> ARM_SMCCC_VERSION_FUNC_ID doesn't make sense and may not be gated by
> the bit. Hence, the idea was to do an initial check if the func_id is
> in fact gated. If yes, check the bit, else let the actual
> implementation take care of it.
The set of hypercalls that are not under userspace control need to exist
on an allowlist then. Any new hypercall after the introduction of these
registers must have a bit assigned then, right? Otherwise it would seem
that new hypercalls could sneak into the guest ABI when migrating to an
upgraded kernel.
>
> > > +}
> > > +
> > > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > > {
> > > u32 func_id = smccc_get_function(vcpu);
> > > @@ -65,6 +88,9 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > > u32 feature;
> > > gpa_t gpa;
> > >
> > > + if (!kvm_hvc_call_supported(vcpu, func_id))
> > > + goto out;
> > > +
> > > switch (func_id) {
> > > case ARM_SMCCC_VERSION_FUNC_ID:
> > > val[0] = ARM_SMCCC_VERSION_1_1;
> > > @@ -143,6 +169,7 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > > return kvm_psci_call(vcpu);
> > > }
> > >
> > > +out:
> > > smccc_set_retval(vcpu, val[0], val[1], val[2], val[3]);
> > > return 1;
> > > }
> > > @@ -151,8 +178,16 @@ static const u64 kvm_arm_fw_reg_ids[] = {
> > > KVM_REG_ARM_PSCI_VERSION,
> > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > > + KVM_REG_ARM_STD_BMAP,
> > > };
> > >
> > > +void kvm_arm_init_hypercalls(struct kvm *kvm)
> > > +{
> > > + struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
> > > +
> > > + hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
> > > +}
> > > +
> > > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> > > {
> > > return ARRAY_SIZE(kvm_arm_fw_reg_ids);
> > > @@ -220,6 +255,7 @@ static int get_kernel_wa_level(u64 regid)
> > >
> > > int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > {
> > > + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> > > void __user *uaddr = (void __user *)(long)reg->addr;
> > > u64 val, reg_id = reg->id;
> > >
> > > @@ -233,6 +269,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> > > val = get_kernel_wa_level(reg_id) & KVM_REG_FEATURE_LEVEL_MASK;
> > > break;
> > > + case KVM_REG_ARM_STD_BMAP:
> > > + val = READ_ONCE(hvc_desc->hvc_std_bmap);
> > > + break;
> > > default:
> > > return -ENOENT;
> > > }
> > > @@ -243,6 +282,43 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > return 0;
> > > }
> > >
> > > +static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
> > > +{
> > > + int ret = 0;
> > > + struct kvm *kvm = vcpu->kvm;
> > > + struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
> > > + u64 *fw_reg_bmap, fw_reg_features;
> >
> > nit: use reverse fir tree ordering for locals (longest line first,
> > shortest last).
> >
> Got it.
> > > + switch (reg_id) {
> > > + case KVM_REG_ARM_STD_BMAP:
> > > + fw_reg_bmap = &hvc_desc->hvc_std_bmap;
> > > + fw_reg_features = ARM_SMCCC_STD_FEATURES;
> > > + break;
> > > + default:
> > > + return -ENOENT;
> > > + }
> > > +
> > > + /* Check for unsupported bit */
> > > + if (val & ~fw_reg_features)
> > > + return -EINVAL;
> > > +
> > > + mutex_lock(&kvm->lock);
> > > +
> > > + /*
> > > + * If the VM (any vCPU) has already started running, return success
> > > + * if there's no change in the value. Else, return -EBUSY.
> >
> > How about returning -EINVAL instead? We already do this for
> > KVM_ARM_VCPU_INIT if userspace uses a different target than the one
> > previously set.
> >
> Returning EBUSY could help userspace distinguish the cause of failure
> better as compared to EINVAL, since technically, the arguments
> supplied by the user are in fact valid. It's just that the timing is
> wrong.
>
Good point :-) Also, this matches the PMU event filter handling as well.
Apologies.
> > > + */
> > > + if (kvm_arm_vm_has_run_once(&kvm->arch)) {
> > > + ret = *fw_reg_bmap != val ? -EBUSY : 0;
> > > + goto out;
> > > + }
> > > +
> > > + WRITE_ONCE(*fw_reg_bmap, val);
> > > +out:
> > > + mutex_unlock(&kvm->lock);
> > > + return ret;
> > > +}
> > > +
> > > int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > {
> > > void __user *uaddr = (void __user *)(long)reg->addr;
> > > @@ -321,6 +397,8 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > return -EINVAL;
> > >
> > > return 0;
> > > + case KVM_REG_ARM_STD_BMAP:
> > > + return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
> > > default:
> > > return -ENOENT;
> > > }
> > > diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> > > index 5d38628a8d04..64d30b452809 100644
> > > --- a/include/kvm/arm_hypercalls.h
> > > +++ b/include/kvm/arm_hypercalls.h
> > > @@ -6,6 +6,9 @@
> > >
> > > #include <asm/kvm_emulate.h>
> > >
> > > +#define ARM_SMCCC_STD_FEATURES \
> > > + GENMASK_ULL(KVM_REG_ARM_STD_BMAP_BIT_MAX, 0)
> > > +
> >
> > This probably needs KVM_ somewhere in its name for the sake of scoping.
> >
> RIght, I can append that.
>
> > > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
> > >
> > > static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
> > > @@ -42,6 +45,7 @@ static inline void smccc_set_retval(struct kvm_vcpu *vcpu,
> > >
> > > struct kvm_one_reg;
> > >
> > > +void kvm_arm_init_hypercalls(struct kvm *kvm);
> > > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
> > > int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
> > > int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> > > --
> > > 2.35.1.473.g83b2b277ed-goog
> > >
>
> Regards,
> Raghavendra
>
> [1]: https://lore.kernel.org/linux-arm-kernel/CAJHc60y6b-scY8zcPuLnjGtr6HzSBnmhi2mCnmkNm4nTxgMTUQ@mail.gmail.com/
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 05/13] KVM: arm64: Setup a framework for hypercall bitmap firmware registers
@ 2022-03-15 7:25 ` Oliver Upton
0 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-15 7:25 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Mon, Mar 14, 2022 at 05:22:31PM -0700, Raghavendra Rao Ananta wrote:
> Hi Oliver,
>
> On Mon, Mar 14, 2022 at 12:41 PM Oliver Upton <oupton@google.com> wrote:
> >
> > On Thu, Feb 24, 2022 at 05:25:51PM +0000, Raghavendra Rao Ananta wrote:
> > > KVM regularly introduces new hypercall services to the guests without
> > > any consent from the userspace. This means, the guests can observe
> > > hypercall services in and out as they migrate across various host
> > > kernel versions. This could be a major problem if the guest
> > > discovered a hypercall, started using it, and after getting migrated
> > > to an older kernel realizes that it's no longer available. Depending
> > > on how the guest handles the change, there's a potential chance that
> > > the guest would just panic.
> > >
> > > As a result, there's a need for the userspace to elect the services
> > > that it wishes the guest to discover. It can elect these services
> > > based on the kernels spread across its (migration) fleet. To remedy
> > > this, extend the existing firmware psuedo-registers, such as
> > > KVM_REG_ARM_PSCI_VERSION, for all the hypercall services available.
> > >
> > > These firmware registers are categorized based on the service call
> > > owners, and unlike the existing firmware psuedo-registers, they hold
> > > the features supported in the form of a bitmap.
> > >
> > > During the VM initialization, the registers holds an upper-limit of
> > > the features supported by the corresponding registers. It's expected
> > > that the VMMs discover the features provided by each register via
> > > GET_ONE_REG, and writeback the desired values using SET_ONE_REG.
> > > KVM allows this modification only until the VM has started.
> > >
> > > Older userspace code can simply ignore the capability and the
> > > hypercall services will be exposed unconditionally to the guests, thus
> > > ensuring backward compatibility.
> > >
> > > In this patch, the framework adds the register only for ARM's standard
> > > secure services (owner value 4). Currently, this includes support only
> > > for ARM True Random Number Generator (TRNG) service, with bit-0 of the
> > > register representing mandatory features of v1.0. The register is also
> > > added to the kvm_arm_vm_scope_fw_regs[] list as it maintains its state
> > > per-VM. Other services are momentarily added in the upcoming patches.
> > >
> > > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > > ---
> > > arch/arm64/include/asm/kvm_host.h | 12 +++++
> > > arch/arm64/include/uapi/asm/kvm.h | 8 ++++
> > > arch/arm64/kvm/arm.c | 8 ++++
> > > arch/arm64/kvm/guest.c | 1 +
> > > arch/arm64/kvm/hypercalls.c | 78 +++++++++++++++++++++++++++++++
> > > include/kvm/arm_hypercalls.h | 4 ++
> > > 6 files changed, 111 insertions(+)
> > >
> > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > > index e823571e50cc..1909ced3208f 100644
> > > --- a/arch/arm64/include/asm/kvm_host.h
> > > +++ b/arch/arm64/include/asm/kvm_host.h
> > > @@ -101,6 +101,15 @@ struct kvm_s2_mmu {
> > > struct kvm_arch_memory_slot {
> > > };
> > >
> > > +/**
> > > + * struct kvm_hvc_desc: KVM ARM64 hypercall descriptor
> > > + *
> > > + * @hvc_std_bmap: Bitmap of standard secure service calls
> > > + */
> > > +struct kvm_hvc_desc {
> >
> > nit: maybe call this structure kvm_hypercall_features? When nested comes
> > along guests will need to use the SVC conduit as HVC traps are always
> > taken to EL2. Same will need to be true for virtual EL2.
> >
> Sure, I can rename it to be more generic.
>
> > > + u64 hvc_std_bmap;
> > > +};
> > > +
> > > struct kvm_arch {
> > > struct kvm_s2_mmu mmu;
> > >
> > > @@ -142,6 +151,9 @@ struct kvm_arch {
> > >
> > > /* Capture first run of the VM */
> > > bool has_run_once;
> > > +
> > > + /* Hypercall firmware register' descriptor */
> > > + struct kvm_hvc_desc hvc_desc;
> > > };
> > >
> > > struct kvm_vcpu_fault_info {
> > > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > > index c35447cc0e0c..2decc30d6b84 100644
> > > --- a/arch/arm64/include/uapi/asm/kvm.h
> > > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > > @@ -287,6 +287,14 @@ struct kvm_arm_copy_mte_tags {
> > > #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED 3
> > > #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED (1U << 4)
> > >
> > > +/* Bitmap firmware registers, extension to the existing psuedo-register space */
> > > +#define KVM_REG_ARM_FW_BMAP KVM_REG_ARM_FW_REG(0xff00)
> >
> > What is the motivation for moving the bitmap register indices so far
> > away from the rest of the firmware regs?
> >
> The original motivation to create a sub-space came from Reiji's
> comment on v3 [1] so that user-space can distinguish between bitmapped
> and regular fw registers.
> As with the spacing, I thought a 50/50 split would do a good job of
> avoiding collisions. Do you have any recommendations here?
>
I see. This is for the sake of ABI stability with future expansion,
right? A new register could be added in the future that controls more
SMCCC features, and we expect userspace to zero them if it cares about
ABI stability.
If that is all true, we probably need some strong supporting
documentation. Additionally, using a new COPROC value for the register
range might be better than partitioning the existing FW reg range.
> > > +#define KVM_REG_ARM_FW_BMAP_REG(r) (KVM_REG_ARM_FW_BMAP | (r))
> >
> > If you are still going to use the index offset, just pass 'r' through to
> > the other macro:
> >
> > #define KVM_REG_ARM_FW_BMAP_REG(r) KVM_REG_ARM_FW_REG(0xff00 + r)
> >
> I'm sorry, what's the advantage of doing this?
>
> > > +#define KVM_REG_ARM_STD_BMAP KVM_REG_ARM_FW_BMAP_REG(0)
> > > +#define KVM_REG_ARM_STD_BIT_TRNG_V1_0 BIT(0)
> > > +#define KVM_REG_ARM_STD_BMAP_BIT_MAX 0 /* Last valid bit */
> >
> > Implementation details such as this probably shouldn't live in UAPI
> > headers. We'll likely need to bump the value in the future.
> >
> Wouldn't the macros act as helpers to userspace as well?
> I agree with your point about the limited spacing, and we may need to
> expand/shrink as needed, but isn't that a general register-space
> problem?
>
I think that the kernel's responsibility to userspace starts and ends with
enumerating the register bits. Those values remain invariant on future
KVM. On the other hand, you'll need to bump the _MAX value every time
you add to the register. Between documentation and bit definitions,
userspace should have enough info to work out the rest on its own :)
> > > +
> > > /* SVE registers */
> > > #define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
> > >
> > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > > index f61cd8d57eae..e9f9edb1cf55 100644
> > > --- a/arch/arm64/kvm/arm.c
> > > +++ b/arch/arm64/kvm/arm.c
> > > @@ -156,6 +156,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> > > kvm->arch.max_vcpus = kvm_arm_default_max_vcpus();
> > >
> > > set_default_spectre(kvm);
> > > + kvm_arm_init_hypercalls(kvm);
> > >
> > > return ret;
> > > out_free_stage2_pgd:
> > > @@ -635,7 +636,14 @@ int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu)
> > > if (kvm_vm_is_protected(kvm))
> > > kvm_call_hyp_nvhe(__pkvm_vcpu_init_traps, vcpu);
> > >
> > > + /*
> > > + * Grab kvm->lock such that the reader of has_run_once can finish
> > > + * the necessary operation atomically, such as deciding whether to
> > > + * block the writes to the firmware registers if the VM has run once.
> > > + */
> > > + mutex_lock(&kvm->lock);
> > > kvm->arch.has_run_once = true;
> > > + mutex_unlock(&kvm->lock);
> >
> > Shouldn't this have just grabbed the kvm lock in patch 04/13?
> >
> It could have, and I agree it's a little igly. But thinking that
> there's are no parallel threads/consumers when it was initially
> implemented gave me no reason to grab the locks.
I see, I was just curious if there was something I had missed.
> > > return ret;
> > > }
> > > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> > > index eb061e64a7a5..d66e6c742bbe 100644
> > > --- a/arch/arm64/kvm/guest.c
> > > +++ b/arch/arm64/kvm/guest.c
> > > @@ -65,6 +65,7 @@ const struct kvm_stats_header kvm_vcpu_stats_header = {
> > > static const u64 kvm_arm_vm_scope_fw_regs[] = {
> > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > > + KVM_REG_ARM_STD_BMAP,
> > > };
> > >
> > > /**
> > > diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> > > index 8624e6964940..48c126c3da72 100644
> > > --- a/arch/arm64/kvm/hypercalls.c
> > > +++ b/arch/arm64/kvm/hypercalls.c
> > > @@ -58,6 +58,29 @@ static void kvm_ptp_get_time(struct kvm_vcpu *vcpu, u64 *val)
> > > val[3] = lower_32_bits(cycles);
> > > }
> > >
> > > +static bool kvm_arm_fw_reg_feat_enabled(u64 reg_bmap, u64 feat_bit)
> > > +{
> > > + return reg_bmap & feat_bit;
> > > +}
> > > +
> > > +static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> > > +{
> > > + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> > > +
> > > + switch (func_id) {
> > > + case ARM_SMCCC_TRNG_VERSION:
> > > + case ARM_SMCCC_TRNG_FEATURES:
> > > + case ARM_SMCCC_TRNG_GET_UUID:
> > > + case ARM_SMCCC_TRNG_RND32:
> > > + case ARM_SMCCC_TRNG_RND64:
> > > + return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_bmap,
> > > + KVM_REG_ARM_STD_BIT_TRNG_V1_0);
> > > + default:
> > > + /* By default, allow the services that aren't listed here */
> > > + return true;
> >
> > I think your default case should really return false. It keeps people
> > honest when they add new patches to set up a new hypercall bit (no bit?
> > no call!)
> >
> > That of course requires that you only return false once all of the
> > preexisting hypercalls are enumerated, otherwise such a patch would
> > cause a regression in isolation.
> >
> I agree, but not all hypercalls may have a bit. For example, guarding
> ARM_SMCCC_VERSION_FUNC_ID doesn't make sense and may not be gated by
> the bit. Hence, the idea was to do an initial check if the func_id is
> in fact gated. If yes, check the bit, else let the actual
> implementation take care of it.
The set of hypercalls that are not under userspace control need to exist
on an allowlist then. Any new hypercall after the introduction of these
registers must have a bit assigned then, right? Otherwise it would seem
that new hypercalls could sneak into the guest ABI when migrating to an
upgraded kernel.
>
> > > +}
> > > +
> > > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > > {
> > > u32 func_id = smccc_get_function(vcpu);
> > > @@ -65,6 +88,9 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > > u32 feature;
> > > gpa_t gpa;
> > >
> > > + if (!kvm_hvc_call_supported(vcpu, func_id))
> > > + goto out;
> > > +
> > > switch (func_id) {
> > > case ARM_SMCCC_VERSION_FUNC_ID:
> > > val[0] = ARM_SMCCC_VERSION_1_1;
> > > @@ -143,6 +169,7 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > > return kvm_psci_call(vcpu);
> > > }
> > >
> > > +out:
> > > smccc_set_retval(vcpu, val[0], val[1], val[2], val[3]);
> > > return 1;
> > > }
> > > @@ -151,8 +178,16 @@ static const u64 kvm_arm_fw_reg_ids[] = {
> > > KVM_REG_ARM_PSCI_VERSION,
> > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > > + KVM_REG_ARM_STD_BMAP,
> > > };
> > >
> > > +void kvm_arm_init_hypercalls(struct kvm *kvm)
> > > +{
> > > + struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
> > > +
> > > + hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
> > > +}
> > > +
> > > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> > > {
> > > return ARRAY_SIZE(kvm_arm_fw_reg_ids);
> > > @@ -220,6 +255,7 @@ static int get_kernel_wa_level(u64 regid)
> > >
> > > int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > {
> > > + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> > > void __user *uaddr = (void __user *)(long)reg->addr;
> > > u64 val, reg_id = reg->id;
> > >
> > > @@ -233,6 +269,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> > > val = get_kernel_wa_level(reg_id) & KVM_REG_FEATURE_LEVEL_MASK;
> > > break;
> > > + case KVM_REG_ARM_STD_BMAP:
> > > + val = READ_ONCE(hvc_desc->hvc_std_bmap);
> > > + break;
> > > default:
> > > return -ENOENT;
> > > }
> > > @@ -243,6 +282,43 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > return 0;
> > > }
> > >
> > > +static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
> > > +{
> > > + int ret = 0;
> > > + struct kvm *kvm = vcpu->kvm;
> > > + struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
> > > + u64 *fw_reg_bmap, fw_reg_features;
> >
> > nit: use reverse fir tree ordering for locals (longest line first,
> > shortest last).
> >
> Got it.
> > > + switch (reg_id) {
> > > + case KVM_REG_ARM_STD_BMAP:
> > > + fw_reg_bmap = &hvc_desc->hvc_std_bmap;
> > > + fw_reg_features = ARM_SMCCC_STD_FEATURES;
> > > + break;
> > > + default:
> > > + return -ENOENT;
> > > + }
> > > +
> > > + /* Check for unsupported bit */
> > > + if (val & ~fw_reg_features)
> > > + return -EINVAL;
> > > +
> > > + mutex_lock(&kvm->lock);
> > > +
> > > + /*
> > > + * If the VM (any vCPU) has already started running, return success
> > > + * if there's no change in the value. Else, return -EBUSY.
> >
> > How about returning -EINVAL instead? We already do this for
> > KVM_ARM_VCPU_INIT if userspace uses a different target than the one
> > previously set.
> >
> Returning EBUSY could help userspace distinguish the cause of failure
> better as compared to EINVAL, since technically, the arguments
> supplied by the user are in fact valid. It's just that the timing is
> wrong.
>
Good point :-) Also, this matches the PMU event filter handling as well.
Apologies.
> > > + */
> > > + if (kvm_arm_vm_has_run_once(&kvm->arch)) {
> > > + ret = *fw_reg_bmap != val ? -EBUSY : 0;
> > > + goto out;
> > > + }
> > > +
> > > + WRITE_ONCE(*fw_reg_bmap, val);
> > > +out:
> > > + mutex_unlock(&kvm->lock);
> > > + return ret;
> > > +}
> > > +
> > > int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > {
> > > void __user *uaddr = (void __user *)(long)reg->addr;
> > > @@ -321,6 +397,8 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > return -EINVAL;
> > >
> > > return 0;
> > > + case KVM_REG_ARM_STD_BMAP:
> > > + return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
> > > default:
> > > return -ENOENT;
> > > }
> > > diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> > > index 5d38628a8d04..64d30b452809 100644
> > > --- a/include/kvm/arm_hypercalls.h
> > > +++ b/include/kvm/arm_hypercalls.h
> > > @@ -6,6 +6,9 @@
> > >
> > > #include <asm/kvm_emulate.h>
> > >
> > > +#define ARM_SMCCC_STD_FEATURES \
> > > + GENMASK_ULL(KVM_REG_ARM_STD_BMAP_BIT_MAX, 0)
> > > +
> >
> > This probably needs KVM_ somewhere in its name for the sake of scoping.
> >
> RIght, I can append that.
>
> > > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
> > >
> > > static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
> > > @@ -42,6 +45,7 @@ static inline void smccc_set_retval(struct kvm_vcpu *vcpu,
> > >
> > > struct kvm_one_reg;
> > >
> > > +void kvm_arm_init_hypercalls(struct kvm *kvm);
> > > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
> > > int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
> > > int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> > > --
> > > 2.35.1.473.g83b2b277ed-goog
> > >
>
> Regards,
> Raghavendra
>
> [1]: https://lore.kernel.org/linux-arm-kernel/CAJHc60y6b-scY8zcPuLnjGtr6HzSBnmhi2mCnmkNm4nTxgMTUQ@mail.gmail.com/
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 05/13] KVM: arm64: Setup a framework for hypercall bitmap firmware registers
@ 2022-03-15 7:25 ` Oliver Upton
0 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-15 7:25 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Mon, Mar 14, 2022 at 05:22:31PM -0700, Raghavendra Rao Ananta wrote:
> Hi Oliver,
>
> On Mon, Mar 14, 2022 at 12:41 PM Oliver Upton <oupton@google.com> wrote:
> >
> > On Thu, Feb 24, 2022 at 05:25:51PM +0000, Raghavendra Rao Ananta wrote:
> > > KVM regularly introduces new hypercall services to the guests without
> > > any consent from the userspace. This means, the guests can observe
> > > hypercall services in and out as they migrate across various host
> > > kernel versions. This could be a major problem if the guest
> > > discovered a hypercall, started using it, and after getting migrated
> > > to an older kernel realizes that it's no longer available. Depending
> > > on how the guest handles the change, there's a potential chance that
> > > the guest would just panic.
> > >
> > > As a result, there's a need for the userspace to elect the services
> > > that it wishes the guest to discover. It can elect these services
> > > based on the kernels spread across its (migration) fleet. To remedy
> > > this, extend the existing firmware psuedo-registers, such as
> > > KVM_REG_ARM_PSCI_VERSION, for all the hypercall services available.
> > >
> > > These firmware registers are categorized based on the service call
> > > owners, and unlike the existing firmware psuedo-registers, they hold
> > > the features supported in the form of a bitmap.
> > >
> > > During the VM initialization, the registers holds an upper-limit of
> > > the features supported by the corresponding registers. It's expected
> > > that the VMMs discover the features provided by each register via
> > > GET_ONE_REG, and writeback the desired values using SET_ONE_REG.
> > > KVM allows this modification only until the VM has started.
> > >
> > > Older userspace code can simply ignore the capability and the
> > > hypercall services will be exposed unconditionally to the guests, thus
> > > ensuring backward compatibility.
> > >
> > > In this patch, the framework adds the register only for ARM's standard
> > > secure services (owner value 4). Currently, this includes support only
> > > for ARM True Random Number Generator (TRNG) service, with bit-0 of the
> > > register representing mandatory features of v1.0. The register is also
> > > added to the kvm_arm_vm_scope_fw_regs[] list as it maintains its state
> > > per-VM. Other services are momentarily added in the upcoming patches.
> > >
> > > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > > ---
> > > arch/arm64/include/asm/kvm_host.h | 12 +++++
> > > arch/arm64/include/uapi/asm/kvm.h | 8 ++++
> > > arch/arm64/kvm/arm.c | 8 ++++
> > > arch/arm64/kvm/guest.c | 1 +
> > > arch/arm64/kvm/hypercalls.c | 78 +++++++++++++++++++++++++++++++
> > > include/kvm/arm_hypercalls.h | 4 ++
> > > 6 files changed, 111 insertions(+)
> > >
> > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > > index e823571e50cc..1909ced3208f 100644
> > > --- a/arch/arm64/include/asm/kvm_host.h
> > > +++ b/arch/arm64/include/asm/kvm_host.h
> > > @@ -101,6 +101,15 @@ struct kvm_s2_mmu {
> > > struct kvm_arch_memory_slot {
> > > };
> > >
> > > +/**
> > > + * struct kvm_hvc_desc: KVM ARM64 hypercall descriptor
> > > + *
> > > + * @hvc_std_bmap: Bitmap of standard secure service calls
> > > + */
> > > +struct kvm_hvc_desc {
> >
> > nit: maybe call this structure kvm_hypercall_features? When nested comes
> > along guests will need to use the SVC conduit as HVC traps are always
> > taken to EL2. Same will need to be true for virtual EL2.
> >
> Sure, I can rename it to be more generic.
>
> > > + u64 hvc_std_bmap;
> > > +};
> > > +
> > > struct kvm_arch {
> > > struct kvm_s2_mmu mmu;
> > >
> > > @@ -142,6 +151,9 @@ struct kvm_arch {
> > >
> > > /* Capture first run of the VM */
> > > bool has_run_once;
> > > +
> > > + /* Hypercall firmware register' descriptor */
> > > + struct kvm_hvc_desc hvc_desc;
> > > };
> > >
> > > struct kvm_vcpu_fault_info {
> > > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > > index c35447cc0e0c..2decc30d6b84 100644
> > > --- a/arch/arm64/include/uapi/asm/kvm.h
> > > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > > @@ -287,6 +287,14 @@ struct kvm_arm_copy_mte_tags {
> > > #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED 3
> > > #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED (1U << 4)
> > >
> > > +/* Bitmap firmware registers, extension to the existing psuedo-register space */
> > > +#define KVM_REG_ARM_FW_BMAP KVM_REG_ARM_FW_REG(0xff00)
> >
> > What is the motivation for moving the bitmap register indices so far
> > away from the rest of the firmware regs?
> >
> The original motivation to create a sub-space came from Reiji's
> comment on v3 [1] so that user-space can distinguish between bitmapped
> and regular fw registers.
> As with the spacing, I thought a 50/50 split would do a good job of
> avoiding collisions. Do you have any recommendations here?
>
I see. This is for the sake of ABI stability with future expansion,
right? A new register could be added in the future that controls more
SMCCC features, and we expect userspace to zero them if it cares about
ABI stability.
If that is all true, we probably need some strong supporting
documentation. Additionally, using a new COPROC value for the register
range might be better than partitioning the existing FW reg range.
> > > +#define KVM_REG_ARM_FW_BMAP_REG(r) (KVM_REG_ARM_FW_BMAP | (r))
> >
> > If you are still going to use the index offset, just pass 'r' through to
> > the other macro:
> >
> > #define KVM_REG_ARM_FW_BMAP_REG(r) KVM_REG_ARM_FW_REG(0xff00 + r)
> >
> I'm sorry, what's the advantage of doing this?
>
> > > +#define KVM_REG_ARM_STD_BMAP KVM_REG_ARM_FW_BMAP_REG(0)
> > > +#define KVM_REG_ARM_STD_BIT_TRNG_V1_0 BIT(0)
> > > +#define KVM_REG_ARM_STD_BMAP_BIT_MAX 0 /* Last valid bit */
> >
> > Implementation details such as this probably shouldn't live in UAPI
> > headers. We'll likely need to bump the value in the future.
> >
> Wouldn't the macros act as helpers to userspace as well?
> I agree with your point about the limited spacing, and we may need to
> expand/shrink as needed, but isn't that a general register-space
> problem?
>
I think that the kernel's responsibility to userspace starts and ends with
enumerating the register bits. Those values remain invariant on future
KVM. On the other hand, you'll need to bump the _MAX value every time
you add to the register. Between documentation and bit definitions,
userspace should have enough info to work out the rest on its own :)
> > > +
> > > /* SVE registers */
> > > #define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
> > >
> > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > > index f61cd8d57eae..e9f9edb1cf55 100644
> > > --- a/arch/arm64/kvm/arm.c
> > > +++ b/arch/arm64/kvm/arm.c
> > > @@ -156,6 +156,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> > > kvm->arch.max_vcpus = kvm_arm_default_max_vcpus();
> > >
> > > set_default_spectre(kvm);
> > > + kvm_arm_init_hypercalls(kvm);
> > >
> > > return ret;
> > > out_free_stage2_pgd:
> > > @@ -635,7 +636,14 @@ int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu)
> > > if (kvm_vm_is_protected(kvm))
> > > kvm_call_hyp_nvhe(__pkvm_vcpu_init_traps, vcpu);
> > >
> > > + /*
> > > + * Grab kvm->lock such that the reader of has_run_once can finish
> > > + * the necessary operation atomically, such as deciding whether to
> > > + * block the writes to the firmware registers if the VM has run once.
> > > + */
> > > + mutex_lock(&kvm->lock);
> > > kvm->arch.has_run_once = true;
> > > + mutex_unlock(&kvm->lock);
> >
> > Shouldn't this have just grabbed the kvm lock in patch 04/13?
> >
> It could have, and I agree it's a little igly. But thinking that
> there's are no parallel threads/consumers when it was initially
> implemented gave me no reason to grab the locks.
I see, I was just curious if there was something I had missed.
> > > return ret;
> > > }
> > > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> > > index eb061e64a7a5..d66e6c742bbe 100644
> > > --- a/arch/arm64/kvm/guest.c
> > > +++ b/arch/arm64/kvm/guest.c
> > > @@ -65,6 +65,7 @@ const struct kvm_stats_header kvm_vcpu_stats_header = {
> > > static const u64 kvm_arm_vm_scope_fw_regs[] = {
> > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > > + KVM_REG_ARM_STD_BMAP,
> > > };
> > >
> > > /**
> > > diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> > > index 8624e6964940..48c126c3da72 100644
> > > --- a/arch/arm64/kvm/hypercalls.c
> > > +++ b/arch/arm64/kvm/hypercalls.c
> > > @@ -58,6 +58,29 @@ static void kvm_ptp_get_time(struct kvm_vcpu *vcpu, u64 *val)
> > > val[3] = lower_32_bits(cycles);
> > > }
> > >
> > > +static bool kvm_arm_fw_reg_feat_enabled(u64 reg_bmap, u64 feat_bit)
> > > +{
> > > + return reg_bmap & feat_bit;
> > > +}
> > > +
> > > +static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> > > +{
> > > + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> > > +
> > > + switch (func_id) {
> > > + case ARM_SMCCC_TRNG_VERSION:
> > > + case ARM_SMCCC_TRNG_FEATURES:
> > > + case ARM_SMCCC_TRNG_GET_UUID:
> > > + case ARM_SMCCC_TRNG_RND32:
> > > + case ARM_SMCCC_TRNG_RND64:
> > > + return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_bmap,
> > > + KVM_REG_ARM_STD_BIT_TRNG_V1_0);
> > > + default:
> > > + /* By default, allow the services that aren't listed here */
> > > + return true;
> >
> > I think your default case should really return false. It keeps people
> > honest when they add new patches to set up a new hypercall bit (no bit?
> > no call!)
> >
> > That of course requires that you only return false once all of the
> > preexisting hypercalls are enumerated, otherwise such a patch would
> > cause a regression in isolation.
> >
> I agree, but not all hypercalls may have a bit. For example, guarding
> ARM_SMCCC_VERSION_FUNC_ID doesn't make sense and may not be gated by
> the bit. Hence, the idea was to do an initial check if the func_id is
> in fact gated. If yes, check the bit, else let the actual
> implementation take care of it.
The set of hypercalls that are not under userspace control need to exist
on an allowlist then. Any new hypercall after the introduction of these
registers must have a bit assigned then, right? Otherwise it would seem
that new hypercalls could sneak into the guest ABI when migrating to an
upgraded kernel.
>
> > > +}
> > > +
> > > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > > {
> > > u32 func_id = smccc_get_function(vcpu);
> > > @@ -65,6 +88,9 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > > u32 feature;
> > > gpa_t gpa;
> > >
> > > + if (!kvm_hvc_call_supported(vcpu, func_id))
> > > + goto out;
> > > +
> > > switch (func_id) {
> > > case ARM_SMCCC_VERSION_FUNC_ID:
> > > val[0] = ARM_SMCCC_VERSION_1_1;
> > > @@ -143,6 +169,7 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > > return kvm_psci_call(vcpu);
> > > }
> > >
> > > +out:
> > > smccc_set_retval(vcpu, val[0], val[1], val[2], val[3]);
> > > return 1;
> > > }
> > > @@ -151,8 +178,16 @@ static const u64 kvm_arm_fw_reg_ids[] = {
> > > KVM_REG_ARM_PSCI_VERSION,
> > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > > + KVM_REG_ARM_STD_BMAP,
> > > };
> > >
> > > +void kvm_arm_init_hypercalls(struct kvm *kvm)
> > > +{
> > > + struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
> > > +
> > > + hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
> > > +}
> > > +
> > > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> > > {
> > > return ARRAY_SIZE(kvm_arm_fw_reg_ids);
> > > @@ -220,6 +255,7 @@ static int get_kernel_wa_level(u64 regid)
> > >
> > > int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > {
> > > + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> > > void __user *uaddr = (void __user *)(long)reg->addr;
> > > u64 val, reg_id = reg->id;
> > >
> > > @@ -233,6 +269,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> > > val = get_kernel_wa_level(reg_id) & KVM_REG_FEATURE_LEVEL_MASK;
> > > break;
> > > + case KVM_REG_ARM_STD_BMAP:
> > > + val = READ_ONCE(hvc_desc->hvc_std_bmap);
> > > + break;
> > > default:
> > > return -ENOENT;
> > > }
> > > @@ -243,6 +282,43 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > return 0;
> > > }
> > >
> > > +static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
> > > +{
> > > + int ret = 0;
> > > + struct kvm *kvm = vcpu->kvm;
> > > + struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
> > > + u64 *fw_reg_bmap, fw_reg_features;
> >
> > nit: use reverse fir tree ordering for locals (longest line first,
> > shortest last).
> >
> Got it.
> > > + switch (reg_id) {
> > > + case KVM_REG_ARM_STD_BMAP:
> > > + fw_reg_bmap = &hvc_desc->hvc_std_bmap;
> > > + fw_reg_features = ARM_SMCCC_STD_FEATURES;
> > > + break;
> > > + default:
> > > + return -ENOENT;
> > > + }
> > > +
> > > + /* Check for unsupported bit */
> > > + if (val & ~fw_reg_features)
> > > + return -EINVAL;
> > > +
> > > + mutex_lock(&kvm->lock);
> > > +
> > > + /*
> > > + * If the VM (any vCPU) has already started running, return success
> > > + * if there's no change in the value. Else, return -EBUSY.
> >
> > How about returning -EINVAL instead? We already do this for
> > KVM_ARM_VCPU_INIT if userspace uses a different target than the one
> > previously set.
> >
> Returning EBUSY could help userspace distinguish the cause of failure
> better as compared to EINVAL, since technically, the arguments
> supplied by the user are in fact valid. It's just that the timing is
> wrong.
>
Good point :-) Also, this matches the PMU event filter handling as well.
Apologies.
> > > + */
> > > + if (kvm_arm_vm_has_run_once(&kvm->arch)) {
> > > + ret = *fw_reg_bmap != val ? -EBUSY : 0;
> > > + goto out;
> > > + }
> > > +
> > > + WRITE_ONCE(*fw_reg_bmap, val);
> > > +out:
> > > + mutex_unlock(&kvm->lock);
> > > + return ret;
> > > +}
> > > +
> > > int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > {
> > > void __user *uaddr = (void __user *)(long)reg->addr;
> > > @@ -321,6 +397,8 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > return -EINVAL;
> > >
> > > return 0;
> > > + case KVM_REG_ARM_STD_BMAP:
> > > + return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
> > > default:
> > > return -ENOENT;
> > > }
> > > diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> > > index 5d38628a8d04..64d30b452809 100644
> > > --- a/include/kvm/arm_hypercalls.h
> > > +++ b/include/kvm/arm_hypercalls.h
> > > @@ -6,6 +6,9 @@
> > >
> > > #include <asm/kvm_emulate.h>
> > >
> > > +#define ARM_SMCCC_STD_FEATURES \
> > > + GENMASK_ULL(KVM_REG_ARM_STD_BMAP_BIT_MAX, 0)
> > > +
> >
> > This probably needs KVM_ somewhere in its name for the sake of scoping.
> >
> RIght, I can append that.
>
> > > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
> > >
> > > static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
> > > @@ -42,6 +45,7 @@ static inline void smccc_set_retval(struct kvm_vcpu *vcpu,
> > >
> > > struct kvm_one_reg;
> > >
> > > +void kvm_arm_init_hypercalls(struct kvm *kvm);
> > > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
> > > int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
> > > int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> > > --
> > > 2.35.1.473.g83b2b277ed-goog
> > >
>
> Regards,
> Raghavendra
>
> [1]: https://lore.kernel.org/linux-arm-kernel/CAJHc60y6b-scY8zcPuLnjGtr6HzSBnmhi2mCnmkNm4nTxgMTUQ@mail.gmail.com/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 05/13] KVM: arm64: Setup a framework for hypercall bitmap firmware registers
2022-03-15 7:25 ` Oliver Upton
(?)
@ 2022-03-15 16:59 ` Raghavendra Rao Ananta
-1 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-03-15 16:59 UTC (permalink / raw)
To: Oliver Upton
Cc: kvm, Will Deacon, Marc Zyngier, Peter Shier, linux-kernel,
Catalin Marinas, Paolo Bonzini, kvmarm, linux-arm-kernel
On Tue, Mar 15, 2022 at 12:25 AM Oliver Upton <oupton@google.com> wrote:
>
> On Mon, Mar 14, 2022 at 05:22:31PM -0700, Raghavendra Rao Ananta wrote:
> > Hi Oliver,
> >
> > On Mon, Mar 14, 2022 at 12:41 PM Oliver Upton <oupton@google.com> wrote:
> > >
> > > On Thu, Feb 24, 2022 at 05:25:51PM +0000, Raghavendra Rao Ananta wrote:
> > > > KVM regularly introduces new hypercall services to the guests without
> > > > any consent from the userspace. This means, the guests can observe
> > > > hypercall services in and out as they migrate across various host
> > > > kernel versions. This could be a major problem if the guest
> > > > discovered a hypercall, started using it, and after getting migrated
> > > > to an older kernel realizes that it's no longer available. Depending
> > > > on how the guest handles the change, there's a potential chance that
> > > > the guest would just panic.
> > > >
> > > > As a result, there's a need for the userspace to elect the services
> > > > that it wishes the guest to discover. It can elect these services
> > > > based on the kernels spread across its (migration) fleet. To remedy
> > > > this, extend the existing firmware psuedo-registers, such as
> > > > KVM_REG_ARM_PSCI_VERSION, for all the hypercall services available.
> > > >
> > > > These firmware registers are categorized based on the service call
> > > > owners, and unlike the existing firmware psuedo-registers, they hold
> > > > the features supported in the form of a bitmap.
> > > >
> > > > During the VM initialization, the registers holds an upper-limit of
> > > > the features supported by the corresponding registers. It's expected
> > > > that the VMMs discover the features provided by each register via
> > > > GET_ONE_REG, and writeback the desired values using SET_ONE_REG.
> > > > KVM allows this modification only until the VM has started.
> > > >
> > > > Older userspace code can simply ignore the capability and the
> > > > hypercall services will be exposed unconditionally to the guests, thus
> > > > ensuring backward compatibility.
> > > >
> > > > In this patch, the framework adds the register only for ARM's standard
> > > > secure services (owner value 4). Currently, this includes support only
> > > > for ARM True Random Number Generator (TRNG) service, with bit-0 of the
> > > > register representing mandatory features of v1.0. The register is also
> > > > added to the kvm_arm_vm_scope_fw_regs[] list as it maintains its state
> > > > per-VM. Other services are momentarily added in the upcoming patches.
> > > >
> > > > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > > > ---
> > > > arch/arm64/include/asm/kvm_host.h | 12 +++++
> > > > arch/arm64/include/uapi/asm/kvm.h | 8 ++++
> > > > arch/arm64/kvm/arm.c | 8 ++++
> > > > arch/arm64/kvm/guest.c | 1 +
> > > > arch/arm64/kvm/hypercalls.c | 78 +++++++++++++++++++++++++++++++
> > > > include/kvm/arm_hypercalls.h | 4 ++
> > > > 6 files changed, 111 insertions(+)
> > > >
> > > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > > > index e823571e50cc..1909ced3208f 100644
> > > > --- a/arch/arm64/include/asm/kvm_host.h
> > > > +++ b/arch/arm64/include/asm/kvm_host.h
> > > > @@ -101,6 +101,15 @@ struct kvm_s2_mmu {
> > > > struct kvm_arch_memory_slot {
> > > > };
> > > >
> > > > +/**
> > > > + * struct kvm_hvc_desc: KVM ARM64 hypercall descriptor
> > > > + *
> > > > + * @hvc_std_bmap: Bitmap of standard secure service calls
> > > > + */
> > > > +struct kvm_hvc_desc {
> > >
> > > nit: maybe call this structure kvm_hypercall_features? When nested comes
> > > along guests will need to use the SVC conduit as HVC traps are always
> > > taken to EL2. Same will need to be true for virtual EL2.
> > >
> > Sure, I can rename it to be more generic.
> >
> > > > + u64 hvc_std_bmap;
> > > > +};
> > > > +
> > > > struct kvm_arch {
> > > > struct kvm_s2_mmu mmu;
> > > >
> > > > @@ -142,6 +151,9 @@ struct kvm_arch {
> > > >
> > > > /* Capture first run of the VM */
> > > > bool has_run_once;
> > > > +
> > > > + /* Hypercall firmware register' descriptor */
> > > > + struct kvm_hvc_desc hvc_desc;
> > > > };
> > > >
> > > > struct kvm_vcpu_fault_info {
> > > > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > > > index c35447cc0e0c..2decc30d6b84 100644
> > > > --- a/arch/arm64/include/uapi/asm/kvm.h
> > > > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > > > @@ -287,6 +287,14 @@ struct kvm_arm_copy_mte_tags {
> > > > #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED 3
> > > > #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED (1U << 4)
> > > >
> > > > +/* Bitmap firmware registers, extension to the existing psuedo-register space */
> > > > +#define KVM_REG_ARM_FW_BMAP KVM_REG_ARM_FW_REG(0xff00)
> > >
> > > What is the motivation for moving the bitmap register indices so far
> > > away from the rest of the firmware regs?
> > >
> > The original motivation to create a sub-space came from Reiji's
> > comment on v3 [1] so that user-space can distinguish between bitmapped
> > and regular fw registers.
> > As with the spacing, I thought a 50/50 split would do a good job of
> > avoiding collisions. Do you have any recommendations here?
> >
>
> I see. This is for the sake of ABI stability with future expansion,
> right? A new register could be added in the future that controls more
> SMCCC features, and we expect userspace to zero them if it cares about
> ABI stability.
>
> If that is all true, we probably need some strong supporting
> documentation. Additionally, using a new COPROC value for the register
> range might be better than partitioning the existing FW reg range.
>
I assumed the 50/50 split could be fine even for future expansion, but
I can go for a new COPROC value. However, wouldn't the same problem
exist even with that? We could never have enough space :)
> > > > +#define KVM_REG_ARM_FW_BMAP_REG(r) (KVM_REG_ARM_FW_BMAP | (r))
> > >
> > > If you are still going to use the index offset, just pass 'r' through to
> > > the other macro:
> > >
> > > #define KVM_REG_ARM_FW_BMAP_REG(r) KVM_REG_ARM_FW_REG(0xff00 + r)
> > >
> > I'm sorry, what's the advantage of doing this?
> >
> > > > +#define KVM_REG_ARM_STD_BMAP KVM_REG_ARM_FW_BMAP_REG(0)
> > > > +#define KVM_REG_ARM_STD_BIT_TRNG_V1_0 BIT(0)
> > > > +#define KVM_REG_ARM_STD_BMAP_BIT_MAX 0 /* Last valid bit */
> > >
> > > Implementation details such as this probably shouldn't live in UAPI
> > > headers. We'll likely need to bump the value in the future.
> > >
> > Wouldn't the macros act as helpers to userspace as well?
> > I agree with your point about the limited spacing, and we may need to
> > expand/shrink as needed, but isn't that a general register-space
> > problem?
> >
>
> I think that the kernel's responsibility to userspace starts and ends with
> enumerating the register bits. Those values remain invariant on future
> KVM. On the other hand, you'll need to bump the _MAX value every time
> you add to the register. Between documentation and bit definitions,
> userspace should have enough info to work out the rest on its own :)
>
Understood. I'll move the _MAX definitions to the kernel-only headers.
> > > > +
> > > > /* SVE registers */
> > > > #define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
> > > >
> > > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > > > index f61cd8d57eae..e9f9edb1cf55 100644
> > > > --- a/arch/arm64/kvm/arm.c
> > > > +++ b/arch/arm64/kvm/arm.c
> > > > @@ -156,6 +156,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> > > > kvm->arch.max_vcpus = kvm_arm_default_max_vcpus();
> > > >
> > > > set_default_spectre(kvm);
> > > > + kvm_arm_init_hypercalls(kvm);
> > > >
> > > > return ret;
> > > > out_free_stage2_pgd:
> > > > @@ -635,7 +636,14 @@ int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu)
> > > > if (kvm_vm_is_protected(kvm))
> > > > kvm_call_hyp_nvhe(__pkvm_vcpu_init_traps, vcpu);
> > > >
> > > > + /*
> > > > + * Grab kvm->lock such that the reader of has_run_once can finish
> > > > + * the necessary operation atomically, such as deciding whether to
> > > > + * block the writes to the firmware registers if the VM has run once.
> > > > + */
> > > > + mutex_lock(&kvm->lock);
> > > > kvm->arch.has_run_once = true;
> > > > + mutex_unlock(&kvm->lock);
> > >
> > > Shouldn't this have just grabbed the kvm lock in patch 04/13?
> > >
> > It could have, and I agree it's a little igly. But thinking that
> > there's are no parallel threads/consumers when it was initially
> > implemented gave me no reason to grab the locks.
>
> I see, I was just curious if there was something I had missed.
>
> > > > return ret;
> > > > }
> > > > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> > > > index eb061e64a7a5..d66e6c742bbe 100644
> > > > --- a/arch/arm64/kvm/guest.c
> > > > +++ b/arch/arm64/kvm/guest.c
> > > > @@ -65,6 +65,7 @@ const struct kvm_stats_header kvm_vcpu_stats_header = {
> > > > static const u64 kvm_arm_vm_scope_fw_regs[] = {
> > > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> > > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > > > + KVM_REG_ARM_STD_BMAP,
> > > > };
> > > >
> > > > /**
> > > > diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> > > > index 8624e6964940..48c126c3da72 100644
> > > > --- a/arch/arm64/kvm/hypercalls.c
> > > > +++ b/arch/arm64/kvm/hypercalls.c
> > > > @@ -58,6 +58,29 @@ static void kvm_ptp_get_time(struct kvm_vcpu *vcpu, u64 *val)
> > > > val[3] = lower_32_bits(cycles);
> > > > }
> > > >
> > > > +static bool kvm_arm_fw_reg_feat_enabled(u64 reg_bmap, u64 feat_bit)
> > > > +{
> > > > + return reg_bmap & feat_bit;
> > > > +}
> > > > +
> > > > +static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> > > > +{
> > > > + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> > > > +
> > > > + switch (func_id) {
> > > > + case ARM_SMCCC_TRNG_VERSION:
> > > > + case ARM_SMCCC_TRNG_FEATURES:
> > > > + case ARM_SMCCC_TRNG_GET_UUID:
> > > > + case ARM_SMCCC_TRNG_RND32:
> > > > + case ARM_SMCCC_TRNG_RND64:
> > > > + return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_bmap,
> > > > + KVM_REG_ARM_STD_BIT_TRNG_V1_0);
> > > > + default:
> > > > + /* By default, allow the services that aren't listed here */
> > > > + return true;
> > >
> > > I think your default case should really return false. It keeps people
> > > honest when they add new patches to set up a new hypercall bit (no bit?
> > > no call!)
> > >
> > > That of course requires that you only return false once all of the
> > > preexisting hypercalls are enumerated, otherwise such a patch would
> > > cause a regression in isolation.
> > >
> > I agree, but not all hypercalls may have a bit. For example, guarding
> > ARM_SMCCC_VERSION_FUNC_ID doesn't make sense and may not be gated by
> > the bit. Hence, the idea was to do an initial check if the func_id is
> > in fact gated. If yes, check the bit, else let the actual
> > implementation take care of it.
>
> The set of hypercalls that are not under userspace control need to exist
> on an allowlist then. Any new hypercall after the introduction of these
> registers must have a bit assigned then, right? Otherwise it would seem
> that new hypercalls could sneak into the guest ABI when migrating to an
> upgraded kernel.
>
Ah, I see your point. I agree, I can create an allowed-list of the
func_ids that are not under user-space's control.
Thanks for your review.
Regards,
Raghavendra
> >
> > > > +}
> > > > +
> > > > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > > > {
> > > > u32 func_id = smccc_get_function(vcpu);
> > > > @@ -65,6 +88,9 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > > > u32 feature;
> > > > gpa_t gpa;
> > > >
> > > > + if (!kvm_hvc_call_supported(vcpu, func_id))
> > > > + goto out;
> > > > +
> > > > switch (func_id) {
> > > > case ARM_SMCCC_VERSION_FUNC_ID:
> > > > val[0] = ARM_SMCCC_VERSION_1_1;
> > > > @@ -143,6 +169,7 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > > > return kvm_psci_call(vcpu);
> > > > }
> > > >
> > > > +out:
> > > > smccc_set_retval(vcpu, val[0], val[1], val[2], val[3]);
> > > > return 1;
> > > > }
> > > > @@ -151,8 +178,16 @@ static const u64 kvm_arm_fw_reg_ids[] = {
> > > > KVM_REG_ARM_PSCI_VERSION,
> > > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> > > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > > > + KVM_REG_ARM_STD_BMAP,
> > > > };
> > > >
> > > > +void kvm_arm_init_hypercalls(struct kvm *kvm)
> > > > +{
> > > > + struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
> > > > +
> > > > + hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
> > > > +}
> > > > +
> > > > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> > > > {
> > > > return ARRAY_SIZE(kvm_arm_fw_reg_ids);
> > > > @@ -220,6 +255,7 @@ static int get_kernel_wa_level(u64 regid)
> > > >
> > > > int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > > {
> > > > + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> > > > void __user *uaddr = (void __user *)(long)reg->addr;
> > > > u64 val, reg_id = reg->id;
> > > >
> > > > @@ -233,6 +269,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > > case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> > > > val = get_kernel_wa_level(reg_id) & KVM_REG_FEATURE_LEVEL_MASK;
> > > > break;
> > > > + case KVM_REG_ARM_STD_BMAP:
> > > > + val = READ_ONCE(hvc_desc->hvc_std_bmap);
> > > > + break;
> > > > default:
> > > > return -ENOENT;
> > > > }
> > > > @@ -243,6 +282,43 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > > return 0;
> > > > }
> > > >
> > > > +static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
> > > > +{
> > > > + int ret = 0;
> > > > + struct kvm *kvm = vcpu->kvm;
> > > > + struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
> > > > + u64 *fw_reg_bmap, fw_reg_features;
> > >
> > > nit: use reverse fir tree ordering for locals (longest line first,
> > > shortest last).
> > >
> > Got it.
> > > > + switch (reg_id) {
> > > > + case KVM_REG_ARM_STD_BMAP:
> > > > + fw_reg_bmap = &hvc_desc->hvc_std_bmap;
> > > > + fw_reg_features = ARM_SMCCC_STD_FEATURES;
> > > > + break;
> > > > + default:
> > > > + return -ENOENT;
> > > > + }
> > > > +
> > > > + /* Check for unsupported bit */
> > > > + if (val & ~fw_reg_features)
> > > > + return -EINVAL;
> > > > +
> > > > + mutex_lock(&kvm->lock);
> > > > +
> > > > + /*
> > > > + * If the VM (any vCPU) has already started running, return success
> > > > + * if there's no change in the value. Else, return -EBUSY.
> > >
> > > How about returning -EINVAL instead? We already do this for
> > > KVM_ARM_VCPU_INIT if userspace uses a different target than the one
> > > previously set.
> > >
> > Returning EBUSY could help userspace distinguish the cause of failure
> > better as compared to EINVAL, since technically, the arguments
> > supplied by the user are in fact valid. It's just that the timing is
> > wrong.
> >
>
> Good point :-) Also, this matches the PMU event filter handling as well.
> Apologies.
>
> > > > + */
> > > > + if (kvm_arm_vm_has_run_once(&kvm->arch)) {
> > > > + ret = *fw_reg_bmap != val ? -EBUSY : 0;
> > > > + goto out;
> > > > + }
> > > > +
> > > > + WRITE_ONCE(*fw_reg_bmap, val);
> > > > +out:
> > > > + mutex_unlock(&kvm->lock);
> > > > + return ret;
> > > > +}
> > > > +
> > > > int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > > {
> > > > void __user *uaddr = (void __user *)(long)reg->addr;
> > > > @@ -321,6 +397,8 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > > return -EINVAL;
> > > >
> > > > return 0;
> > > > + case KVM_REG_ARM_STD_BMAP:
> > > > + return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
> > > > default:
> > > > return -ENOENT;
> > > > }
> > > > diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> > > > index 5d38628a8d04..64d30b452809 100644
> > > > --- a/include/kvm/arm_hypercalls.h
> > > > +++ b/include/kvm/arm_hypercalls.h
> > > > @@ -6,6 +6,9 @@
> > > >
> > > > #include <asm/kvm_emulate.h>
> > > >
> > > > +#define ARM_SMCCC_STD_FEATURES \
> > > > + GENMASK_ULL(KVM_REG_ARM_STD_BMAP_BIT_MAX, 0)
> > > > +
> > >
> > > This probably needs KVM_ somewhere in its name for the sake of scoping.
> > >
> > RIght, I can append that.
> >
> > > > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
> > > >
> > > > static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
> > > > @@ -42,6 +45,7 @@ static inline void smccc_set_retval(struct kvm_vcpu *vcpu,
> > > >
> > > > struct kvm_one_reg;
> > > >
> > > > +void kvm_arm_init_hypercalls(struct kvm *kvm);
> > > > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
> > > > int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
> > > > int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> > > > --
> > > > 2.35.1.473.g83b2b277ed-goog
> > > >
> >
> > Regards,
> > Raghavendra
> >
> > [1]: https://lore.kernel.org/linux-arm-kernel/CAJHc60y6b-scY8zcPuLnjGtr6HzSBnmhi2mCnmkNm4nTxgMTUQ@mail.gmail.com/
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 05/13] KVM: arm64: Setup a framework for hypercall bitmap firmware registers
@ 2022-03-15 16:59 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-03-15 16:59 UTC (permalink / raw)
To: Oliver Upton
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Tue, Mar 15, 2022 at 12:25 AM Oliver Upton <oupton@google.com> wrote:
>
> On Mon, Mar 14, 2022 at 05:22:31PM -0700, Raghavendra Rao Ananta wrote:
> > Hi Oliver,
> >
> > On Mon, Mar 14, 2022 at 12:41 PM Oliver Upton <oupton@google.com> wrote:
> > >
> > > On Thu, Feb 24, 2022 at 05:25:51PM +0000, Raghavendra Rao Ananta wrote:
> > > > KVM regularly introduces new hypercall services to the guests without
> > > > any consent from the userspace. This means, the guests can observe
> > > > hypercall services in and out as they migrate across various host
> > > > kernel versions. This could be a major problem if the guest
> > > > discovered a hypercall, started using it, and after getting migrated
> > > > to an older kernel realizes that it's no longer available. Depending
> > > > on how the guest handles the change, there's a potential chance that
> > > > the guest would just panic.
> > > >
> > > > As a result, there's a need for the userspace to elect the services
> > > > that it wishes the guest to discover. It can elect these services
> > > > based on the kernels spread across its (migration) fleet. To remedy
> > > > this, extend the existing firmware psuedo-registers, such as
> > > > KVM_REG_ARM_PSCI_VERSION, for all the hypercall services available.
> > > >
> > > > These firmware registers are categorized based on the service call
> > > > owners, and unlike the existing firmware psuedo-registers, they hold
> > > > the features supported in the form of a bitmap.
> > > >
> > > > During the VM initialization, the registers holds an upper-limit of
> > > > the features supported by the corresponding registers. It's expected
> > > > that the VMMs discover the features provided by each register via
> > > > GET_ONE_REG, and writeback the desired values using SET_ONE_REG.
> > > > KVM allows this modification only until the VM has started.
> > > >
> > > > Older userspace code can simply ignore the capability and the
> > > > hypercall services will be exposed unconditionally to the guests, thus
> > > > ensuring backward compatibility.
> > > >
> > > > In this patch, the framework adds the register only for ARM's standard
> > > > secure services (owner value 4). Currently, this includes support only
> > > > for ARM True Random Number Generator (TRNG) service, with bit-0 of the
> > > > register representing mandatory features of v1.0. The register is also
> > > > added to the kvm_arm_vm_scope_fw_regs[] list as it maintains its state
> > > > per-VM. Other services are momentarily added in the upcoming patches.
> > > >
> > > > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > > > ---
> > > > arch/arm64/include/asm/kvm_host.h | 12 +++++
> > > > arch/arm64/include/uapi/asm/kvm.h | 8 ++++
> > > > arch/arm64/kvm/arm.c | 8 ++++
> > > > arch/arm64/kvm/guest.c | 1 +
> > > > arch/arm64/kvm/hypercalls.c | 78 +++++++++++++++++++++++++++++++
> > > > include/kvm/arm_hypercalls.h | 4 ++
> > > > 6 files changed, 111 insertions(+)
> > > >
> > > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > > > index e823571e50cc..1909ced3208f 100644
> > > > --- a/arch/arm64/include/asm/kvm_host.h
> > > > +++ b/arch/arm64/include/asm/kvm_host.h
> > > > @@ -101,6 +101,15 @@ struct kvm_s2_mmu {
> > > > struct kvm_arch_memory_slot {
> > > > };
> > > >
> > > > +/**
> > > > + * struct kvm_hvc_desc: KVM ARM64 hypercall descriptor
> > > > + *
> > > > + * @hvc_std_bmap: Bitmap of standard secure service calls
> > > > + */
> > > > +struct kvm_hvc_desc {
> > >
> > > nit: maybe call this structure kvm_hypercall_features? When nested comes
> > > along guests will need to use the SVC conduit as HVC traps are always
> > > taken to EL2. Same will need to be true for virtual EL2.
> > >
> > Sure, I can rename it to be more generic.
> >
> > > > + u64 hvc_std_bmap;
> > > > +};
> > > > +
> > > > struct kvm_arch {
> > > > struct kvm_s2_mmu mmu;
> > > >
> > > > @@ -142,6 +151,9 @@ struct kvm_arch {
> > > >
> > > > /* Capture first run of the VM */
> > > > bool has_run_once;
> > > > +
> > > > + /* Hypercall firmware register' descriptor */
> > > > + struct kvm_hvc_desc hvc_desc;
> > > > };
> > > >
> > > > struct kvm_vcpu_fault_info {
> > > > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > > > index c35447cc0e0c..2decc30d6b84 100644
> > > > --- a/arch/arm64/include/uapi/asm/kvm.h
> > > > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > > > @@ -287,6 +287,14 @@ struct kvm_arm_copy_mte_tags {
> > > > #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED 3
> > > > #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED (1U << 4)
> > > >
> > > > +/* Bitmap firmware registers, extension to the existing psuedo-register space */
> > > > +#define KVM_REG_ARM_FW_BMAP KVM_REG_ARM_FW_REG(0xff00)
> > >
> > > What is the motivation for moving the bitmap register indices so far
> > > away from the rest of the firmware regs?
> > >
> > The original motivation to create a sub-space came from Reiji's
> > comment on v3 [1] so that user-space can distinguish between bitmapped
> > and regular fw registers.
> > As with the spacing, I thought a 50/50 split would do a good job of
> > avoiding collisions. Do you have any recommendations here?
> >
>
> I see. This is for the sake of ABI stability with future expansion,
> right? A new register could be added in the future that controls more
> SMCCC features, and we expect userspace to zero them if it cares about
> ABI stability.
>
> If that is all true, we probably need some strong supporting
> documentation. Additionally, using a new COPROC value for the register
> range might be better than partitioning the existing FW reg range.
>
I assumed the 50/50 split could be fine even for future expansion, but
I can go for a new COPROC value. However, wouldn't the same problem
exist even with that? We could never have enough space :)
> > > > +#define KVM_REG_ARM_FW_BMAP_REG(r) (KVM_REG_ARM_FW_BMAP | (r))
> > >
> > > If you are still going to use the index offset, just pass 'r' through to
> > > the other macro:
> > >
> > > #define KVM_REG_ARM_FW_BMAP_REG(r) KVM_REG_ARM_FW_REG(0xff00 + r)
> > >
> > I'm sorry, what's the advantage of doing this?
> >
> > > > +#define KVM_REG_ARM_STD_BMAP KVM_REG_ARM_FW_BMAP_REG(0)
> > > > +#define KVM_REG_ARM_STD_BIT_TRNG_V1_0 BIT(0)
> > > > +#define KVM_REG_ARM_STD_BMAP_BIT_MAX 0 /* Last valid bit */
> > >
> > > Implementation details such as this probably shouldn't live in UAPI
> > > headers. We'll likely need to bump the value in the future.
> > >
> > Wouldn't the macros act as helpers to userspace as well?
> > I agree with your point about the limited spacing, and we may need to
> > expand/shrink as needed, but isn't that a general register-space
> > problem?
> >
>
> I think that the kernel's responsibility to userspace starts and ends with
> enumerating the register bits. Those values remain invariant on future
> KVM. On the other hand, you'll need to bump the _MAX value every time
> you add to the register. Between documentation and bit definitions,
> userspace should have enough info to work out the rest on its own :)
>
Understood. I'll move the _MAX definitions to the kernel-only headers.
> > > > +
> > > > /* SVE registers */
> > > > #define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
> > > >
> > > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > > > index f61cd8d57eae..e9f9edb1cf55 100644
> > > > --- a/arch/arm64/kvm/arm.c
> > > > +++ b/arch/arm64/kvm/arm.c
> > > > @@ -156,6 +156,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> > > > kvm->arch.max_vcpus = kvm_arm_default_max_vcpus();
> > > >
> > > > set_default_spectre(kvm);
> > > > + kvm_arm_init_hypercalls(kvm);
> > > >
> > > > return ret;
> > > > out_free_stage2_pgd:
> > > > @@ -635,7 +636,14 @@ int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu)
> > > > if (kvm_vm_is_protected(kvm))
> > > > kvm_call_hyp_nvhe(__pkvm_vcpu_init_traps, vcpu);
> > > >
> > > > + /*
> > > > + * Grab kvm->lock such that the reader of has_run_once can finish
> > > > + * the necessary operation atomically, such as deciding whether to
> > > > + * block the writes to the firmware registers if the VM has run once.
> > > > + */
> > > > + mutex_lock(&kvm->lock);
> > > > kvm->arch.has_run_once = true;
> > > > + mutex_unlock(&kvm->lock);
> > >
> > > Shouldn't this have just grabbed the kvm lock in patch 04/13?
> > >
> > It could have, and I agree it's a little igly. But thinking that
> > there's are no parallel threads/consumers when it was initially
> > implemented gave me no reason to grab the locks.
>
> I see, I was just curious if there was something I had missed.
>
> > > > return ret;
> > > > }
> > > > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> > > > index eb061e64a7a5..d66e6c742bbe 100644
> > > > --- a/arch/arm64/kvm/guest.c
> > > > +++ b/arch/arm64/kvm/guest.c
> > > > @@ -65,6 +65,7 @@ const struct kvm_stats_header kvm_vcpu_stats_header = {
> > > > static const u64 kvm_arm_vm_scope_fw_regs[] = {
> > > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> > > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > > > + KVM_REG_ARM_STD_BMAP,
> > > > };
> > > >
> > > > /**
> > > > diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> > > > index 8624e6964940..48c126c3da72 100644
> > > > --- a/arch/arm64/kvm/hypercalls.c
> > > > +++ b/arch/arm64/kvm/hypercalls.c
> > > > @@ -58,6 +58,29 @@ static void kvm_ptp_get_time(struct kvm_vcpu *vcpu, u64 *val)
> > > > val[3] = lower_32_bits(cycles);
> > > > }
> > > >
> > > > +static bool kvm_arm_fw_reg_feat_enabled(u64 reg_bmap, u64 feat_bit)
> > > > +{
> > > > + return reg_bmap & feat_bit;
> > > > +}
> > > > +
> > > > +static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> > > > +{
> > > > + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> > > > +
> > > > + switch (func_id) {
> > > > + case ARM_SMCCC_TRNG_VERSION:
> > > > + case ARM_SMCCC_TRNG_FEATURES:
> > > > + case ARM_SMCCC_TRNG_GET_UUID:
> > > > + case ARM_SMCCC_TRNG_RND32:
> > > > + case ARM_SMCCC_TRNG_RND64:
> > > > + return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_bmap,
> > > > + KVM_REG_ARM_STD_BIT_TRNG_V1_0);
> > > > + default:
> > > > + /* By default, allow the services that aren't listed here */
> > > > + return true;
> > >
> > > I think your default case should really return false. It keeps people
> > > honest when they add new patches to set up a new hypercall bit (no bit?
> > > no call!)
> > >
> > > That of course requires that you only return false once all of the
> > > preexisting hypercalls are enumerated, otherwise such a patch would
> > > cause a regression in isolation.
> > >
> > I agree, but not all hypercalls may have a bit. For example, guarding
> > ARM_SMCCC_VERSION_FUNC_ID doesn't make sense and may not be gated by
> > the bit. Hence, the idea was to do an initial check if the func_id is
> > in fact gated. If yes, check the bit, else let the actual
> > implementation take care of it.
>
> The set of hypercalls that are not under userspace control need to exist
> on an allowlist then. Any new hypercall after the introduction of these
> registers must have a bit assigned then, right? Otherwise it would seem
> that new hypercalls could sneak into the guest ABI when migrating to an
> upgraded kernel.
>
Ah, I see your point. I agree, I can create an allowed-list of the
func_ids that are not under user-space's control.
Thanks for your review.
Regards,
Raghavendra
> >
> > > > +}
> > > > +
> > > > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > > > {
> > > > u32 func_id = smccc_get_function(vcpu);
> > > > @@ -65,6 +88,9 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > > > u32 feature;
> > > > gpa_t gpa;
> > > >
> > > > + if (!kvm_hvc_call_supported(vcpu, func_id))
> > > > + goto out;
> > > > +
> > > > switch (func_id) {
> > > > case ARM_SMCCC_VERSION_FUNC_ID:
> > > > val[0] = ARM_SMCCC_VERSION_1_1;
> > > > @@ -143,6 +169,7 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > > > return kvm_psci_call(vcpu);
> > > > }
> > > >
> > > > +out:
> > > > smccc_set_retval(vcpu, val[0], val[1], val[2], val[3]);
> > > > return 1;
> > > > }
> > > > @@ -151,8 +178,16 @@ static const u64 kvm_arm_fw_reg_ids[] = {
> > > > KVM_REG_ARM_PSCI_VERSION,
> > > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> > > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > > > + KVM_REG_ARM_STD_BMAP,
> > > > };
> > > >
> > > > +void kvm_arm_init_hypercalls(struct kvm *kvm)
> > > > +{
> > > > + struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
> > > > +
> > > > + hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
> > > > +}
> > > > +
> > > > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> > > > {
> > > > return ARRAY_SIZE(kvm_arm_fw_reg_ids);
> > > > @@ -220,6 +255,7 @@ static int get_kernel_wa_level(u64 regid)
> > > >
> > > > int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > > {
> > > > + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> > > > void __user *uaddr = (void __user *)(long)reg->addr;
> > > > u64 val, reg_id = reg->id;
> > > >
> > > > @@ -233,6 +269,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > > case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> > > > val = get_kernel_wa_level(reg_id) & KVM_REG_FEATURE_LEVEL_MASK;
> > > > break;
> > > > + case KVM_REG_ARM_STD_BMAP:
> > > > + val = READ_ONCE(hvc_desc->hvc_std_bmap);
> > > > + break;
> > > > default:
> > > > return -ENOENT;
> > > > }
> > > > @@ -243,6 +282,43 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > > return 0;
> > > > }
> > > >
> > > > +static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
> > > > +{
> > > > + int ret = 0;
> > > > + struct kvm *kvm = vcpu->kvm;
> > > > + struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
> > > > + u64 *fw_reg_bmap, fw_reg_features;
> > >
> > > nit: use reverse fir tree ordering for locals (longest line first,
> > > shortest last).
> > >
> > Got it.
> > > > + switch (reg_id) {
> > > > + case KVM_REG_ARM_STD_BMAP:
> > > > + fw_reg_bmap = &hvc_desc->hvc_std_bmap;
> > > > + fw_reg_features = ARM_SMCCC_STD_FEATURES;
> > > > + break;
> > > > + default:
> > > > + return -ENOENT;
> > > > + }
> > > > +
> > > > + /* Check for unsupported bit */
> > > > + if (val & ~fw_reg_features)
> > > > + return -EINVAL;
> > > > +
> > > > + mutex_lock(&kvm->lock);
> > > > +
> > > > + /*
> > > > + * If the VM (any vCPU) has already started running, return success
> > > > + * if there's no change in the value. Else, return -EBUSY.
> > >
> > > How about returning -EINVAL instead? We already do this for
> > > KVM_ARM_VCPU_INIT if userspace uses a different target than the one
> > > previously set.
> > >
> > Returning EBUSY could help userspace distinguish the cause of failure
> > better as compared to EINVAL, since technically, the arguments
> > supplied by the user are in fact valid. It's just that the timing is
> > wrong.
> >
>
> Good point :-) Also, this matches the PMU event filter handling as well.
> Apologies.
>
> > > > + */
> > > > + if (kvm_arm_vm_has_run_once(&kvm->arch)) {
> > > > + ret = *fw_reg_bmap != val ? -EBUSY : 0;
> > > > + goto out;
> > > > + }
> > > > +
> > > > + WRITE_ONCE(*fw_reg_bmap, val);
> > > > +out:
> > > > + mutex_unlock(&kvm->lock);
> > > > + return ret;
> > > > +}
> > > > +
> > > > int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > > {
> > > > void __user *uaddr = (void __user *)(long)reg->addr;
> > > > @@ -321,6 +397,8 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > > return -EINVAL;
> > > >
> > > > return 0;
> > > > + case KVM_REG_ARM_STD_BMAP:
> > > > + return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
> > > > default:
> > > > return -ENOENT;
> > > > }
> > > > diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> > > > index 5d38628a8d04..64d30b452809 100644
> > > > --- a/include/kvm/arm_hypercalls.h
> > > > +++ b/include/kvm/arm_hypercalls.h
> > > > @@ -6,6 +6,9 @@
> > > >
> > > > #include <asm/kvm_emulate.h>
> > > >
> > > > +#define ARM_SMCCC_STD_FEATURES \
> > > > + GENMASK_ULL(KVM_REG_ARM_STD_BMAP_BIT_MAX, 0)
> > > > +
> > >
> > > This probably needs KVM_ somewhere in its name for the sake of scoping.
> > >
> > RIght, I can append that.
> >
> > > > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
> > > >
> > > > static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
> > > > @@ -42,6 +45,7 @@ static inline void smccc_set_retval(struct kvm_vcpu *vcpu,
> > > >
> > > > struct kvm_one_reg;
> > > >
> > > > +void kvm_arm_init_hypercalls(struct kvm *kvm);
> > > > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
> > > > int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
> > > > int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> > > > --
> > > > 2.35.1.473.g83b2b277ed-goog
> > > >
> >
> > Regards,
> > Raghavendra
> >
> > [1]: https://lore.kernel.org/linux-arm-kernel/CAJHc60y6b-scY8zcPuLnjGtr6HzSBnmhi2mCnmkNm4nTxgMTUQ@mail.gmail.com/
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 05/13] KVM: arm64: Setup a framework for hypercall bitmap firmware registers
@ 2022-03-15 16:59 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-03-15 16:59 UTC (permalink / raw)
To: Oliver Upton
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Tue, Mar 15, 2022 at 12:25 AM Oliver Upton <oupton@google.com> wrote:
>
> On Mon, Mar 14, 2022 at 05:22:31PM -0700, Raghavendra Rao Ananta wrote:
> > Hi Oliver,
> >
> > On Mon, Mar 14, 2022 at 12:41 PM Oliver Upton <oupton@google.com> wrote:
> > >
> > > On Thu, Feb 24, 2022 at 05:25:51PM +0000, Raghavendra Rao Ananta wrote:
> > > > KVM regularly introduces new hypercall services to the guests without
> > > > any consent from the userspace. This means, the guests can observe
> > > > hypercall services in and out as they migrate across various host
> > > > kernel versions. This could be a major problem if the guest
> > > > discovered a hypercall, started using it, and after getting migrated
> > > > to an older kernel realizes that it's no longer available. Depending
> > > > on how the guest handles the change, there's a potential chance that
> > > > the guest would just panic.
> > > >
> > > > As a result, there's a need for the userspace to elect the services
> > > > that it wishes the guest to discover. It can elect these services
> > > > based on the kernels spread across its (migration) fleet. To remedy
> > > > this, extend the existing firmware psuedo-registers, such as
> > > > KVM_REG_ARM_PSCI_VERSION, for all the hypercall services available.
> > > >
> > > > These firmware registers are categorized based on the service call
> > > > owners, and unlike the existing firmware psuedo-registers, they hold
> > > > the features supported in the form of a bitmap.
> > > >
> > > > During the VM initialization, the registers holds an upper-limit of
> > > > the features supported by the corresponding registers. It's expected
> > > > that the VMMs discover the features provided by each register via
> > > > GET_ONE_REG, and writeback the desired values using SET_ONE_REG.
> > > > KVM allows this modification only until the VM has started.
> > > >
> > > > Older userspace code can simply ignore the capability and the
> > > > hypercall services will be exposed unconditionally to the guests, thus
> > > > ensuring backward compatibility.
> > > >
> > > > In this patch, the framework adds the register only for ARM's standard
> > > > secure services (owner value 4). Currently, this includes support only
> > > > for ARM True Random Number Generator (TRNG) service, with bit-0 of the
> > > > register representing mandatory features of v1.0. The register is also
> > > > added to the kvm_arm_vm_scope_fw_regs[] list as it maintains its state
> > > > per-VM. Other services are momentarily added in the upcoming patches.
> > > >
> > > > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > > > ---
> > > > arch/arm64/include/asm/kvm_host.h | 12 +++++
> > > > arch/arm64/include/uapi/asm/kvm.h | 8 ++++
> > > > arch/arm64/kvm/arm.c | 8 ++++
> > > > arch/arm64/kvm/guest.c | 1 +
> > > > arch/arm64/kvm/hypercalls.c | 78 +++++++++++++++++++++++++++++++
> > > > include/kvm/arm_hypercalls.h | 4 ++
> > > > 6 files changed, 111 insertions(+)
> > > >
> > > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > > > index e823571e50cc..1909ced3208f 100644
> > > > --- a/arch/arm64/include/asm/kvm_host.h
> > > > +++ b/arch/arm64/include/asm/kvm_host.h
> > > > @@ -101,6 +101,15 @@ struct kvm_s2_mmu {
> > > > struct kvm_arch_memory_slot {
> > > > };
> > > >
> > > > +/**
> > > > + * struct kvm_hvc_desc: KVM ARM64 hypercall descriptor
> > > > + *
> > > > + * @hvc_std_bmap: Bitmap of standard secure service calls
> > > > + */
> > > > +struct kvm_hvc_desc {
> > >
> > > nit: maybe call this structure kvm_hypercall_features? When nested comes
> > > along guests will need to use the SVC conduit as HVC traps are always
> > > taken to EL2. Same will need to be true for virtual EL2.
> > >
> > Sure, I can rename it to be more generic.
> >
> > > > + u64 hvc_std_bmap;
> > > > +};
> > > > +
> > > > struct kvm_arch {
> > > > struct kvm_s2_mmu mmu;
> > > >
> > > > @@ -142,6 +151,9 @@ struct kvm_arch {
> > > >
> > > > /* Capture first run of the VM */
> > > > bool has_run_once;
> > > > +
> > > > + /* Hypercall firmware register' descriptor */
> > > > + struct kvm_hvc_desc hvc_desc;
> > > > };
> > > >
> > > > struct kvm_vcpu_fault_info {
> > > > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > > > index c35447cc0e0c..2decc30d6b84 100644
> > > > --- a/arch/arm64/include/uapi/asm/kvm.h
> > > > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > > > @@ -287,6 +287,14 @@ struct kvm_arm_copy_mte_tags {
> > > > #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED 3
> > > > #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED (1U << 4)
> > > >
> > > > +/* Bitmap firmware registers, extension to the existing psuedo-register space */
> > > > +#define KVM_REG_ARM_FW_BMAP KVM_REG_ARM_FW_REG(0xff00)
> > >
> > > What is the motivation for moving the bitmap register indices so far
> > > away from the rest of the firmware regs?
> > >
> > The original motivation to create a sub-space came from Reiji's
> > comment on v3 [1] so that user-space can distinguish between bitmapped
> > and regular fw registers.
> > As with the spacing, I thought a 50/50 split would do a good job of
> > avoiding collisions. Do you have any recommendations here?
> >
>
> I see. This is for the sake of ABI stability with future expansion,
> right? A new register could be added in the future that controls more
> SMCCC features, and we expect userspace to zero them if it cares about
> ABI stability.
>
> If that is all true, we probably need some strong supporting
> documentation. Additionally, using a new COPROC value for the register
> range might be better than partitioning the existing FW reg range.
>
I assumed the 50/50 split could be fine even for future expansion, but
I can go for a new COPROC value. However, wouldn't the same problem
exist even with that? We could never have enough space :)
> > > > +#define KVM_REG_ARM_FW_BMAP_REG(r) (KVM_REG_ARM_FW_BMAP | (r))
> > >
> > > If you are still going to use the index offset, just pass 'r' through to
> > > the other macro:
> > >
> > > #define KVM_REG_ARM_FW_BMAP_REG(r) KVM_REG_ARM_FW_REG(0xff00 + r)
> > >
> > I'm sorry, what's the advantage of doing this?
> >
> > > > +#define KVM_REG_ARM_STD_BMAP KVM_REG_ARM_FW_BMAP_REG(0)
> > > > +#define KVM_REG_ARM_STD_BIT_TRNG_V1_0 BIT(0)
> > > > +#define KVM_REG_ARM_STD_BMAP_BIT_MAX 0 /* Last valid bit */
> > >
> > > Implementation details such as this probably shouldn't live in UAPI
> > > headers. We'll likely need to bump the value in the future.
> > >
> > Wouldn't the macros act as helpers to userspace as well?
> > I agree with your point about the limited spacing, and we may need to
> > expand/shrink as needed, but isn't that a general register-space
> > problem?
> >
>
> I think that the kernel's responsibility to userspace starts and ends with
> enumerating the register bits. Those values remain invariant on future
> KVM. On the other hand, you'll need to bump the _MAX value every time
> you add to the register. Between documentation and bit definitions,
> userspace should have enough info to work out the rest on its own :)
>
Understood. I'll move the _MAX definitions to the kernel-only headers.
> > > > +
> > > > /* SVE registers */
> > > > #define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
> > > >
> > > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > > > index f61cd8d57eae..e9f9edb1cf55 100644
> > > > --- a/arch/arm64/kvm/arm.c
> > > > +++ b/arch/arm64/kvm/arm.c
> > > > @@ -156,6 +156,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> > > > kvm->arch.max_vcpus = kvm_arm_default_max_vcpus();
> > > >
> > > > set_default_spectre(kvm);
> > > > + kvm_arm_init_hypercalls(kvm);
> > > >
> > > > return ret;
> > > > out_free_stage2_pgd:
> > > > @@ -635,7 +636,14 @@ int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu)
> > > > if (kvm_vm_is_protected(kvm))
> > > > kvm_call_hyp_nvhe(__pkvm_vcpu_init_traps, vcpu);
> > > >
> > > > + /*
> > > > + * Grab kvm->lock such that the reader of has_run_once can finish
> > > > + * the necessary operation atomically, such as deciding whether to
> > > > + * block the writes to the firmware registers if the VM has run once.
> > > > + */
> > > > + mutex_lock(&kvm->lock);
> > > > kvm->arch.has_run_once = true;
> > > > + mutex_unlock(&kvm->lock);
> > >
> > > Shouldn't this have just grabbed the kvm lock in patch 04/13?
> > >
> > It could have, and I agree it's a little igly. But thinking that
> > there's are no parallel threads/consumers when it was initially
> > implemented gave me no reason to grab the locks.
>
> I see, I was just curious if there was something I had missed.
>
> > > > return ret;
> > > > }
> > > > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> > > > index eb061e64a7a5..d66e6c742bbe 100644
> > > > --- a/arch/arm64/kvm/guest.c
> > > > +++ b/arch/arm64/kvm/guest.c
> > > > @@ -65,6 +65,7 @@ const struct kvm_stats_header kvm_vcpu_stats_header = {
> > > > static const u64 kvm_arm_vm_scope_fw_regs[] = {
> > > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> > > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > > > + KVM_REG_ARM_STD_BMAP,
> > > > };
> > > >
> > > > /**
> > > > diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> > > > index 8624e6964940..48c126c3da72 100644
> > > > --- a/arch/arm64/kvm/hypercalls.c
> > > > +++ b/arch/arm64/kvm/hypercalls.c
> > > > @@ -58,6 +58,29 @@ static void kvm_ptp_get_time(struct kvm_vcpu *vcpu, u64 *val)
> > > > val[3] = lower_32_bits(cycles);
> > > > }
> > > >
> > > > +static bool kvm_arm_fw_reg_feat_enabled(u64 reg_bmap, u64 feat_bit)
> > > > +{
> > > > + return reg_bmap & feat_bit;
> > > > +}
> > > > +
> > > > +static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> > > > +{
> > > > + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> > > > +
> > > > + switch (func_id) {
> > > > + case ARM_SMCCC_TRNG_VERSION:
> > > > + case ARM_SMCCC_TRNG_FEATURES:
> > > > + case ARM_SMCCC_TRNG_GET_UUID:
> > > > + case ARM_SMCCC_TRNG_RND32:
> > > > + case ARM_SMCCC_TRNG_RND64:
> > > > + return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_bmap,
> > > > + KVM_REG_ARM_STD_BIT_TRNG_V1_0);
> > > > + default:
> > > > + /* By default, allow the services that aren't listed here */
> > > > + return true;
> > >
> > > I think your default case should really return false. It keeps people
> > > honest when they add new patches to set up a new hypercall bit (no bit?
> > > no call!)
> > >
> > > That of course requires that you only return false once all of the
> > > preexisting hypercalls are enumerated, otherwise such a patch would
> > > cause a regression in isolation.
> > >
> > I agree, but not all hypercalls may have a bit. For example, guarding
> > ARM_SMCCC_VERSION_FUNC_ID doesn't make sense and may not be gated by
> > the bit. Hence, the idea was to do an initial check if the func_id is
> > in fact gated. If yes, check the bit, else let the actual
> > implementation take care of it.
>
> The set of hypercalls that are not under userspace control need to exist
> on an allowlist then. Any new hypercall after the introduction of these
> registers must have a bit assigned then, right? Otherwise it would seem
> that new hypercalls could sneak into the guest ABI when migrating to an
> upgraded kernel.
>
Ah, I see your point. I agree, I can create an allowed-list of the
func_ids that are not under user-space's control.
Thanks for your review.
Regards,
Raghavendra
> >
> > > > +}
> > > > +
> > > > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > > > {
> > > > u32 func_id = smccc_get_function(vcpu);
> > > > @@ -65,6 +88,9 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > > > u32 feature;
> > > > gpa_t gpa;
> > > >
> > > > + if (!kvm_hvc_call_supported(vcpu, func_id))
> > > > + goto out;
> > > > +
> > > > switch (func_id) {
> > > > case ARM_SMCCC_VERSION_FUNC_ID:
> > > > val[0] = ARM_SMCCC_VERSION_1_1;
> > > > @@ -143,6 +169,7 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > > > return kvm_psci_call(vcpu);
> > > > }
> > > >
> > > > +out:
> > > > smccc_set_retval(vcpu, val[0], val[1], val[2], val[3]);
> > > > return 1;
> > > > }
> > > > @@ -151,8 +178,16 @@ static const u64 kvm_arm_fw_reg_ids[] = {
> > > > KVM_REG_ARM_PSCI_VERSION,
> > > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> > > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > > > + KVM_REG_ARM_STD_BMAP,
> > > > };
> > > >
> > > > +void kvm_arm_init_hypercalls(struct kvm *kvm)
> > > > +{
> > > > + struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
> > > > +
> > > > + hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
> > > > +}
> > > > +
> > > > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> > > > {
> > > > return ARRAY_SIZE(kvm_arm_fw_reg_ids);
> > > > @@ -220,6 +255,7 @@ static int get_kernel_wa_level(u64 regid)
> > > >
> > > > int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > > {
> > > > + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> > > > void __user *uaddr = (void __user *)(long)reg->addr;
> > > > u64 val, reg_id = reg->id;
> > > >
> > > > @@ -233,6 +269,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > > case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
> > > > val = get_kernel_wa_level(reg_id) & KVM_REG_FEATURE_LEVEL_MASK;
> > > > break;
> > > > + case KVM_REG_ARM_STD_BMAP:
> > > > + val = READ_ONCE(hvc_desc->hvc_std_bmap);
> > > > + break;
> > > > default:
> > > > return -ENOENT;
> > > > }
> > > > @@ -243,6 +282,43 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > > return 0;
> > > > }
> > > >
> > > > +static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
> > > > +{
> > > > + int ret = 0;
> > > > + struct kvm *kvm = vcpu->kvm;
> > > > + struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
> > > > + u64 *fw_reg_bmap, fw_reg_features;
> > >
> > > nit: use reverse fir tree ordering for locals (longest line first,
> > > shortest last).
> > >
> > Got it.
> > > > + switch (reg_id) {
> > > > + case KVM_REG_ARM_STD_BMAP:
> > > > + fw_reg_bmap = &hvc_desc->hvc_std_bmap;
> > > > + fw_reg_features = ARM_SMCCC_STD_FEATURES;
> > > > + break;
> > > > + default:
> > > > + return -ENOENT;
> > > > + }
> > > > +
> > > > + /* Check for unsupported bit */
> > > > + if (val & ~fw_reg_features)
> > > > + return -EINVAL;
> > > > +
> > > > + mutex_lock(&kvm->lock);
> > > > +
> > > > + /*
> > > > + * If the VM (any vCPU) has already started running, return success
> > > > + * if there's no change in the value. Else, return -EBUSY.
> > >
> > > How about returning -EINVAL instead? We already do this for
> > > KVM_ARM_VCPU_INIT if userspace uses a different target than the one
> > > previously set.
> > >
> > Returning EBUSY could help userspace distinguish the cause of failure
> > better as compared to EINVAL, since technically, the arguments
> > supplied by the user are in fact valid. It's just that the timing is
> > wrong.
> >
>
> Good point :-) Also, this matches the PMU event filter handling as well.
> Apologies.
>
> > > > + */
> > > > + if (kvm_arm_vm_has_run_once(&kvm->arch)) {
> > > > + ret = *fw_reg_bmap != val ? -EBUSY : 0;
> > > > + goto out;
> > > > + }
> > > > +
> > > > + WRITE_ONCE(*fw_reg_bmap, val);
> > > > +out:
> > > > + mutex_unlock(&kvm->lock);
> > > > + return ret;
> > > > +}
> > > > +
> > > > int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > > {
> > > > void __user *uaddr = (void __user *)(long)reg->addr;
> > > > @@ -321,6 +397,8 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > > return -EINVAL;
> > > >
> > > > return 0;
> > > > + case KVM_REG_ARM_STD_BMAP:
> > > > + return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
> > > > default:
> > > > return -ENOENT;
> > > > }
> > > > diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> > > > index 5d38628a8d04..64d30b452809 100644
> > > > --- a/include/kvm/arm_hypercalls.h
> > > > +++ b/include/kvm/arm_hypercalls.h
> > > > @@ -6,6 +6,9 @@
> > > >
> > > > #include <asm/kvm_emulate.h>
> > > >
> > > > +#define ARM_SMCCC_STD_FEATURES \
> > > > + GENMASK_ULL(KVM_REG_ARM_STD_BMAP_BIT_MAX, 0)
> > > > +
> > >
> > > This probably needs KVM_ somewhere in its name for the sake of scoping.
> > >
> > RIght, I can append that.
> >
> > > > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
> > > >
> > > > static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
> > > > @@ -42,6 +45,7 @@ static inline void smccc_set_retval(struct kvm_vcpu *vcpu,
> > > >
> > > > struct kvm_one_reg;
> > > >
> > > > +void kvm_arm_init_hypercalls(struct kvm *kvm);
> > > > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu);
> > > > int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
> > > > int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> > > > --
> > > > 2.35.1.473.g83b2b277ed-goog
> > > >
> >
> > Regards,
> > Raghavendra
> >
> > [1]: https://lore.kernel.org/linux-arm-kernel/CAJHc60y6b-scY8zcPuLnjGtr6HzSBnmhi2mCnmkNm4nTxgMTUQ@mail.gmail.com/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 05/13] KVM: arm64: Setup a framework for hypercall bitmap firmware registers
2022-03-15 16:59 ` Raghavendra Rao Ananta
(?)
@ 2022-03-15 17:35 ` Oliver Upton
-1 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-15 17:35 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: kvm, Will Deacon, Marc Zyngier, Peter Shier, linux-kernel,
Catalin Marinas, Paolo Bonzini, kvmarm, linux-arm-kernel
On Tue, Mar 15, 2022 at 09:59:35AM -0700, Raghavendra Rao Ananta wrote:
> On Tue, Mar 15, 2022 at 12:25 AM Oliver Upton <oupton@google.com> wrote:
> >
> > On Mon, Mar 14, 2022 at 05:22:31PM -0700, Raghavendra Rao Ananta wrote:
> > > Hi Oliver,
> > >
> > > On Mon, Mar 14, 2022 at 12:41 PM Oliver Upton <oupton@google.com> wrote:
> > > >
> > > > On Thu, Feb 24, 2022 at 05:25:51PM +0000, Raghavendra Rao Ananta wrote:
> > > > > KVM regularly introduces new hypercall services to the guests without
> > > > > any consent from the userspace. This means, the guests can observe
> > > > > hypercall services in and out as they migrate across various host
> > > > > kernel versions. This could be a major problem if the guest
> > > > > discovered a hypercall, started using it, and after getting migrated
> > > > > to an older kernel realizes that it's no longer available. Depending
> > > > > on how the guest handles the change, there's a potential chance that
> > > > > the guest would just panic.
> > > > >
> > > > > As a result, there's a need for the userspace to elect the services
> > > > > that it wishes the guest to discover. It can elect these services
> > > > > based on the kernels spread across its (migration) fleet. To remedy
> > > > > this, extend the existing firmware psuedo-registers, such as
> > > > > KVM_REG_ARM_PSCI_VERSION, for all the hypercall services available.
> > > > >
> > > > > These firmware registers are categorized based on the service call
> > > > > owners, and unlike the existing firmware psuedo-registers, they hold
> > > > > the features supported in the form of a bitmap.
> > > > >
> > > > > During the VM initialization, the registers holds an upper-limit of
> > > > > the features supported by the corresponding registers. It's expected
> > > > > that the VMMs discover the features provided by each register via
> > > > > GET_ONE_REG, and writeback the desired values using SET_ONE_REG.
> > > > > KVM allows this modification only until the VM has started.
> > > > >
> > > > > Older userspace code can simply ignore the capability and the
> > > > > hypercall services will be exposed unconditionally to the guests, thus
> > > > > ensuring backward compatibility.
> > > > >
> > > > > In this patch, the framework adds the register only for ARM's standard
> > > > > secure services (owner value 4). Currently, this includes support only
> > > > > for ARM True Random Number Generator (TRNG) service, with bit-0 of the
> > > > > register representing mandatory features of v1.0. The register is also
> > > > > added to the kvm_arm_vm_scope_fw_regs[] list as it maintains its state
> > > > > per-VM. Other services are momentarily added in the upcoming patches.
> > > > >
> > > > > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > > > > ---
> > > > > arch/arm64/include/asm/kvm_host.h | 12 +++++
> > > > > arch/arm64/include/uapi/asm/kvm.h | 8 ++++
> > > > > arch/arm64/kvm/arm.c | 8 ++++
> > > > > arch/arm64/kvm/guest.c | 1 +
> > > > > arch/arm64/kvm/hypercalls.c | 78 +++++++++++++++++++++++++++++++
> > > > > include/kvm/arm_hypercalls.h | 4 ++
> > > > > 6 files changed, 111 insertions(+)
> > > > >
> > > > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > > > > index e823571e50cc..1909ced3208f 100644
> > > > > --- a/arch/arm64/include/asm/kvm_host.h
> > > > > +++ b/arch/arm64/include/asm/kvm_host.h
> > > > > @@ -101,6 +101,15 @@ struct kvm_s2_mmu {
> > > > > struct kvm_arch_memory_slot {
> > > > > };
> > > > >
> > > > > +/**
> > > > > + * struct kvm_hvc_desc: KVM ARM64 hypercall descriptor
> > > > > + *
> > > > > + * @hvc_std_bmap: Bitmap of standard secure service calls
> > > > > + */
> > > > > +struct kvm_hvc_desc {
> > > >
> > > > nit: maybe call this structure kvm_hypercall_features? When nested comes
> > > > along guests will need to use the SVC conduit as HVC traps are always
> > > > taken to EL2. Same will need to be true for virtual EL2.
> > > >
> > > Sure, I can rename it to be more generic.
> > >
> > > > > + u64 hvc_std_bmap;
> > > > > +};
> > > > > +
> > > > > struct kvm_arch {
> > > > > struct kvm_s2_mmu mmu;
> > > > >
> > > > > @@ -142,6 +151,9 @@ struct kvm_arch {
> > > > >
> > > > > /* Capture first run of the VM */
> > > > > bool has_run_once;
> > > > > +
> > > > > + /* Hypercall firmware register' descriptor */
> > > > > + struct kvm_hvc_desc hvc_desc;
> > > > > };
> > > > >
> > > > > struct kvm_vcpu_fault_info {
> > > > > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > > > > index c35447cc0e0c..2decc30d6b84 100644
> > > > > --- a/arch/arm64/include/uapi/asm/kvm.h
> > > > > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > > > > @@ -287,6 +287,14 @@ struct kvm_arm_copy_mte_tags {
> > > > > #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED 3
> > > > > #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED (1U << 4)
> > > > >
> > > > > +/* Bitmap firmware registers, extension to the existing psuedo-register space */
> > > > > +#define KVM_REG_ARM_FW_BMAP KVM_REG_ARM_FW_REG(0xff00)
> > > >
> > > > What is the motivation for moving the bitmap register indices so far
> > > > away from the rest of the firmware regs?
> > > >
> > > The original motivation to create a sub-space came from Reiji's
> > > comment on v3 [1] so that user-space can distinguish between bitmapped
> > > and regular fw registers.
> > > As with the spacing, I thought a 50/50 split would do a good job of
> > > avoiding collisions. Do you have any recommendations here?
> > >
> >
> > I see. This is for the sake of ABI stability with future expansion,
> > right? A new register could be added in the future that controls more
> > SMCCC features, and we expect userspace to zero them if it cares about
> > ABI stability.
> >
> > If that is all true, we probably need some strong supporting
> > documentation. Additionally, using a new COPROC value for the register
> > range might be better than partitioning the existing FW reg range.
> >
> I assumed the 50/50 split could be fine even for future expansion, but
> I can go for a new COPROC value. However, wouldn't the same problem
> exist even with that? We could never have enough space :)
Of course, but I think the UAPI is consistent if you use a new COPROC
value for the bitmaps. That way, you can add documentation that covers
the entire COPROC value you've selected, and doesn't require any further
twiddling with an existing register range. It seems that we have plenty
of COPROC values that are available as well.
> > > > > +#define KVM_REG_ARM_FW_BMAP_REG(r) (KVM_REG_ARM_FW_BMAP | (r))
> > > >
> > > > If you are still going to use the index offset, just pass 'r' through to
> > > > the other macro:
> > > >
> > > > #define KVM_REG_ARM_FW_BMAP_REG(r) KVM_REG_ARM_FW_REG(0xff00 + r)
> > > >
> > > I'm sorry, what's the advantage of doing this?
> > >
Just a style nit :)
--
Thanks,
Oliver
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 05/13] KVM: arm64: Setup a framework for hypercall bitmap firmware registers
@ 2022-03-15 17:35 ` Oliver Upton
0 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-15 17:35 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Tue, Mar 15, 2022 at 09:59:35AM -0700, Raghavendra Rao Ananta wrote:
> On Tue, Mar 15, 2022 at 12:25 AM Oliver Upton <oupton@google.com> wrote:
> >
> > On Mon, Mar 14, 2022 at 05:22:31PM -0700, Raghavendra Rao Ananta wrote:
> > > Hi Oliver,
> > >
> > > On Mon, Mar 14, 2022 at 12:41 PM Oliver Upton <oupton@google.com> wrote:
> > > >
> > > > On Thu, Feb 24, 2022 at 05:25:51PM +0000, Raghavendra Rao Ananta wrote:
> > > > > KVM regularly introduces new hypercall services to the guests without
> > > > > any consent from the userspace. This means, the guests can observe
> > > > > hypercall services in and out as they migrate across various host
> > > > > kernel versions. This could be a major problem if the guest
> > > > > discovered a hypercall, started using it, and after getting migrated
> > > > > to an older kernel realizes that it's no longer available. Depending
> > > > > on how the guest handles the change, there's a potential chance that
> > > > > the guest would just panic.
> > > > >
> > > > > As a result, there's a need for the userspace to elect the services
> > > > > that it wishes the guest to discover. It can elect these services
> > > > > based on the kernels spread across its (migration) fleet. To remedy
> > > > > this, extend the existing firmware psuedo-registers, such as
> > > > > KVM_REG_ARM_PSCI_VERSION, for all the hypercall services available.
> > > > >
> > > > > These firmware registers are categorized based on the service call
> > > > > owners, and unlike the existing firmware psuedo-registers, they hold
> > > > > the features supported in the form of a bitmap.
> > > > >
> > > > > During the VM initialization, the registers holds an upper-limit of
> > > > > the features supported by the corresponding registers. It's expected
> > > > > that the VMMs discover the features provided by each register via
> > > > > GET_ONE_REG, and writeback the desired values using SET_ONE_REG.
> > > > > KVM allows this modification only until the VM has started.
> > > > >
> > > > > Older userspace code can simply ignore the capability and the
> > > > > hypercall services will be exposed unconditionally to the guests, thus
> > > > > ensuring backward compatibility.
> > > > >
> > > > > In this patch, the framework adds the register only for ARM's standard
> > > > > secure services (owner value 4). Currently, this includes support only
> > > > > for ARM True Random Number Generator (TRNG) service, with bit-0 of the
> > > > > register representing mandatory features of v1.0. The register is also
> > > > > added to the kvm_arm_vm_scope_fw_regs[] list as it maintains its state
> > > > > per-VM. Other services are momentarily added in the upcoming patches.
> > > > >
> > > > > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > > > > ---
> > > > > arch/arm64/include/asm/kvm_host.h | 12 +++++
> > > > > arch/arm64/include/uapi/asm/kvm.h | 8 ++++
> > > > > arch/arm64/kvm/arm.c | 8 ++++
> > > > > arch/arm64/kvm/guest.c | 1 +
> > > > > arch/arm64/kvm/hypercalls.c | 78 +++++++++++++++++++++++++++++++
> > > > > include/kvm/arm_hypercalls.h | 4 ++
> > > > > 6 files changed, 111 insertions(+)
> > > > >
> > > > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > > > > index e823571e50cc..1909ced3208f 100644
> > > > > --- a/arch/arm64/include/asm/kvm_host.h
> > > > > +++ b/arch/arm64/include/asm/kvm_host.h
> > > > > @@ -101,6 +101,15 @@ struct kvm_s2_mmu {
> > > > > struct kvm_arch_memory_slot {
> > > > > };
> > > > >
> > > > > +/**
> > > > > + * struct kvm_hvc_desc: KVM ARM64 hypercall descriptor
> > > > > + *
> > > > > + * @hvc_std_bmap: Bitmap of standard secure service calls
> > > > > + */
> > > > > +struct kvm_hvc_desc {
> > > >
> > > > nit: maybe call this structure kvm_hypercall_features? When nested comes
> > > > along guests will need to use the SVC conduit as HVC traps are always
> > > > taken to EL2. Same will need to be true for virtual EL2.
> > > >
> > > Sure, I can rename it to be more generic.
> > >
> > > > > + u64 hvc_std_bmap;
> > > > > +};
> > > > > +
> > > > > struct kvm_arch {
> > > > > struct kvm_s2_mmu mmu;
> > > > >
> > > > > @@ -142,6 +151,9 @@ struct kvm_arch {
> > > > >
> > > > > /* Capture first run of the VM */
> > > > > bool has_run_once;
> > > > > +
> > > > > + /* Hypercall firmware register' descriptor */
> > > > > + struct kvm_hvc_desc hvc_desc;
> > > > > };
> > > > >
> > > > > struct kvm_vcpu_fault_info {
> > > > > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > > > > index c35447cc0e0c..2decc30d6b84 100644
> > > > > --- a/arch/arm64/include/uapi/asm/kvm.h
> > > > > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > > > > @@ -287,6 +287,14 @@ struct kvm_arm_copy_mte_tags {
> > > > > #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED 3
> > > > > #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED (1U << 4)
> > > > >
> > > > > +/* Bitmap firmware registers, extension to the existing psuedo-register space */
> > > > > +#define KVM_REG_ARM_FW_BMAP KVM_REG_ARM_FW_REG(0xff00)
> > > >
> > > > What is the motivation for moving the bitmap register indices so far
> > > > away from the rest of the firmware regs?
> > > >
> > > The original motivation to create a sub-space came from Reiji's
> > > comment on v3 [1] so that user-space can distinguish between bitmapped
> > > and regular fw registers.
> > > As with the spacing, I thought a 50/50 split would do a good job of
> > > avoiding collisions. Do you have any recommendations here?
> > >
> >
> > I see. This is for the sake of ABI stability with future expansion,
> > right? A new register could be added in the future that controls more
> > SMCCC features, and we expect userspace to zero them if it cares about
> > ABI stability.
> >
> > If that is all true, we probably need some strong supporting
> > documentation. Additionally, using a new COPROC value for the register
> > range might be better than partitioning the existing FW reg range.
> >
> I assumed the 50/50 split could be fine even for future expansion, but
> I can go for a new COPROC value. However, wouldn't the same problem
> exist even with that? We could never have enough space :)
Of course, but I think the UAPI is consistent if you use a new COPROC
value for the bitmaps. That way, you can add documentation that covers
the entire COPROC value you've selected, and doesn't require any further
twiddling with an existing register range. It seems that we have plenty
of COPROC values that are available as well.
> > > > > +#define KVM_REG_ARM_FW_BMAP_REG(r) (KVM_REG_ARM_FW_BMAP | (r))
> > > >
> > > > If you are still going to use the index offset, just pass 'r' through to
> > > > the other macro:
> > > >
> > > > #define KVM_REG_ARM_FW_BMAP_REG(r) KVM_REG_ARM_FW_REG(0xff00 + r)
> > > >
> > > I'm sorry, what's the advantage of doing this?
> > >
Just a style nit :)
--
Thanks,
Oliver
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 05/13] KVM: arm64: Setup a framework for hypercall bitmap firmware registers
@ 2022-03-15 17:35 ` Oliver Upton
0 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-15 17:35 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Tue, Mar 15, 2022 at 09:59:35AM -0700, Raghavendra Rao Ananta wrote:
> On Tue, Mar 15, 2022 at 12:25 AM Oliver Upton <oupton@google.com> wrote:
> >
> > On Mon, Mar 14, 2022 at 05:22:31PM -0700, Raghavendra Rao Ananta wrote:
> > > Hi Oliver,
> > >
> > > On Mon, Mar 14, 2022 at 12:41 PM Oliver Upton <oupton@google.com> wrote:
> > > >
> > > > On Thu, Feb 24, 2022 at 05:25:51PM +0000, Raghavendra Rao Ananta wrote:
> > > > > KVM regularly introduces new hypercall services to the guests without
> > > > > any consent from the userspace. This means, the guests can observe
> > > > > hypercall services in and out as they migrate across various host
> > > > > kernel versions. This could be a major problem if the guest
> > > > > discovered a hypercall, started using it, and after getting migrated
> > > > > to an older kernel realizes that it's no longer available. Depending
> > > > > on how the guest handles the change, there's a potential chance that
> > > > > the guest would just panic.
> > > > >
> > > > > As a result, there's a need for the userspace to elect the services
> > > > > that it wishes the guest to discover. It can elect these services
> > > > > based on the kernels spread across its (migration) fleet. To remedy
> > > > > this, extend the existing firmware psuedo-registers, such as
> > > > > KVM_REG_ARM_PSCI_VERSION, for all the hypercall services available.
> > > > >
> > > > > These firmware registers are categorized based on the service call
> > > > > owners, and unlike the existing firmware psuedo-registers, they hold
> > > > > the features supported in the form of a bitmap.
> > > > >
> > > > > During the VM initialization, the registers holds an upper-limit of
> > > > > the features supported by the corresponding registers. It's expected
> > > > > that the VMMs discover the features provided by each register via
> > > > > GET_ONE_REG, and writeback the desired values using SET_ONE_REG.
> > > > > KVM allows this modification only until the VM has started.
> > > > >
> > > > > Older userspace code can simply ignore the capability and the
> > > > > hypercall services will be exposed unconditionally to the guests, thus
> > > > > ensuring backward compatibility.
> > > > >
> > > > > In this patch, the framework adds the register only for ARM's standard
> > > > > secure services (owner value 4). Currently, this includes support only
> > > > > for ARM True Random Number Generator (TRNG) service, with bit-0 of the
> > > > > register representing mandatory features of v1.0. The register is also
> > > > > added to the kvm_arm_vm_scope_fw_regs[] list as it maintains its state
> > > > > per-VM. Other services are momentarily added in the upcoming patches.
> > > > >
> > > > > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > > > > ---
> > > > > arch/arm64/include/asm/kvm_host.h | 12 +++++
> > > > > arch/arm64/include/uapi/asm/kvm.h | 8 ++++
> > > > > arch/arm64/kvm/arm.c | 8 ++++
> > > > > arch/arm64/kvm/guest.c | 1 +
> > > > > arch/arm64/kvm/hypercalls.c | 78 +++++++++++++++++++++++++++++++
> > > > > include/kvm/arm_hypercalls.h | 4 ++
> > > > > 6 files changed, 111 insertions(+)
> > > > >
> > > > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > > > > index e823571e50cc..1909ced3208f 100644
> > > > > --- a/arch/arm64/include/asm/kvm_host.h
> > > > > +++ b/arch/arm64/include/asm/kvm_host.h
> > > > > @@ -101,6 +101,15 @@ struct kvm_s2_mmu {
> > > > > struct kvm_arch_memory_slot {
> > > > > };
> > > > >
> > > > > +/**
> > > > > + * struct kvm_hvc_desc: KVM ARM64 hypercall descriptor
> > > > > + *
> > > > > + * @hvc_std_bmap: Bitmap of standard secure service calls
> > > > > + */
> > > > > +struct kvm_hvc_desc {
> > > >
> > > > nit: maybe call this structure kvm_hypercall_features? When nested comes
> > > > along guests will need to use the SVC conduit as HVC traps are always
> > > > taken to EL2. Same will need to be true for virtual EL2.
> > > >
> > > Sure, I can rename it to be more generic.
> > >
> > > > > + u64 hvc_std_bmap;
> > > > > +};
> > > > > +
> > > > > struct kvm_arch {
> > > > > struct kvm_s2_mmu mmu;
> > > > >
> > > > > @@ -142,6 +151,9 @@ struct kvm_arch {
> > > > >
> > > > > /* Capture first run of the VM */
> > > > > bool has_run_once;
> > > > > +
> > > > > + /* Hypercall firmware register' descriptor */
> > > > > + struct kvm_hvc_desc hvc_desc;
> > > > > };
> > > > >
> > > > > struct kvm_vcpu_fault_info {
> > > > > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > > > > index c35447cc0e0c..2decc30d6b84 100644
> > > > > --- a/arch/arm64/include/uapi/asm/kvm.h
> > > > > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > > > > @@ -287,6 +287,14 @@ struct kvm_arm_copy_mte_tags {
> > > > > #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED 3
> > > > > #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED (1U << 4)
> > > > >
> > > > > +/* Bitmap firmware registers, extension to the existing psuedo-register space */
> > > > > +#define KVM_REG_ARM_FW_BMAP KVM_REG_ARM_FW_REG(0xff00)
> > > >
> > > > What is the motivation for moving the bitmap register indices so far
> > > > away from the rest of the firmware regs?
> > > >
> > > The original motivation to create a sub-space came from Reiji's
> > > comment on v3 [1] so that user-space can distinguish between bitmapped
> > > and regular fw registers.
> > > As with the spacing, I thought a 50/50 split would do a good job of
> > > avoiding collisions. Do you have any recommendations here?
> > >
> >
> > I see. This is for the sake of ABI stability with future expansion,
> > right? A new register could be added in the future that controls more
> > SMCCC features, and we expect userspace to zero them if it cares about
> > ABI stability.
> >
> > If that is all true, we probably need some strong supporting
> > documentation. Additionally, using a new COPROC value for the register
> > range might be better than partitioning the existing FW reg range.
> >
> I assumed the 50/50 split could be fine even for future expansion, but
> I can go for a new COPROC value. However, wouldn't the same problem
> exist even with that? We could never have enough space :)
Of course, but I think the UAPI is consistent if you use a new COPROC
value for the bitmaps. That way, you can add documentation that covers
the entire COPROC value you've selected, and doesn't require any further
twiddling with an existing register range. It seems that we have plenty
of COPROC values that are available as well.
> > > > > +#define KVM_REG_ARM_FW_BMAP_REG(r) (KVM_REG_ARM_FW_BMAP | (r))
> > > >
> > > > If you are still going to use the index offset, just pass 'r' through to
> > > > the other macro:
> > > >
> > > > #define KVM_REG_ARM_FW_BMAP_REG(r) KVM_REG_ARM_FW_REG(0xff00 + r)
> > > >
> > > I'm sorry, what's the advantage of doing this?
> > >
Just a style nit :)
--
Thanks,
Oliver
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 117+ messages in thread
* [PATCH v4 06/13] KVM: arm64: Add standard hypervisor firmware register
2022-02-24 17:25 ` Raghavendra Rao Ananta
(?)
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
-1 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: kvm, Catalin Marinas, Peter Shier, linux-kernel, Paolo Bonzini,
Will Deacon, kvmarm, linux-arm-kernel
Introduce the firmware register to hold the standard hypervisor
service calls (owner value 5) as a bitmap. The bitmap represents
the features that'll be enabled for the guest, as configured by
the user-space. Currently, this includes support only for
Paravirtualized time, represented by bit-0.
The register is also added to the kvm_arm_vm_scope_fw_regs[] list
as it maintains its state per-VM.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
arch/arm64/include/asm/kvm_host.h | 2 ++
arch/arm64/include/uapi/asm/kvm.h | 4 ++++
arch/arm64/kvm/guest.c | 1 +
arch/arm64/kvm/hypercalls.c | 20 +++++++++++++++++++-
include/kvm/arm_hypercalls.h | 3 +++
5 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 1909ced3208f..318148b69279 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -105,9 +105,11 @@ struct kvm_arch_memory_slot {
* struct kvm_hvc_desc: KVM ARM64 hypercall descriptor
*
* @hvc_std_bmap: Bitmap of standard secure service calls
+ * @hvc_std_hyp_bmap: Bitmap of standard hypervisor service calls
*/
struct kvm_hvc_desc {
u64 hvc_std_bmap;
+ u64 hvc_std_hyp_bmap;
};
struct kvm_arch {
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 2decc30d6b84..9a2caead7359 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -295,6 +295,10 @@ struct kvm_arm_copy_mte_tags {
#define KVM_REG_ARM_STD_BIT_TRNG_V1_0 BIT(0)
#define KVM_REG_ARM_STD_BMAP_BIT_MAX 0 /* Last valid bit */
+#define KVM_REG_ARM_STD_HYP_BMAP KVM_REG_ARM_FW_BMAP_REG(1)
+#define KVM_REG_ARM_STD_HYP_BIT_PV_TIME BIT(0)
+#define KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
+
/* SVE registers */
#define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index d66e6c742bbe..c42426d6137e 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -66,6 +66,7 @@ static const u64 kvm_arm_vm_scope_fw_regs[] = {
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
KVM_REG_ARM_STD_BMAP,
+ KVM_REG_ARM_STD_HYP_BMAP,
};
/**
diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
index 48c126c3da72..ebc0cc26cf2e 100644
--- a/arch/arm64/kvm/hypercalls.c
+++ b/arch/arm64/kvm/hypercalls.c
@@ -75,6 +75,10 @@ static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
case ARM_SMCCC_TRNG_RND64:
return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_bmap,
KVM_REG_ARM_STD_BIT_TRNG_V1_0);
+ case ARM_SMCCC_HV_PV_TIME_FEATURES:
+ case ARM_SMCCC_HV_PV_TIME_ST:
+ return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_hyp_bmap,
+ KVM_REG_ARM_STD_HYP_BIT_PV_TIME);
default:
/* By default, allow the services that aren't listed here */
return true;
@@ -83,6 +87,7 @@ static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
{
+ struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
u32 func_id = smccc_get_function(vcpu);
u64 val[4] = {SMCCC_RET_NOT_SUPPORTED};
u32 feature;
@@ -134,7 +139,10 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
}
break;
case ARM_SMCCC_HV_PV_TIME_FEATURES:
- val[0] = SMCCC_RET_SUCCESS;
+ if (kvm_arm_fw_reg_feat_enabled(
+ hvc_desc->hvc_std_hyp_bmap,
+ KVM_REG_ARM_STD_HYP_BIT_PV_TIME))
+ val[0] = SMCCC_RET_SUCCESS;
break;
}
break;
@@ -179,6 +187,7 @@ static const u64 kvm_arm_fw_reg_ids[] = {
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
KVM_REG_ARM_STD_BMAP,
+ KVM_REG_ARM_STD_HYP_BMAP,
};
void kvm_arm_init_hypercalls(struct kvm *kvm)
@@ -186,6 +195,7 @@ void kvm_arm_init_hypercalls(struct kvm *kvm)
struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
+ hvc_desc->hvc_std_hyp_bmap = ARM_SMCCC_STD_HYP_FEATURES;
}
int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
@@ -272,6 +282,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
case KVM_REG_ARM_STD_BMAP:
val = READ_ONCE(hvc_desc->hvc_std_bmap);
break;
+ case KVM_REG_ARM_STD_HYP_BMAP:
+ val = READ_ONCE(hvc_desc->hvc_std_hyp_bmap);
+ break;
default:
return -ENOENT;
}
@@ -294,6 +307,10 @@ static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
fw_reg_bmap = &hvc_desc->hvc_std_bmap;
fw_reg_features = ARM_SMCCC_STD_FEATURES;
break;
+ case KVM_REG_ARM_STD_HYP_BMAP:
+ fw_reg_bmap = &hvc_desc->hvc_std_hyp_bmap;
+ fw_reg_features = ARM_SMCCC_STD_HYP_FEATURES;
+ break;
default:
return -ENOENT;
}
@@ -398,6 +415,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
return 0;
case KVM_REG_ARM_STD_BMAP:
+ case KVM_REG_ARM_STD_HYP_BMAP:
return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
default:
return -ENOENT;
diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
index 64d30b452809..a1cb6e839c74 100644
--- a/include/kvm/arm_hypercalls.h
+++ b/include/kvm/arm_hypercalls.h
@@ -9,6 +9,9 @@
#define ARM_SMCCC_STD_FEATURES \
GENMASK_ULL(KVM_REG_ARM_STD_BMAP_BIT_MAX, 0)
+#define ARM_SMCCC_STD_HYP_FEATURES \
+ GENMASK_ULL(KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX, 0)
+
int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
--
2.35.1.473.g83b2b277ed-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 117+ messages in thread* [PATCH v4 06/13] KVM: arm64: Add standard hypervisor firmware register
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: Paolo Bonzini, Catalin Marinas, Will Deacon, Peter Shier,
Ricardo Koller, Oliver Upton, Reiji Watanabe, Jing Zhang,
Raghavendra Rao Anata, linux-arm-kernel, kvmarm, linux-kernel,
kvm
Introduce the firmware register to hold the standard hypervisor
service calls (owner value 5) as a bitmap. The bitmap represents
the features that'll be enabled for the guest, as configured by
the user-space. Currently, this includes support only for
Paravirtualized time, represented by bit-0.
The register is also added to the kvm_arm_vm_scope_fw_regs[] list
as it maintains its state per-VM.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
arch/arm64/include/asm/kvm_host.h | 2 ++
arch/arm64/include/uapi/asm/kvm.h | 4 ++++
arch/arm64/kvm/guest.c | 1 +
arch/arm64/kvm/hypercalls.c | 20 +++++++++++++++++++-
include/kvm/arm_hypercalls.h | 3 +++
5 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 1909ced3208f..318148b69279 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -105,9 +105,11 @@ struct kvm_arch_memory_slot {
* struct kvm_hvc_desc: KVM ARM64 hypercall descriptor
*
* @hvc_std_bmap: Bitmap of standard secure service calls
+ * @hvc_std_hyp_bmap: Bitmap of standard hypervisor service calls
*/
struct kvm_hvc_desc {
u64 hvc_std_bmap;
+ u64 hvc_std_hyp_bmap;
};
struct kvm_arch {
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 2decc30d6b84..9a2caead7359 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -295,6 +295,10 @@ struct kvm_arm_copy_mte_tags {
#define KVM_REG_ARM_STD_BIT_TRNG_V1_0 BIT(0)
#define KVM_REG_ARM_STD_BMAP_BIT_MAX 0 /* Last valid bit */
+#define KVM_REG_ARM_STD_HYP_BMAP KVM_REG_ARM_FW_BMAP_REG(1)
+#define KVM_REG_ARM_STD_HYP_BIT_PV_TIME BIT(0)
+#define KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
+
/* SVE registers */
#define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index d66e6c742bbe..c42426d6137e 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -66,6 +66,7 @@ static const u64 kvm_arm_vm_scope_fw_regs[] = {
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
KVM_REG_ARM_STD_BMAP,
+ KVM_REG_ARM_STD_HYP_BMAP,
};
/**
diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
index 48c126c3da72..ebc0cc26cf2e 100644
--- a/arch/arm64/kvm/hypercalls.c
+++ b/arch/arm64/kvm/hypercalls.c
@@ -75,6 +75,10 @@ static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
case ARM_SMCCC_TRNG_RND64:
return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_bmap,
KVM_REG_ARM_STD_BIT_TRNG_V1_0);
+ case ARM_SMCCC_HV_PV_TIME_FEATURES:
+ case ARM_SMCCC_HV_PV_TIME_ST:
+ return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_hyp_bmap,
+ KVM_REG_ARM_STD_HYP_BIT_PV_TIME);
default:
/* By default, allow the services that aren't listed here */
return true;
@@ -83,6 +87,7 @@ static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
{
+ struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
u32 func_id = smccc_get_function(vcpu);
u64 val[4] = {SMCCC_RET_NOT_SUPPORTED};
u32 feature;
@@ -134,7 +139,10 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
}
break;
case ARM_SMCCC_HV_PV_TIME_FEATURES:
- val[0] = SMCCC_RET_SUCCESS;
+ if (kvm_arm_fw_reg_feat_enabled(
+ hvc_desc->hvc_std_hyp_bmap,
+ KVM_REG_ARM_STD_HYP_BIT_PV_TIME))
+ val[0] = SMCCC_RET_SUCCESS;
break;
}
break;
@@ -179,6 +187,7 @@ static const u64 kvm_arm_fw_reg_ids[] = {
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
KVM_REG_ARM_STD_BMAP,
+ KVM_REG_ARM_STD_HYP_BMAP,
};
void kvm_arm_init_hypercalls(struct kvm *kvm)
@@ -186,6 +195,7 @@ void kvm_arm_init_hypercalls(struct kvm *kvm)
struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
+ hvc_desc->hvc_std_hyp_bmap = ARM_SMCCC_STD_HYP_FEATURES;
}
int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
@@ -272,6 +282,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
case KVM_REG_ARM_STD_BMAP:
val = READ_ONCE(hvc_desc->hvc_std_bmap);
break;
+ case KVM_REG_ARM_STD_HYP_BMAP:
+ val = READ_ONCE(hvc_desc->hvc_std_hyp_bmap);
+ break;
default:
return -ENOENT;
}
@@ -294,6 +307,10 @@ static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
fw_reg_bmap = &hvc_desc->hvc_std_bmap;
fw_reg_features = ARM_SMCCC_STD_FEATURES;
break;
+ case KVM_REG_ARM_STD_HYP_BMAP:
+ fw_reg_bmap = &hvc_desc->hvc_std_hyp_bmap;
+ fw_reg_features = ARM_SMCCC_STD_HYP_FEATURES;
+ break;
default:
return -ENOENT;
}
@@ -398,6 +415,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
return 0;
case KVM_REG_ARM_STD_BMAP:
+ case KVM_REG_ARM_STD_HYP_BMAP:
return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
default:
return -ENOENT;
diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
index 64d30b452809..a1cb6e839c74 100644
--- a/include/kvm/arm_hypercalls.h
+++ b/include/kvm/arm_hypercalls.h
@@ -9,6 +9,9 @@
#define ARM_SMCCC_STD_FEATURES \
GENMASK_ULL(KVM_REG_ARM_STD_BMAP_BIT_MAX, 0)
+#define ARM_SMCCC_STD_HYP_FEATURES \
+ GENMASK_ULL(KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX, 0)
+
int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
--
2.35.1.473.g83b2b277ed-goog
^ permalink raw reply related [flat|nested] 117+ messages in thread* [PATCH v4 06/13] KVM: arm64: Add standard hypervisor firmware register
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: Paolo Bonzini, Catalin Marinas, Will Deacon, Peter Shier,
Ricardo Koller, Oliver Upton, Reiji Watanabe, Jing Zhang,
Raghavendra Rao Anata, linux-arm-kernel, kvmarm, linux-kernel,
kvm
Introduce the firmware register to hold the standard hypervisor
service calls (owner value 5) as a bitmap. The bitmap represents
the features that'll be enabled for the guest, as configured by
the user-space. Currently, this includes support only for
Paravirtualized time, represented by bit-0.
The register is also added to the kvm_arm_vm_scope_fw_regs[] list
as it maintains its state per-VM.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
arch/arm64/include/asm/kvm_host.h | 2 ++
arch/arm64/include/uapi/asm/kvm.h | 4 ++++
arch/arm64/kvm/guest.c | 1 +
arch/arm64/kvm/hypercalls.c | 20 +++++++++++++++++++-
include/kvm/arm_hypercalls.h | 3 +++
5 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 1909ced3208f..318148b69279 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -105,9 +105,11 @@ struct kvm_arch_memory_slot {
* struct kvm_hvc_desc: KVM ARM64 hypercall descriptor
*
* @hvc_std_bmap: Bitmap of standard secure service calls
+ * @hvc_std_hyp_bmap: Bitmap of standard hypervisor service calls
*/
struct kvm_hvc_desc {
u64 hvc_std_bmap;
+ u64 hvc_std_hyp_bmap;
};
struct kvm_arch {
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 2decc30d6b84..9a2caead7359 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -295,6 +295,10 @@ struct kvm_arm_copy_mte_tags {
#define KVM_REG_ARM_STD_BIT_TRNG_V1_0 BIT(0)
#define KVM_REG_ARM_STD_BMAP_BIT_MAX 0 /* Last valid bit */
+#define KVM_REG_ARM_STD_HYP_BMAP KVM_REG_ARM_FW_BMAP_REG(1)
+#define KVM_REG_ARM_STD_HYP_BIT_PV_TIME BIT(0)
+#define KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
+
/* SVE registers */
#define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index d66e6c742bbe..c42426d6137e 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -66,6 +66,7 @@ static const u64 kvm_arm_vm_scope_fw_regs[] = {
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
KVM_REG_ARM_STD_BMAP,
+ KVM_REG_ARM_STD_HYP_BMAP,
};
/**
diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
index 48c126c3da72..ebc0cc26cf2e 100644
--- a/arch/arm64/kvm/hypercalls.c
+++ b/arch/arm64/kvm/hypercalls.c
@@ -75,6 +75,10 @@ static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
case ARM_SMCCC_TRNG_RND64:
return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_bmap,
KVM_REG_ARM_STD_BIT_TRNG_V1_0);
+ case ARM_SMCCC_HV_PV_TIME_FEATURES:
+ case ARM_SMCCC_HV_PV_TIME_ST:
+ return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_hyp_bmap,
+ KVM_REG_ARM_STD_HYP_BIT_PV_TIME);
default:
/* By default, allow the services that aren't listed here */
return true;
@@ -83,6 +87,7 @@ static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
{
+ struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
u32 func_id = smccc_get_function(vcpu);
u64 val[4] = {SMCCC_RET_NOT_SUPPORTED};
u32 feature;
@@ -134,7 +139,10 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
}
break;
case ARM_SMCCC_HV_PV_TIME_FEATURES:
- val[0] = SMCCC_RET_SUCCESS;
+ if (kvm_arm_fw_reg_feat_enabled(
+ hvc_desc->hvc_std_hyp_bmap,
+ KVM_REG_ARM_STD_HYP_BIT_PV_TIME))
+ val[0] = SMCCC_RET_SUCCESS;
break;
}
break;
@@ -179,6 +187,7 @@ static const u64 kvm_arm_fw_reg_ids[] = {
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
KVM_REG_ARM_STD_BMAP,
+ KVM_REG_ARM_STD_HYP_BMAP,
};
void kvm_arm_init_hypercalls(struct kvm *kvm)
@@ -186,6 +195,7 @@ void kvm_arm_init_hypercalls(struct kvm *kvm)
struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
+ hvc_desc->hvc_std_hyp_bmap = ARM_SMCCC_STD_HYP_FEATURES;
}
int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
@@ -272,6 +282,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
case KVM_REG_ARM_STD_BMAP:
val = READ_ONCE(hvc_desc->hvc_std_bmap);
break;
+ case KVM_REG_ARM_STD_HYP_BMAP:
+ val = READ_ONCE(hvc_desc->hvc_std_hyp_bmap);
+ break;
default:
return -ENOENT;
}
@@ -294,6 +307,10 @@ static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
fw_reg_bmap = &hvc_desc->hvc_std_bmap;
fw_reg_features = ARM_SMCCC_STD_FEATURES;
break;
+ case KVM_REG_ARM_STD_HYP_BMAP:
+ fw_reg_bmap = &hvc_desc->hvc_std_hyp_bmap;
+ fw_reg_features = ARM_SMCCC_STD_HYP_FEATURES;
+ break;
default:
return -ENOENT;
}
@@ -398,6 +415,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
return 0;
case KVM_REG_ARM_STD_BMAP:
+ case KVM_REG_ARM_STD_HYP_BMAP:
return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
default:
return -ENOENT;
diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
index 64d30b452809..a1cb6e839c74 100644
--- a/include/kvm/arm_hypercalls.h
+++ b/include/kvm/arm_hypercalls.h
@@ -9,6 +9,9 @@
#define ARM_SMCCC_STD_FEATURES \
GENMASK_ULL(KVM_REG_ARM_STD_BMAP_BIT_MAX, 0)
+#define ARM_SMCCC_STD_HYP_FEATURES \
+ GENMASK_ULL(KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX, 0)
+
int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
--
2.35.1.473.g83b2b277ed-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 117+ messages in thread* Re: [PATCH v4 06/13] KVM: arm64: Add standard hypervisor firmware register
2022-02-24 17:25 ` Raghavendra Rao Ananta
(?)
@ 2022-03-14 19:45 ` Oliver Upton
-1 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-14 19:45 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: kvm, Will Deacon, Marc Zyngier, Peter Shier, linux-kernel,
Catalin Marinas, Paolo Bonzini, kvmarm, linux-arm-kernel
On Thu, Feb 24, 2022 at 05:25:52PM +0000, Raghavendra Rao Ananta wrote:
> Introduce the firmware register to hold the standard hypervisor
> service calls (owner value 5) as a bitmap. The bitmap represents
> the features that'll be enabled for the guest, as configured by
> the user-space. Currently, this includes support only for
> Paravirtualized time, represented by bit-0.
>
> The register is also added to the kvm_arm_vm_scope_fw_regs[] list
> as it maintains its state per-VM.
>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> ---
> arch/arm64/include/asm/kvm_host.h | 2 ++
> arch/arm64/include/uapi/asm/kvm.h | 4 ++++
> arch/arm64/kvm/guest.c | 1 +
> arch/arm64/kvm/hypercalls.c | 20 +++++++++++++++++++-
> include/kvm/arm_hypercalls.h | 3 +++
> 5 files changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 1909ced3208f..318148b69279 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -105,9 +105,11 @@ struct kvm_arch_memory_slot {
> * struct kvm_hvc_desc: KVM ARM64 hypercall descriptor
> *
> * @hvc_std_bmap: Bitmap of standard secure service calls
> + * @hvc_std_hyp_bmap: Bitmap of standard hypervisor service calls
> */
> struct kvm_hvc_desc {
> u64 hvc_std_bmap;
> + u64 hvc_std_hyp_bmap;
> };
>
> struct kvm_arch {
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index 2decc30d6b84..9a2caead7359 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -295,6 +295,10 @@ struct kvm_arm_copy_mte_tags {
> #define KVM_REG_ARM_STD_BIT_TRNG_V1_0 BIT(0)
> #define KVM_REG_ARM_STD_BMAP_BIT_MAX 0 /* Last valid bit */
>
> +#define KVM_REG_ARM_STD_HYP_BMAP KVM_REG_ARM_FW_BMAP_REG(1)
> +#define KVM_REG_ARM_STD_HYP_BIT_PV_TIME BIT(0)
> +#define KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
> +
> /* SVE registers */
> #define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
>
> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> index d66e6c742bbe..c42426d6137e 100644
> --- a/arch/arm64/kvm/guest.c
> +++ b/arch/arm64/kvm/guest.c
> @@ -66,6 +66,7 @@ static const u64 kvm_arm_vm_scope_fw_regs[] = {
> KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> KVM_REG_ARM_STD_BMAP,
> + KVM_REG_ARM_STD_HYP_BMAP,
> };
>
> /**
> diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> index 48c126c3da72..ebc0cc26cf2e 100644
> --- a/arch/arm64/kvm/hypercalls.c
> +++ b/arch/arm64/kvm/hypercalls.c
> @@ -75,6 +75,10 @@ static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> case ARM_SMCCC_TRNG_RND64:
> return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_bmap,
> KVM_REG_ARM_STD_BIT_TRNG_V1_0);
> + case ARM_SMCCC_HV_PV_TIME_FEATURES:
> + case ARM_SMCCC_HV_PV_TIME_ST:
> + return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_hyp_bmap,
> + KVM_REG_ARM_STD_HYP_BIT_PV_TIME);
> default:
> /* By default, allow the services that aren't listed here */
> return true;
> @@ -83,6 +87,7 @@ static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
>
> int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> {
> + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> u32 func_id = smccc_get_function(vcpu);
> u64 val[4] = {SMCCC_RET_NOT_SUPPORTED};
> u32 feature;
> @@ -134,7 +139,10 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> }
> break;
> case ARM_SMCCC_HV_PV_TIME_FEATURES:
> - val[0] = SMCCC_RET_SUCCESS;
> + if (kvm_arm_fw_reg_feat_enabled(
> + hvc_desc->hvc_std_hyp_bmap,
It is probably OK to keep this parameter on the line above (just stay
under 100 characters a line).
> + KVM_REG_ARM_STD_HYP_BIT_PV_TIME))
> + val[0] = SMCCC_RET_SUCCESS;
> break;
> }
> break;
> @@ -179,6 +187,7 @@ static const u64 kvm_arm_fw_reg_ids[] = {
> KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> KVM_REG_ARM_STD_BMAP,
> + KVM_REG_ARM_STD_HYP_BMAP,
> };
>
> void kvm_arm_init_hypercalls(struct kvm *kvm)
> @@ -186,6 +195,7 @@ void kvm_arm_init_hypercalls(struct kvm *kvm)
> struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
>
> hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
> + hvc_desc->hvc_std_hyp_bmap = ARM_SMCCC_STD_HYP_FEATURES;
> }
>
> int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> @@ -272,6 +282,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> case KVM_REG_ARM_STD_BMAP:
> val = READ_ONCE(hvc_desc->hvc_std_bmap);
> break;
> + case KVM_REG_ARM_STD_HYP_BMAP:
> + val = READ_ONCE(hvc_desc->hvc_std_hyp_bmap);
> + break;
> default:
> return -ENOENT;
> }
> @@ -294,6 +307,10 @@ static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
> fw_reg_bmap = &hvc_desc->hvc_std_bmap;
> fw_reg_features = ARM_SMCCC_STD_FEATURES;
> break;
> + case KVM_REG_ARM_STD_HYP_BMAP:
> + fw_reg_bmap = &hvc_desc->hvc_std_hyp_bmap;
> + fw_reg_features = ARM_SMCCC_STD_HYP_FEATURES;
> + break;
> default:
> return -ENOENT;
> }
> @@ -398,6 +415,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
>
> return 0;
> case KVM_REG_ARM_STD_BMAP:
> + case KVM_REG_ARM_STD_HYP_BMAP:
> return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
> default:
> return -ENOENT;
> diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> index 64d30b452809..a1cb6e839c74 100644
> --- a/include/kvm/arm_hypercalls.h
> +++ b/include/kvm/arm_hypercalls.h
> @@ -9,6 +9,9 @@
> #define ARM_SMCCC_STD_FEATURES \
> GENMASK_ULL(KVM_REG_ARM_STD_BMAP_BIT_MAX, 0)
>
> +#define ARM_SMCCC_STD_HYP_FEATURES \
> + GENMASK_ULL(KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX, 0)
> +
> int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
>
> static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
> --
> 2.35.1.473.g83b2b277ed-goog
>
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 06/13] KVM: arm64: Add standard hypervisor firmware register
@ 2022-03-14 19:45 ` Oliver Upton
0 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-14 19:45 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Thu, Feb 24, 2022 at 05:25:52PM +0000, Raghavendra Rao Ananta wrote:
> Introduce the firmware register to hold the standard hypervisor
> service calls (owner value 5) as a bitmap. The bitmap represents
> the features that'll be enabled for the guest, as configured by
> the user-space. Currently, this includes support only for
> Paravirtualized time, represented by bit-0.
>
> The register is also added to the kvm_arm_vm_scope_fw_regs[] list
> as it maintains its state per-VM.
>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> ---
> arch/arm64/include/asm/kvm_host.h | 2 ++
> arch/arm64/include/uapi/asm/kvm.h | 4 ++++
> arch/arm64/kvm/guest.c | 1 +
> arch/arm64/kvm/hypercalls.c | 20 +++++++++++++++++++-
> include/kvm/arm_hypercalls.h | 3 +++
> 5 files changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 1909ced3208f..318148b69279 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -105,9 +105,11 @@ struct kvm_arch_memory_slot {
> * struct kvm_hvc_desc: KVM ARM64 hypercall descriptor
> *
> * @hvc_std_bmap: Bitmap of standard secure service calls
> + * @hvc_std_hyp_bmap: Bitmap of standard hypervisor service calls
> */
> struct kvm_hvc_desc {
> u64 hvc_std_bmap;
> + u64 hvc_std_hyp_bmap;
> };
>
> struct kvm_arch {
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index 2decc30d6b84..9a2caead7359 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -295,6 +295,10 @@ struct kvm_arm_copy_mte_tags {
> #define KVM_REG_ARM_STD_BIT_TRNG_V1_0 BIT(0)
> #define KVM_REG_ARM_STD_BMAP_BIT_MAX 0 /* Last valid bit */
>
> +#define KVM_REG_ARM_STD_HYP_BMAP KVM_REG_ARM_FW_BMAP_REG(1)
> +#define KVM_REG_ARM_STD_HYP_BIT_PV_TIME BIT(0)
> +#define KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
> +
> /* SVE registers */
> #define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
>
> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> index d66e6c742bbe..c42426d6137e 100644
> --- a/arch/arm64/kvm/guest.c
> +++ b/arch/arm64/kvm/guest.c
> @@ -66,6 +66,7 @@ static const u64 kvm_arm_vm_scope_fw_regs[] = {
> KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> KVM_REG_ARM_STD_BMAP,
> + KVM_REG_ARM_STD_HYP_BMAP,
> };
>
> /**
> diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> index 48c126c3da72..ebc0cc26cf2e 100644
> --- a/arch/arm64/kvm/hypercalls.c
> +++ b/arch/arm64/kvm/hypercalls.c
> @@ -75,6 +75,10 @@ static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> case ARM_SMCCC_TRNG_RND64:
> return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_bmap,
> KVM_REG_ARM_STD_BIT_TRNG_V1_0);
> + case ARM_SMCCC_HV_PV_TIME_FEATURES:
> + case ARM_SMCCC_HV_PV_TIME_ST:
> + return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_hyp_bmap,
> + KVM_REG_ARM_STD_HYP_BIT_PV_TIME);
> default:
> /* By default, allow the services that aren't listed here */
> return true;
> @@ -83,6 +87,7 @@ static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
>
> int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> {
> + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> u32 func_id = smccc_get_function(vcpu);
> u64 val[4] = {SMCCC_RET_NOT_SUPPORTED};
> u32 feature;
> @@ -134,7 +139,10 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> }
> break;
> case ARM_SMCCC_HV_PV_TIME_FEATURES:
> - val[0] = SMCCC_RET_SUCCESS;
> + if (kvm_arm_fw_reg_feat_enabled(
> + hvc_desc->hvc_std_hyp_bmap,
It is probably OK to keep this parameter on the line above (just stay
under 100 characters a line).
> + KVM_REG_ARM_STD_HYP_BIT_PV_TIME))
> + val[0] = SMCCC_RET_SUCCESS;
> break;
> }
> break;
> @@ -179,6 +187,7 @@ static const u64 kvm_arm_fw_reg_ids[] = {
> KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> KVM_REG_ARM_STD_BMAP,
> + KVM_REG_ARM_STD_HYP_BMAP,
> };
>
> void kvm_arm_init_hypercalls(struct kvm *kvm)
> @@ -186,6 +195,7 @@ void kvm_arm_init_hypercalls(struct kvm *kvm)
> struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
>
> hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
> + hvc_desc->hvc_std_hyp_bmap = ARM_SMCCC_STD_HYP_FEATURES;
> }
>
> int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> @@ -272,6 +282,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> case KVM_REG_ARM_STD_BMAP:
> val = READ_ONCE(hvc_desc->hvc_std_bmap);
> break;
> + case KVM_REG_ARM_STD_HYP_BMAP:
> + val = READ_ONCE(hvc_desc->hvc_std_hyp_bmap);
> + break;
> default:
> return -ENOENT;
> }
> @@ -294,6 +307,10 @@ static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
> fw_reg_bmap = &hvc_desc->hvc_std_bmap;
> fw_reg_features = ARM_SMCCC_STD_FEATURES;
> break;
> + case KVM_REG_ARM_STD_HYP_BMAP:
> + fw_reg_bmap = &hvc_desc->hvc_std_hyp_bmap;
> + fw_reg_features = ARM_SMCCC_STD_HYP_FEATURES;
> + break;
> default:
> return -ENOENT;
> }
> @@ -398,6 +415,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
>
> return 0;
> case KVM_REG_ARM_STD_BMAP:
> + case KVM_REG_ARM_STD_HYP_BMAP:
> return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
> default:
> return -ENOENT;
> diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> index 64d30b452809..a1cb6e839c74 100644
> --- a/include/kvm/arm_hypercalls.h
> +++ b/include/kvm/arm_hypercalls.h
> @@ -9,6 +9,9 @@
> #define ARM_SMCCC_STD_FEATURES \
> GENMASK_ULL(KVM_REG_ARM_STD_BMAP_BIT_MAX, 0)
>
> +#define ARM_SMCCC_STD_HYP_FEATURES \
> + GENMASK_ULL(KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX, 0)
> +
> int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
>
> static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
> --
> 2.35.1.473.g83b2b277ed-goog
>
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 06/13] KVM: arm64: Add standard hypervisor firmware register
@ 2022-03-14 19:45 ` Oliver Upton
0 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-14 19:45 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Thu, Feb 24, 2022 at 05:25:52PM +0000, Raghavendra Rao Ananta wrote:
> Introduce the firmware register to hold the standard hypervisor
> service calls (owner value 5) as a bitmap. The bitmap represents
> the features that'll be enabled for the guest, as configured by
> the user-space. Currently, this includes support only for
> Paravirtualized time, represented by bit-0.
>
> The register is also added to the kvm_arm_vm_scope_fw_regs[] list
> as it maintains its state per-VM.
>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> ---
> arch/arm64/include/asm/kvm_host.h | 2 ++
> arch/arm64/include/uapi/asm/kvm.h | 4 ++++
> arch/arm64/kvm/guest.c | 1 +
> arch/arm64/kvm/hypercalls.c | 20 +++++++++++++++++++-
> include/kvm/arm_hypercalls.h | 3 +++
> 5 files changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 1909ced3208f..318148b69279 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -105,9 +105,11 @@ struct kvm_arch_memory_slot {
> * struct kvm_hvc_desc: KVM ARM64 hypercall descriptor
> *
> * @hvc_std_bmap: Bitmap of standard secure service calls
> + * @hvc_std_hyp_bmap: Bitmap of standard hypervisor service calls
> */
> struct kvm_hvc_desc {
> u64 hvc_std_bmap;
> + u64 hvc_std_hyp_bmap;
> };
>
> struct kvm_arch {
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index 2decc30d6b84..9a2caead7359 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -295,6 +295,10 @@ struct kvm_arm_copy_mte_tags {
> #define KVM_REG_ARM_STD_BIT_TRNG_V1_0 BIT(0)
> #define KVM_REG_ARM_STD_BMAP_BIT_MAX 0 /* Last valid bit */
>
> +#define KVM_REG_ARM_STD_HYP_BMAP KVM_REG_ARM_FW_BMAP_REG(1)
> +#define KVM_REG_ARM_STD_HYP_BIT_PV_TIME BIT(0)
> +#define KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
> +
> /* SVE registers */
> #define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
>
> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> index d66e6c742bbe..c42426d6137e 100644
> --- a/arch/arm64/kvm/guest.c
> +++ b/arch/arm64/kvm/guest.c
> @@ -66,6 +66,7 @@ static const u64 kvm_arm_vm_scope_fw_regs[] = {
> KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> KVM_REG_ARM_STD_BMAP,
> + KVM_REG_ARM_STD_HYP_BMAP,
> };
>
> /**
> diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> index 48c126c3da72..ebc0cc26cf2e 100644
> --- a/arch/arm64/kvm/hypercalls.c
> +++ b/arch/arm64/kvm/hypercalls.c
> @@ -75,6 +75,10 @@ static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> case ARM_SMCCC_TRNG_RND64:
> return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_bmap,
> KVM_REG_ARM_STD_BIT_TRNG_V1_0);
> + case ARM_SMCCC_HV_PV_TIME_FEATURES:
> + case ARM_SMCCC_HV_PV_TIME_ST:
> + return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_hyp_bmap,
> + KVM_REG_ARM_STD_HYP_BIT_PV_TIME);
> default:
> /* By default, allow the services that aren't listed here */
> return true;
> @@ -83,6 +87,7 @@ static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
>
> int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> {
> + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> u32 func_id = smccc_get_function(vcpu);
> u64 val[4] = {SMCCC_RET_NOT_SUPPORTED};
> u32 feature;
> @@ -134,7 +139,10 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> }
> break;
> case ARM_SMCCC_HV_PV_TIME_FEATURES:
> - val[0] = SMCCC_RET_SUCCESS;
> + if (kvm_arm_fw_reg_feat_enabled(
> + hvc_desc->hvc_std_hyp_bmap,
It is probably OK to keep this parameter on the line above (just stay
under 100 characters a line).
> + KVM_REG_ARM_STD_HYP_BIT_PV_TIME))
> + val[0] = SMCCC_RET_SUCCESS;
> break;
> }
> break;
> @@ -179,6 +187,7 @@ static const u64 kvm_arm_fw_reg_ids[] = {
> KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> KVM_REG_ARM_STD_BMAP,
> + KVM_REG_ARM_STD_HYP_BMAP,
> };
>
> void kvm_arm_init_hypercalls(struct kvm *kvm)
> @@ -186,6 +195,7 @@ void kvm_arm_init_hypercalls(struct kvm *kvm)
> struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
>
> hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
> + hvc_desc->hvc_std_hyp_bmap = ARM_SMCCC_STD_HYP_FEATURES;
> }
>
> int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> @@ -272,6 +282,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> case KVM_REG_ARM_STD_BMAP:
> val = READ_ONCE(hvc_desc->hvc_std_bmap);
> break;
> + case KVM_REG_ARM_STD_HYP_BMAP:
> + val = READ_ONCE(hvc_desc->hvc_std_hyp_bmap);
> + break;
> default:
> return -ENOENT;
> }
> @@ -294,6 +307,10 @@ static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
> fw_reg_bmap = &hvc_desc->hvc_std_bmap;
> fw_reg_features = ARM_SMCCC_STD_FEATURES;
> break;
> + case KVM_REG_ARM_STD_HYP_BMAP:
> + fw_reg_bmap = &hvc_desc->hvc_std_hyp_bmap;
> + fw_reg_features = ARM_SMCCC_STD_HYP_FEATURES;
> + break;
> default:
> return -ENOENT;
> }
> @@ -398,6 +415,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
>
> return 0;
> case KVM_REG_ARM_STD_BMAP:
> + case KVM_REG_ARM_STD_HYP_BMAP:
> return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
> default:
> return -ENOENT;
> diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> index 64d30b452809..a1cb6e839c74 100644
> --- a/include/kvm/arm_hypercalls.h
> +++ b/include/kvm/arm_hypercalls.h
> @@ -9,6 +9,9 @@
> #define ARM_SMCCC_STD_FEATURES \
> GENMASK_ULL(KVM_REG_ARM_STD_BMAP_BIT_MAX, 0)
>
> +#define ARM_SMCCC_STD_HYP_FEATURES \
> + GENMASK_ULL(KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX, 0)
> +
> int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
>
> static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
> --
> 2.35.1.473.g83b2b277ed-goog
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 06/13] KVM: arm64: Add standard hypervisor firmware register
2022-03-14 19:45 ` Oliver Upton
(?)
@ 2022-03-15 0:23 ` Raghavendra Rao Ananta
-1 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-03-15 0:23 UTC (permalink / raw)
To: Oliver Upton
Cc: kvm, Will Deacon, Marc Zyngier, Peter Shier, linux-kernel,
Catalin Marinas, Paolo Bonzini, kvmarm, linux-arm-kernel
On Mon, Mar 14, 2022 at 12:45 PM Oliver Upton <oupton@google.com> wrote:
>
> On Thu, Feb 24, 2022 at 05:25:52PM +0000, Raghavendra Rao Ananta wrote:
> > Introduce the firmware register to hold the standard hypervisor
> > service calls (owner value 5) as a bitmap. The bitmap represents
> > the features that'll be enabled for the guest, as configured by
> > the user-space. Currently, this includes support only for
> > Paravirtualized time, represented by bit-0.
> >
> > The register is also added to the kvm_arm_vm_scope_fw_regs[] list
> > as it maintains its state per-VM.
> >
> > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > ---
> > arch/arm64/include/asm/kvm_host.h | 2 ++
> > arch/arm64/include/uapi/asm/kvm.h | 4 ++++
> > arch/arm64/kvm/guest.c | 1 +
> > arch/arm64/kvm/hypercalls.c | 20 +++++++++++++++++++-
> > include/kvm/arm_hypercalls.h | 3 +++
> > 5 files changed, 29 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > index 1909ced3208f..318148b69279 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -105,9 +105,11 @@ struct kvm_arch_memory_slot {
> > * struct kvm_hvc_desc: KVM ARM64 hypercall descriptor
> > *
> > * @hvc_std_bmap: Bitmap of standard secure service calls
> > + * @hvc_std_hyp_bmap: Bitmap of standard hypervisor service calls
> > */
> > struct kvm_hvc_desc {
> > u64 hvc_std_bmap;
> > + u64 hvc_std_hyp_bmap;
> > };
> >
> > struct kvm_arch {
> > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > index 2decc30d6b84..9a2caead7359 100644
> > --- a/arch/arm64/include/uapi/asm/kvm.h
> > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > @@ -295,6 +295,10 @@ struct kvm_arm_copy_mte_tags {
> > #define KVM_REG_ARM_STD_BIT_TRNG_V1_0 BIT(0)
> > #define KVM_REG_ARM_STD_BMAP_BIT_MAX 0 /* Last valid bit */
> >
> > +#define KVM_REG_ARM_STD_HYP_BMAP KVM_REG_ARM_FW_BMAP_REG(1)
> > +#define KVM_REG_ARM_STD_HYP_BIT_PV_TIME BIT(0)
> > +#define KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
> > +
> > /* SVE registers */
> > #define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
> >
> > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> > index d66e6c742bbe..c42426d6137e 100644
> > --- a/arch/arm64/kvm/guest.c
> > +++ b/arch/arm64/kvm/guest.c
> > @@ -66,6 +66,7 @@ static const u64 kvm_arm_vm_scope_fw_regs[] = {
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > KVM_REG_ARM_STD_BMAP,
> > + KVM_REG_ARM_STD_HYP_BMAP,
> > };
> >
> > /**
> > diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> > index 48c126c3da72..ebc0cc26cf2e 100644
> > --- a/arch/arm64/kvm/hypercalls.c
> > +++ b/arch/arm64/kvm/hypercalls.c
> > @@ -75,6 +75,10 @@ static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> > case ARM_SMCCC_TRNG_RND64:
> > return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_bmap,
> > KVM_REG_ARM_STD_BIT_TRNG_V1_0);
> > + case ARM_SMCCC_HV_PV_TIME_FEATURES:
> > + case ARM_SMCCC_HV_PV_TIME_ST:
> > + return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_hyp_bmap,
> > + KVM_REG_ARM_STD_HYP_BIT_PV_TIME);
> > default:
> > /* By default, allow the services that aren't listed here */
> > return true;
> > @@ -83,6 +87,7 @@ static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> >
> > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > {
> > + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> > u32 func_id = smccc_get_function(vcpu);
> > u64 val[4] = {SMCCC_RET_NOT_SUPPORTED};
> > u32 feature;
> > @@ -134,7 +139,10 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > }
> > break;
> > case ARM_SMCCC_HV_PV_TIME_FEATURES:
> > - val[0] = SMCCC_RET_SUCCESS;
> > + if (kvm_arm_fw_reg_feat_enabled(
> > + hvc_desc->hvc_std_hyp_bmap,
>
> It is probably OK to keep this parameter on the line above (just stay
> under 100 characters a line).
>
Will rearrange this in the next series. Thanks.
Regards,
Raghavendra
> > + KVM_REG_ARM_STD_HYP_BIT_PV_TIME))
> > + val[0] = SMCCC_RET_SUCCESS;
> > break;
> > }
> > break;
> > @@ -179,6 +187,7 @@ static const u64 kvm_arm_fw_reg_ids[] = {
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > KVM_REG_ARM_STD_BMAP,
> > + KVM_REG_ARM_STD_HYP_BMAP,
> > };
> >
> > void kvm_arm_init_hypercalls(struct kvm *kvm)
> > @@ -186,6 +195,7 @@ void kvm_arm_init_hypercalls(struct kvm *kvm)
> > struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
> >
> > hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
> > + hvc_desc->hvc_std_hyp_bmap = ARM_SMCCC_STD_HYP_FEATURES;
> > }
> >
> > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> > @@ -272,6 +282,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > case KVM_REG_ARM_STD_BMAP:
> > val = READ_ONCE(hvc_desc->hvc_std_bmap);
> > break;
> > + case KVM_REG_ARM_STD_HYP_BMAP:
> > + val = READ_ONCE(hvc_desc->hvc_std_hyp_bmap);
> > + break;
> > default:
> > return -ENOENT;
> > }
> > @@ -294,6 +307,10 @@ static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
> > fw_reg_bmap = &hvc_desc->hvc_std_bmap;
> > fw_reg_features = ARM_SMCCC_STD_FEATURES;
> > break;
> > + case KVM_REG_ARM_STD_HYP_BMAP:
> > + fw_reg_bmap = &hvc_desc->hvc_std_hyp_bmap;
> > + fw_reg_features = ARM_SMCCC_STD_HYP_FEATURES;
> > + break;
> > default:
> > return -ENOENT;
> > }
> > @@ -398,6 +415,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> >
> > return 0;
> > case KVM_REG_ARM_STD_BMAP:
> > + case KVM_REG_ARM_STD_HYP_BMAP:
> > return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
> > default:
> > return -ENOENT;
> > diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> > index 64d30b452809..a1cb6e839c74 100644
> > --- a/include/kvm/arm_hypercalls.h
> > +++ b/include/kvm/arm_hypercalls.h
> > @@ -9,6 +9,9 @@
> > #define ARM_SMCCC_STD_FEATURES \
> > GENMASK_ULL(KVM_REG_ARM_STD_BMAP_BIT_MAX, 0)
> >
> > +#define ARM_SMCCC_STD_HYP_FEATURES \
> > + GENMASK_ULL(KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX, 0)
> > +
> > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
> >
> > static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
> > --
> > 2.35.1.473.g83b2b277ed-goog
> >
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 06/13] KVM: arm64: Add standard hypervisor firmware register
@ 2022-03-15 0:23 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-03-15 0:23 UTC (permalink / raw)
To: Oliver Upton
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Mon, Mar 14, 2022 at 12:45 PM Oliver Upton <oupton@google.com> wrote:
>
> On Thu, Feb 24, 2022 at 05:25:52PM +0000, Raghavendra Rao Ananta wrote:
> > Introduce the firmware register to hold the standard hypervisor
> > service calls (owner value 5) as a bitmap. The bitmap represents
> > the features that'll be enabled for the guest, as configured by
> > the user-space. Currently, this includes support only for
> > Paravirtualized time, represented by bit-0.
> >
> > The register is also added to the kvm_arm_vm_scope_fw_regs[] list
> > as it maintains its state per-VM.
> >
> > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > ---
> > arch/arm64/include/asm/kvm_host.h | 2 ++
> > arch/arm64/include/uapi/asm/kvm.h | 4 ++++
> > arch/arm64/kvm/guest.c | 1 +
> > arch/arm64/kvm/hypercalls.c | 20 +++++++++++++++++++-
> > include/kvm/arm_hypercalls.h | 3 +++
> > 5 files changed, 29 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > index 1909ced3208f..318148b69279 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -105,9 +105,11 @@ struct kvm_arch_memory_slot {
> > * struct kvm_hvc_desc: KVM ARM64 hypercall descriptor
> > *
> > * @hvc_std_bmap: Bitmap of standard secure service calls
> > + * @hvc_std_hyp_bmap: Bitmap of standard hypervisor service calls
> > */
> > struct kvm_hvc_desc {
> > u64 hvc_std_bmap;
> > + u64 hvc_std_hyp_bmap;
> > };
> >
> > struct kvm_arch {
> > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > index 2decc30d6b84..9a2caead7359 100644
> > --- a/arch/arm64/include/uapi/asm/kvm.h
> > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > @@ -295,6 +295,10 @@ struct kvm_arm_copy_mte_tags {
> > #define KVM_REG_ARM_STD_BIT_TRNG_V1_0 BIT(0)
> > #define KVM_REG_ARM_STD_BMAP_BIT_MAX 0 /* Last valid bit */
> >
> > +#define KVM_REG_ARM_STD_HYP_BMAP KVM_REG_ARM_FW_BMAP_REG(1)
> > +#define KVM_REG_ARM_STD_HYP_BIT_PV_TIME BIT(0)
> > +#define KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
> > +
> > /* SVE registers */
> > #define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
> >
> > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> > index d66e6c742bbe..c42426d6137e 100644
> > --- a/arch/arm64/kvm/guest.c
> > +++ b/arch/arm64/kvm/guest.c
> > @@ -66,6 +66,7 @@ static const u64 kvm_arm_vm_scope_fw_regs[] = {
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > KVM_REG_ARM_STD_BMAP,
> > + KVM_REG_ARM_STD_HYP_BMAP,
> > };
> >
> > /**
> > diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> > index 48c126c3da72..ebc0cc26cf2e 100644
> > --- a/arch/arm64/kvm/hypercalls.c
> > +++ b/arch/arm64/kvm/hypercalls.c
> > @@ -75,6 +75,10 @@ static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> > case ARM_SMCCC_TRNG_RND64:
> > return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_bmap,
> > KVM_REG_ARM_STD_BIT_TRNG_V1_0);
> > + case ARM_SMCCC_HV_PV_TIME_FEATURES:
> > + case ARM_SMCCC_HV_PV_TIME_ST:
> > + return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_hyp_bmap,
> > + KVM_REG_ARM_STD_HYP_BIT_PV_TIME);
> > default:
> > /* By default, allow the services that aren't listed here */
> > return true;
> > @@ -83,6 +87,7 @@ static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> >
> > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > {
> > + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> > u32 func_id = smccc_get_function(vcpu);
> > u64 val[4] = {SMCCC_RET_NOT_SUPPORTED};
> > u32 feature;
> > @@ -134,7 +139,10 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > }
> > break;
> > case ARM_SMCCC_HV_PV_TIME_FEATURES:
> > - val[0] = SMCCC_RET_SUCCESS;
> > + if (kvm_arm_fw_reg_feat_enabled(
> > + hvc_desc->hvc_std_hyp_bmap,
>
> It is probably OK to keep this parameter on the line above (just stay
> under 100 characters a line).
>
Will rearrange this in the next series. Thanks.
Regards,
Raghavendra
> > + KVM_REG_ARM_STD_HYP_BIT_PV_TIME))
> > + val[0] = SMCCC_RET_SUCCESS;
> > break;
> > }
> > break;
> > @@ -179,6 +187,7 @@ static const u64 kvm_arm_fw_reg_ids[] = {
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > KVM_REG_ARM_STD_BMAP,
> > + KVM_REG_ARM_STD_HYP_BMAP,
> > };
> >
> > void kvm_arm_init_hypercalls(struct kvm *kvm)
> > @@ -186,6 +195,7 @@ void kvm_arm_init_hypercalls(struct kvm *kvm)
> > struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
> >
> > hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
> > + hvc_desc->hvc_std_hyp_bmap = ARM_SMCCC_STD_HYP_FEATURES;
> > }
> >
> > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> > @@ -272,6 +282,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > case KVM_REG_ARM_STD_BMAP:
> > val = READ_ONCE(hvc_desc->hvc_std_bmap);
> > break;
> > + case KVM_REG_ARM_STD_HYP_BMAP:
> > + val = READ_ONCE(hvc_desc->hvc_std_hyp_bmap);
> > + break;
> > default:
> > return -ENOENT;
> > }
> > @@ -294,6 +307,10 @@ static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
> > fw_reg_bmap = &hvc_desc->hvc_std_bmap;
> > fw_reg_features = ARM_SMCCC_STD_FEATURES;
> > break;
> > + case KVM_REG_ARM_STD_HYP_BMAP:
> > + fw_reg_bmap = &hvc_desc->hvc_std_hyp_bmap;
> > + fw_reg_features = ARM_SMCCC_STD_HYP_FEATURES;
> > + break;
> > default:
> > return -ENOENT;
> > }
> > @@ -398,6 +415,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> >
> > return 0;
> > case KVM_REG_ARM_STD_BMAP:
> > + case KVM_REG_ARM_STD_HYP_BMAP:
> > return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
> > default:
> > return -ENOENT;
> > diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> > index 64d30b452809..a1cb6e839c74 100644
> > --- a/include/kvm/arm_hypercalls.h
> > +++ b/include/kvm/arm_hypercalls.h
> > @@ -9,6 +9,9 @@
> > #define ARM_SMCCC_STD_FEATURES \
> > GENMASK_ULL(KVM_REG_ARM_STD_BMAP_BIT_MAX, 0)
> >
> > +#define ARM_SMCCC_STD_HYP_FEATURES \
> > + GENMASK_ULL(KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX, 0)
> > +
> > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
> >
> > static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
> > --
> > 2.35.1.473.g83b2b277ed-goog
> >
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 06/13] KVM: arm64: Add standard hypervisor firmware register
@ 2022-03-15 0:23 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-03-15 0:23 UTC (permalink / raw)
To: Oliver Upton
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Mon, Mar 14, 2022 at 12:45 PM Oliver Upton <oupton@google.com> wrote:
>
> On Thu, Feb 24, 2022 at 05:25:52PM +0000, Raghavendra Rao Ananta wrote:
> > Introduce the firmware register to hold the standard hypervisor
> > service calls (owner value 5) as a bitmap. The bitmap represents
> > the features that'll be enabled for the guest, as configured by
> > the user-space. Currently, this includes support only for
> > Paravirtualized time, represented by bit-0.
> >
> > The register is also added to the kvm_arm_vm_scope_fw_regs[] list
> > as it maintains its state per-VM.
> >
> > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > ---
> > arch/arm64/include/asm/kvm_host.h | 2 ++
> > arch/arm64/include/uapi/asm/kvm.h | 4 ++++
> > arch/arm64/kvm/guest.c | 1 +
> > arch/arm64/kvm/hypercalls.c | 20 +++++++++++++++++++-
> > include/kvm/arm_hypercalls.h | 3 +++
> > 5 files changed, 29 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > index 1909ced3208f..318148b69279 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -105,9 +105,11 @@ struct kvm_arch_memory_slot {
> > * struct kvm_hvc_desc: KVM ARM64 hypercall descriptor
> > *
> > * @hvc_std_bmap: Bitmap of standard secure service calls
> > + * @hvc_std_hyp_bmap: Bitmap of standard hypervisor service calls
> > */
> > struct kvm_hvc_desc {
> > u64 hvc_std_bmap;
> > + u64 hvc_std_hyp_bmap;
> > };
> >
> > struct kvm_arch {
> > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > index 2decc30d6b84..9a2caead7359 100644
> > --- a/arch/arm64/include/uapi/asm/kvm.h
> > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > @@ -295,6 +295,10 @@ struct kvm_arm_copy_mte_tags {
> > #define KVM_REG_ARM_STD_BIT_TRNG_V1_0 BIT(0)
> > #define KVM_REG_ARM_STD_BMAP_BIT_MAX 0 /* Last valid bit */
> >
> > +#define KVM_REG_ARM_STD_HYP_BMAP KVM_REG_ARM_FW_BMAP_REG(1)
> > +#define KVM_REG_ARM_STD_HYP_BIT_PV_TIME BIT(0)
> > +#define KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
> > +
> > /* SVE registers */
> > #define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
> >
> > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> > index d66e6c742bbe..c42426d6137e 100644
> > --- a/arch/arm64/kvm/guest.c
> > +++ b/arch/arm64/kvm/guest.c
> > @@ -66,6 +66,7 @@ static const u64 kvm_arm_vm_scope_fw_regs[] = {
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > KVM_REG_ARM_STD_BMAP,
> > + KVM_REG_ARM_STD_HYP_BMAP,
> > };
> >
> > /**
> > diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> > index 48c126c3da72..ebc0cc26cf2e 100644
> > --- a/arch/arm64/kvm/hypercalls.c
> > +++ b/arch/arm64/kvm/hypercalls.c
> > @@ -75,6 +75,10 @@ static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> > case ARM_SMCCC_TRNG_RND64:
> > return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_bmap,
> > KVM_REG_ARM_STD_BIT_TRNG_V1_0);
> > + case ARM_SMCCC_HV_PV_TIME_FEATURES:
> > + case ARM_SMCCC_HV_PV_TIME_ST:
> > + return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_hyp_bmap,
> > + KVM_REG_ARM_STD_HYP_BIT_PV_TIME);
> > default:
> > /* By default, allow the services that aren't listed here */
> > return true;
> > @@ -83,6 +87,7 @@ static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> >
> > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > {
> > + struct kvm_hvc_desc *hvc_desc = &vcpu->kvm->arch.hvc_desc;
> > u32 func_id = smccc_get_function(vcpu);
> > u64 val[4] = {SMCCC_RET_NOT_SUPPORTED};
> > u32 feature;
> > @@ -134,7 +139,10 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > }
> > break;
> > case ARM_SMCCC_HV_PV_TIME_FEATURES:
> > - val[0] = SMCCC_RET_SUCCESS;
> > + if (kvm_arm_fw_reg_feat_enabled(
> > + hvc_desc->hvc_std_hyp_bmap,
>
> It is probably OK to keep this parameter on the line above (just stay
> under 100 characters a line).
>
Will rearrange this in the next series. Thanks.
Regards,
Raghavendra
> > + KVM_REG_ARM_STD_HYP_BIT_PV_TIME))
> > + val[0] = SMCCC_RET_SUCCESS;
> > break;
> > }
> > break;
> > @@ -179,6 +187,7 @@ static const u64 kvm_arm_fw_reg_ids[] = {
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > KVM_REG_ARM_STD_BMAP,
> > + KVM_REG_ARM_STD_HYP_BMAP,
> > };
> >
> > void kvm_arm_init_hypercalls(struct kvm *kvm)
> > @@ -186,6 +195,7 @@ void kvm_arm_init_hypercalls(struct kvm *kvm)
> > struct kvm_hvc_desc *hvc_desc = &kvm->arch.hvc_desc;
> >
> > hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
> > + hvc_desc->hvc_std_hyp_bmap = ARM_SMCCC_STD_HYP_FEATURES;
> > }
> >
> > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> > @@ -272,6 +282,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > case KVM_REG_ARM_STD_BMAP:
> > val = READ_ONCE(hvc_desc->hvc_std_bmap);
> > break;
> > + case KVM_REG_ARM_STD_HYP_BMAP:
> > + val = READ_ONCE(hvc_desc->hvc_std_hyp_bmap);
> > + break;
> > default:
> > return -ENOENT;
> > }
> > @@ -294,6 +307,10 @@ static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
> > fw_reg_bmap = &hvc_desc->hvc_std_bmap;
> > fw_reg_features = ARM_SMCCC_STD_FEATURES;
> > break;
> > + case KVM_REG_ARM_STD_HYP_BMAP:
> > + fw_reg_bmap = &hvc_desc->hvc_std_hyp_bmap;
> > + fw_reg_features = ARM_SMCCC_STD_HYP_FEATURES;
> > + break;
> > default:
> > return -ENOENT;
> > }
> > @@ -398,6 +415,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> >
> > return 0;
> > case KVM_REG_ARM_STD_BMAP:
> > + case KVM_REG_ARM_STD_HYP_BMAP:
> > return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
> > default:
> > return -ENOENT;
> > diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> > index 64d30b452809..a1cb6e839c74 100644
> > --- a/include/kvm/arm_hypercalls.h
> > +++ b/include/kvm/arm_hypercalls.h
> > @@ -9,6 +9,9 @@
> > #define ARM_SMCCC_STD_FEATURES \
> > GENMASK_ULL(KVM_REG_ARM_STD_BMAP_BIT_MAX, 0)
> >
> > +#define ARM_SMCCC_STD_HYP_FEATURES \
> > + GENMASK_ULL(KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX, 0)
> > +
> > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
> >
> > static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
> > --
> > 2.35.1.473.g83b2b277ed-goog
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 117+ messages in thread
* [PATCH v4 07/13] KVM: arm64: Add vendor hypervisor firmware register
2022-02-24 17:25 ` Raghavendra Rao Ananta
(?)
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
-1 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: kvm, Catalin Marinas, Peter Shier, linux-kernel, Paolo Bonzini,
Will Deacon, kvmarm, linux-arm-kernel
Introduce the firmware register to hold the vendor specific
hypervisor service calls (owner value 6) as a bitmap. The
bitmap represents the features that'll be enabled for the
guest, as configured by the user-space. Currently, this
includes support only for Precision Time Protocol (PTP),
represented by bit-0.
The register is also added to the kvm_arm_vm_scope_fw_regs[]
list as it maintains its state per-VM.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
arch/arm64/include/asm/kvm_host.h | 2 ++
arch/arm64/include/uapi/asm/kvm.h | 4 ++++
arch/arm64/kvm/guest.c | 1 +
arch/arm64/kvm/hypercalls.c | 22 +++++++++++++++++++++-
include/kvm/arm_hypercalls.h | 3 +++
5 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 318148b69279..d999456c4604 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -106,10 +106,12 @@ struct kvm_arch_memory_slot {
*
* @hvc_std_bmap: Bitmap of standard secure service calls
* @hvc_std_hyp_bmap: Bitmap of standard hypervisor service calls
+ * @hvc_vendor_hyp_bmap: Bitmap of vendor specific hypervisor service calls
*/
struct kvm_hvc_desc {
u64 hvc_std_bmap;
u64 hvc_std_hyp_bmap;
+ u64 hvc_vendor_hyp_bmap;
};
struct kvm_arch {
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 9a2caead7359..ed470bde13d8 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -299,6 +299,10 @@ struct kvm_arm_copy_mte_tags {
#define KVM_REG_ARM_STD_HYP_BIT_PV_TIME BIT(0)
#define KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
+#define KVM_REG_ARM_VENDOR_HYP_BMAP KVM_REG_ARM_FW_BMAP_REG(2)
+#define KVM_REG_ARM_VENDOR_HYP_BIT_PTP BIT(0)
+#define KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
+
/* SVE registers */
#define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index c42426d6137e..fc3656f91aed 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -67,6 +67,7 @@ static const u64 kvm_arm_vm_scope_fw_regs[] = {
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
KVM_REG_ARM_STD_BMAP,
KVM_REG_ARM_STD_HYP_BMAP,
+ KVM_REG_ARM_VENDOR_HYP_BMAP,
};
/**
diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
index ebc0cc26cf2e..5c5098c8f1f9 100644
--- a/arch/arm64/kvm/hypercalls.c
+++ b/arch/arm64/kvm/hypercalls.c
@@ -79,6 +79,9 @@ static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
case ARM_SMCCC_HV_PV_TIME_ST:
return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_hyp_bmap,
KVM_REG_ARM_STD_HYP_BIT_PV_TIME);
+ case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
+ return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_vendor_hyp_bmap,
+ KVM_REG_ARM_VENDOR_HYP_BIT_PTP);
default:
/* By default, allow the services that aren't listed here */
return true;
@@ -162,7 +165,14 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
break;
case ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID:
val[0] = BIT(ARM_SMCCC_KVM_FUNC_FEATURES);
- val[0] |= BIT(ARM_SMCCC_KVM_FUNC_PTP);
+
+ /*
+ * The feature bits exposed to user-space doesn't include
+ * ARM_SMCCC_KVM_FUNC_FEATURES. However, we expose this to
+ * the guest as bit-0. Hence, left-shift the user-space
+ * exposed bitmap by 1 to accommodate this.
+ */
+ val[0] |= hvc_desc->hvc_vendor_hyp_bmap << 1;
break;
case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
kvm_ptp_get_time(vcpu, val);
@@ -188,6 +198,7 @@ static const u64 kvm_arm_fw_reg_ids[] = {
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
KVM_REG_ARM_STD_BMAP,
KVM_REG_ARM_STD_HYP_BMAP,
+ KVM_REG_ARM_VENDOR_HYP_BMAP,
};
void kvm_arm_init_hypercalls(struct kvm *kvm)
@@ -196,6 +207,7 @@ void kvm_arm_init_hypercalls(struct kvm *kvm)
hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
hvc_desc->hvc_std_hyp_bmap = ARM_SMCCC_STD_HYP_FEATURES;
+ hvc_desc->hvc_vendor_hyp_bmap = ARM_SMCCC_VENDOR_HYP_FEATURES;
}
int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
@@ -285,6 +297,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
case KVM_REG_ARM_STD_HYP_BMAP:
val = READ_ONCE(hvc_desc->hvc_std_hyp_bmap);
break;
+ case KVM_REG_ARM_VENDOR_HYP_BMAP:
+ val = READ_ONCE(hvc_desc->hvc_vendor_hyp_bmap);
+ break;
default:
return -ENOENT;
}
@@ -311,6 +326,10 @@ static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
fw_reg_bmap = &hvc_desc->hvc_std_hyp_bmap;
fw_reg_features = ARM_SMCCC_STD_HYP_FEATURES;
break;
+ case KVM_REG_ARM_VENDOR_HYP_BMAP:
+ fw_reg_bmap = &hvc_desc->hvc_vendor_hyp_bmap;
+ fw_reg_features = ARM_SMCCC_VENDOR_HYP_FEATURES;
+ break;
default:
return -ENOENT;
}
@@ -416,6 +435,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
return 0;
case KVM_REG_ARM_STD_BMAP:
case KVM_REG_ARM_STD_HYP_BMAP:
+ case KVM_REG_ARM_VENDOR_HYP_BMAP:
return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
default:
return -ENOENT;
diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
index a1cb6e839c74..91be758ca58e 100644
--- a/include/kvm/arm_hypercalls.h
+++ b/include/kvm/arm_hypercalls.h
@@ -12,6 +12,9 @@
#define ARM_SMCCC_STD_HYP_FEATURES \
GENMASK_ULL(KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX, 0)
+#define ARM_SMCCC_VENDOR_HYP_FEATURES \
+ GENMASK_ULL(KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX, 0)
+
int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
--
2.35.1.473.g83b2b277ed-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 117+ messages in thread* [PATCH v4 07/13] KVM: arm64: Add vendor hypervisor firmware register
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: Paolo Bonzini, Catalin Marinas, Will Deacon, Peter Shier,
Ricardo Koller, Oliver Upton, Reiji Watanabe, Jing Zhang,
Raghavendra Rao Anata, linux-arm-kernel, kvmarm, linux-kernel,
kvm
Introduce the firmware register to hold the vendor specific
hypervisor service calls (owner value 6) as a bitmap. The
bitmap represents the features that'll be enabled for the
guest, as configured by the user-space. Currently, this
includes support only for Precision Time Protocol (PTP),
represented by bit-0.
The register is also added to the kvm_arm_vm_scope_fw_regs[]
list as it maintains its state per-VM.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
arch/arm64/include/asm/kvm_host.h | 2 ++
arch/arm64/include/uapi/asm/kvm.h | 4 ++++
arch/arm64/kvm/guest.c | 1 +
arch/arm64/kvm/hypercalls.c | 22 +++++++++++++++++++++-
include/kvm/arm_hypercalls.h | 3 +++
5 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 318148b69279..d999456c4604 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -106,10 +106,12 @@ struct kvm_arch_memory_slot {
*
* @hvc_std_bmap: Bitmap of standard secure service calls
* @hvc_std_hyp_bmap: Bitmap of standard hypervisor service calls
+ * @hvc_vendor_hyp_bmap: Bitmap of vendor specific hypervisor service calls
*/
struct kvm_hvc_desc {
u64 hvc_std_bmap;
u64 hvc_std_hyp_bmap;
+ u64 hvc_vendor_hyp_bmap;
};
struct kvm_arch {
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 9a2caead7359..ed470bde13d8 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -299,6 +299,10 @@ struct kvm_arm_copy_mte_tags {
#define KVM_REG_ARM_STD_HYP_BIT_PV_TIME BIT(0)
#define KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
+#define KVM_REG_ARM_VENDOR_HYP_BMAP KVM_REG_ARM_FW_BMAP_REG(2)
+#define KVM_REG_ARM_VENDOR_HYP_BIT_PTP BIT(0)
+#define KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
+
/* SVE registers */
#define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index c42426d6137e..fc3656f91aed 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -67,6 +67,7 @@ static const u64 kvm_arm_vm_scope_fw_regs[] = {
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
KVM_REG_ARM_STD_BMAP,
KVM_REG_ARM_STD_HYP_BMAP,
+ KVM_REG_ARM_VENDOR_HYP_BMAP,
};
/**
diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
index ebc0cc26cf2e..5c5098c8f1f9 100644
--- a/arch/arm64/kvm/hypercalls.c
+++ b/arch/arm64/kvm/hypercalls.c
@@ -79,6 +79,9 @@ static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
case ARM_SMCCC_HV_PV_TIME_ST:
return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_hyp_bmap,
KVM_REG_ARM_STD_HYP_BIT_PV_TIME);
+ case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
+ return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_vendor_hyp_bmap,
+ KVM_REG_ARM_VENDOR_HYP_BIT_PTP);
default:
/* By default, allow the services that aren't listed here */
return true;
@@ -162,7 +165,14 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
break;
case ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID:
val[0] = BIT(ARM_SMCCC_KVM_FUNC_FEATURES);
- val[0] |= BIT(ARM_SMCCC_KVM_FUNC_PTP);
+
+ /*
+ * The feature bits exposed to user-space doesn't include
+ * ARM_SMCCC_KVM_FUNC_FEATURES. However, we expose this to
+ * the guest as bit-0. Hence, left-shift the user-space
+ * exposed bitmap by 1 to accommodate this.
+ */
+ val[0] |= hvc_desc->hvc_vendor_hyp_bmap << 1;
break;
case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
kvm_ptp_get_time(vcpu, val);
@@ -188,6 +198,7 @@ static const u64 kvm_arm_fw_reg_ids[] = {
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
KVM_REG_ARM_STD_BMAP,
KVM_REG_ARM_STD_HYP_BMAP,
+ KVM_REG_ARM_VENDOR_HYP_BMAP,
};
void kvm_arm_init_hypercalls(struct kvm *kvm)
@@ -196,6 +207,7 @@ void kvm_arm_init_hypercalls(struct kvm *kvm)
hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
hvc_desc->hvc_std_hyp_bmap = ARM_SMCCC_STD_HYP_FEATURES;
+ hvc_desc->hvc_vendor_hyp_bmap = ARM_SMCCC_VENDOR_HYP_FEATURES;
}
int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
@@ -285,6 +297,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
case KVM_REG_ARM_STD_HYP_BMAP:
val = READ_ONCE(hvc_desc->hvc_std_hyp_bmap);
break;
+ case KVM_REG_ARM_VENDOR_HYP_BMAP:
+ val = READ_ONCE(hvc_desc->hvc_vendor_hyp_bmap);
+ break;
default:
return -ENOENT;
}
@@ -311,6 +326,10 @@ static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
fw_reg_bmap = &hvc_desc->hvc_std_hyp_bmap;
fw_reg_features = ARM_SMCCC_STD_HYP_FEATURES;
break;
+ case KVM_REG_ARM_VENDOR_HYP_BMAP:
+ fw_reg_bmap = &hvc_desc->hvc_vendor_hyp_bmap;
+ fw_reg_features = ARM_SMCCC_VENDOR_HYP_FEATURES;
+ break;
default:
return -ENOENT;
}
@@ -416,6 +435,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
return 0;
case KVM_REG_ARM_STD_BMAP:
case KVM_REG_ARM_STD_HYP_BMAP:
+ case KVM_REG_ARM_VENDOR_HYP_BMAP:
return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
default:
return -ENOENT;
diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
index a1cb6e839c74..91be758ca58e 100644
--- a/include/kvm/arm_hypercalls.h
+++ b/include/kvm/arm_hypercalls.h
@@ -12,6 +12,9 @@
#define ARM_SMCCC_STD_HYP_FEATURES \
GENMASK_ULL(KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX, 0)
+#define ARM_SMCCC_VENDOR_HYP_FEATURES \
+ GENMASK_ULL(KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX, 0)
+
int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
--
2.35.1.473.g83b2b277ed-goog
^ permalink raw reply related [flat|nested] 117+ messages in thread* [PATCH v4 07/13] KVM: arm64: Add vendor hypervisor firmware register
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: Paolo Bonzini, Catalin Marinas, Will Deacon, Peter Shier,
Ricardo Koller, Oliver Upton, Reiji Watanabe, Jing Zhang,
Raghavendra Rao Anata, linux-arm-kernel, kvmarm, linux-kernel,
kvm
Introduce the firmware register to hold the vendor specific
hypervisor service calls (owner value 6) as a bitmap. The
bitmap represents the features that'll be enabled for the
guest, as configured by the user-space. Currently, this
includes support only for Precision Time Protocol (PTP),
represented by bit-0.
The register is also added to the kvm_arm_vm_scope_fw_regs[]
list as it maintains its state per-VM.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
arch/arm64/include/asm/kvm_host.h | 2 ++
arch/arm64/include/uapi/asm/kvm.h | 4 ++++
arch/arm64/kvm/guest.c | 1 +
arch/arm64/kvm/hypercalls.c | 22 +++++++++++++++++++++-
include/kvm/arm_hypercalls.h | 3 +++
5 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 318148b69279..d999456c4604 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -106,10 +106,12 @@ struct kvm_arch_memory_slot {
*
* @hvc_std_bmap: Bitmap of standard secure service calls
* @hvc_std_hyp_bmap: Bitmap of standard hypervisor service calls
+ * @hvc_vendor_hyp_bmap: Bitmap of vendor specific hypervisor service calls
*/
struct kvm_hvc_desc {
u64 hvc_std_bmap;
u64 hvc_std_hyp_bmap;
+ u64 hvc_vendor_hyp_bmap;
};
struct kvm_arch {
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 9a2caead7359..ed470bde13d8 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -299,6 +299,10 @@ struct kvm_arm_copy_mte_tags {
#define KVM_REG_ARM_STD_HYP_BIT_PV_TIME BIT(0)
#define KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
+#define KVM_REG_ARM_VENDOR_HYP_BMAP KVM_REG_ARM_FW_BMAP_REG(2)
+#define KVM_REG_ARM_VENDOR_HYP_BIT_PTP BIT(0)
+#define KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
+
/* SVE registers */
#define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index c42426d6137e..fc3656f91aed 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -67,6 +67,7 @@ static const u64 kvm_arm_vm_scope_fw_regs[] = {
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
KVM_REG_ARM_STD_BMAP,
KVM_REG_ARM_STD_HYP_BMAP,
+ KVM_REG_ARM_VENDOR_HYP_BMAP,
};
/**
diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
index ebc0cc26cf2e..5c5098c8f1f9 100644
--- a/arch/arm64/kvm/hypercalls.c
+++ b/arch/arm64/kvm/hypercalls.c
@@ -79,6 +79,9 @@ static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
case ARM_SMCCC_HV_PV_TIME_ST:
return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_hyp_bmap,
KVM_REG_ARM_STD_HYP_BIT_PV_TIME);
+ case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
+ return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_vendor_hyp_bmap,
+ KVM_REG_ARM_VENDOR_HYP_BIT_PTP);
default:
/* By default, allow the services that aren't listed here */
return true;
@@ -162,7 +165,14 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
break;
case ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID:
val[0] = BIT(ARM_SMCCC_KVM_FUNC_FEATURES);
- val[0] |= BIT(ARM_SMCCC_KVM_FUNC_PTP);
+
+ /*
+ * The feature bits exposed to user-space doesn't include
+ * ARM_SMCCC_KVM_FUNC_FEATURES. However, we expose this to
+ * the guest as bit-0. Hence, left-shift the user-space
+ * exposed bitmap by 1 to accommodate this.
+ */
+ val[0] |= hvc_desc->hvc_vendor_hyp_bmap << 1;
break;
case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
kvm_ptp_get_time(vcpu, val);
@@ -188,6 +198,7 @@ static const u64 kvm_arm_fw_reg_ids[] = {
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
KVM_REG_ARM_STD_BMAP,
KVM_REG_ARM_STD_HYP_BMAP,
+ KVM_REG_ARM_VENDOR_HYP_BMAP,
};
void kvm_arm_init_hypercalls(struct kvm *kvm)
@@ -196,6 +207,7 @@ void kvm_arm_init_hypercalls(struct kvm *kvm)
hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
hvc_desc->hvc_std_hyp_bmap = ARM_SMCCC_STD_HYP_FEATURES;
+ hvc_desc->hvc_vendor_hyp_bmap = ARM_SMCCC_VENDOR_HYP_FEATURES;
}
int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
@@ -285,6 +297,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
case KVM_REG_ARM_STD_HYP_BMAP:
val = READ_ONCE(hvc_desc->hvc_std_hyp_bmap);
break;
+ case KVM_REG_ARM_VENDOR_HYP_BMAP:
+ val = READ_ONCE(hvc_desc->hvc_vendor_hyp_bmap);
+ break;
default:
return -ENOENT;
}
@@ -311,6 +326,10 @@ static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
fw_reg_bmap = &hvc_desc->hvc_std_hyp_bmap;
fw_reg_features = ARM_SMCCC_STD_HYP_FEATURES;
break;
+ case KVM_REG_ARM_VENDOR_HYP_BMAP:
+ fw_reg_bmap = &hvc_desc->hvc_vendor_hyp_bmap;
+ fw_reg_features = ARM_SMCCC_VENDOR_HYP_FEATURES;
+ break;
default:
return -ENOENT;
}
@@ -416,6 +435,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
return 0;
case KVM_REG_ARM_STD_BMAP:
case KVM_REG_ARM_STD_HYP_BMAP:
+ case KVM_REG_ARM_VENDOR_HYP_BMAP:
return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
default:
return -ENOENT;
diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
index a1cb6e839c74..91be758ca58e 100644
--- a/include/kvm/arm_hypercalls.h
+++ b/include/kvm/arm_hypercalls.h
@@ -12,6 +12,9 @@
#define ARM_SMCCC_STD_HYP_FEATURES \
GENMASK_ULL(KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX, 0)
+#define ARM_SMCCC_VENDOR_HYP_FEATURES \
+ GENMASK_ULL(KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX, 0)
+
int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
--
2.35.1.473.g83b2b277ed-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 117+ messages in thread* Re: [PATCH v4 07/13] KVM: arm64: Add vendor hypervisor firmware register
2022-02-24 17:25 ` Raghavendra Rao Ananta
(?)
@ 2022-03-14 19:59 ` Oliver Upton
-1 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-14 19:59 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: kvm, Will Deacon, Marc Zyngier, Peter Shier, linux-kernel,
Catalin Marinas, Paolo Bonzini, kvmarm, linux-arm-kernel
On Thu, Feb 24, 2022 at 05:25:53PM +0000, Raghavendra Rao Ananta wrote:
> Introduce the firmware register to hold the vendor specific
> hypervisor service calls (owner value 6) as a bitmap. The
> bitmap represents the features that'll be enabled for the
> guest, as configured by the user-space. Currently, this
> includes support only for Precision Time Protocol (PTP),
> represented by bit-0.
>
> The register is also added to the kvm_arm_vm_scope_fw_regs[]
> list as it maintains its state per-VM.
>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> ---
> arch/arm64/include/asm/kvm_host.h | 2 ++
> arch/arm64/include/uapi/asm/kvm.h | 4 ++++
> arch/arm64/kvm/guest.c | 1 +
> arch/arm64/kvm/hypercalls.c | 22 +++++++++++++++++++++-
> include/kvm/arm_hypercalls.h | 3 +++
> 5 files changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 318148b69279..d999456c4604 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -106,10 +106,12 @@ struct kvm_arch_memory_slot {
> *
> * @hvc_std_bmap: Bitmap of standard secure service calls
> * @hvc_std_hyp_bmap: Bitmap of standard hypervisor service calls
> + * @hvc_vendor_hyp_bmap: Bitmap of vendor specific hypervisor service calls
> */
> struct kvm_hvc_desc {
> u64 hvc_std_bmap;
> u64 hvc_std_hyp_bmap;
> + u64 hvc_vendor_hyp_bmap;
> };
>
> struct kvm_arch {
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index 9a2caead7359..ed470bde13d8 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -299,6 +299,10 @@ struct kvm_arm_copy_mte_tags {
> #define KVM_REG_ARM_STD_HYP_BIT_PV_TIME BIT(0)
> #define KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
>
> +#define KVM_REG_ARM_VENDOR_HYP_BMAP KVM_REG_ARM_FW_BMAP_REG(2)
> +#define KVM_REG_ARM_VENDOR_HYP_BIT_PTP BIT(0)
> +#define KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
> +
> /* SVE registers */
> #define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
>
> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> index c42426d6137e..fc3656f91aed 100644
> --- a/arch/arm64/kvm/guest.c
> +++ b/arch/arm64/kvm/guest.c
> @@ -67,6 +67,7 @@ static const u64 kvm_arm_vm_scope_fw_regs[] = {
> KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> KVM_REG_ARM_STD_BMAP,
> KVM_REG_ARM_STD_HYP_BMAP,
> + KVM_REG_ARM_VENDOR_HYP_BMAP,
> };
>
> /**
> diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> index ebc0cc26cf2e..5c5098c8f1f9 100644
> --- a/arch/arm64/kvm/hypercalls.c
> +++ b/arch/arm64/kvm/hypercalls.c
> @@ -79,6 +79,9 @@ static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> case ARM_SMCCC_HV_PV_TIME_ST:
> return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_hyp_bmap,
> KVM_REG_ARM_STD_HYP_BIT_PV_TIME);
> + case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
> + return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_vendor_hyp_bmap,
> + KVM_REG_ARM_VENDOR_HYP_BIT_PTP);
> default:
> /* By default, allow the services that aren't listed here */
> return true;
> @@ -162,7 +165,14 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> break;
> case ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID:
> val[0] = BIT(ARM_SMCCC_KVM_FUNC_FEATURES);
> - val[0] |= BIT(ARM_SMCCC_KVM_FUNC_PTP);
> +
> + /*
> + * The feature bits exposed to user-space doesn't include
> + * ARM_SMCCC_KVM_FUNC_FEATURES. However, we expose this to
> + * the guest as bit-0. Hence, left-shift the user-space
> + * exposed bitmap by 1 to accommodate this.
> + */
> + val[0] |= hvc_desc->hvc_vendor_hyp_bmap << 1;
Having an off-by-one difference between the userspace and guest
representations of this bitmap seems like it could be a source of bugs
in the future. Its also impossible for the guest to completely hide the
vendor range if it so chooses.
Why not tie ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID and
ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID to BIT(0)? PTP would then
become BIT(1).
> break;
> case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
> kvm_ptp_get_time(vcpu, val);
> @@ -188,6 +198,7 @@ static const u64 kvm_arm_fw_reg_ids[] = {
> KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> KVM_REG_ARM_STD_BMAP,
> KVM_REG_ARM_STD_HYP_BMAP,
> + KVM_REG_ARM_VENDOR_HYP_BMAP,
> };
>
> void kvm_arm_init_hypercalls(struct kvm *kvm)
> @@ -196,6 +207,7 @@ void kvm_arm_init_hypercalls(struct kvm *kvm)
>
> hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
> hvc_desc->hvc_std_hyp_bmap = ARM_SMCCC_STD_HYP_FEATURES;
> + hvc_desc->hvc_vendor_hyp_bmap = ARM_SMCCC_VENDOR_HYP_FEATURES;
> }
>
> int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> @@ -285,6 +297,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> case KVM_REG_ARM_STD_HYP_BMAP:
> val = READ_ONCE(hvc_desc->hvc_std_hyp_bmap);
> break;
> + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> + val = READ_ONCE(hvc_desc->hvc_vendor_hyp_bmap);
> + break;
> default:
> return -ENOENT;
> }
> @@ -311,6 +326,10 @@ static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
> fw_reg_bmap = &hvc_desc->hvc_std_hyp_bmap;
> fw_reg_features = ARM_SMCCC_STD_HYP_FEATURES;
> break;
> + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> + fw_reg_bmap = &hvc_desc->hvc_vendor_hyp_bmap;
> + fw_reg_features = ARM_SMCCC_VENDOR_HYP_FEATURES;
> + break;
> default:
> return -ENOENT;
> }
> @@ -416,6 +435,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> return 0;
> case KVM_REG_ARM_STD_BMAP:
> case KVM_REG_ARM_STD_HYP_BMAP:
> + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
> default:
> return -ENOENT;
> diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> index a1cb6e839c74..91be758ca58e 100644
> --- a/include/kvm/arm_hypercalls.h
> +++ b/include/kvm/arm_hypercalls.h
> @@ -12,6 +12,9 @@
> #define ARM_SMCCC_STD_HYP_FEATURES \
> GENMASK_ULL(KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX, 0)
>
> +#define ARM_SMCCC_VENDOR_HYP_FEATURES \
> + GENMASK_ULL(KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX, 0)
> +
> int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
>
> static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
> --
> 2.35.1.473.g83b2b277ed-goog
>
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 07/13] KVM: arm64: Add vendor hypervisor firmware register
@ 2022-03-14 19:59 ` Oliver Upton
0 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-14 19:59 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Thu, Feb 24, 2022 at 05:25:53PM +0000, Raghavendra Rao Ananta wrote:
> Introduce the firmware register to hold the vendor specific
> hypervisor service calls (owner value 6) as a bitmap. The
> bitmap represents the features that'll be enabled for the
> guest, as configured by the user-space. Currently, this
> includes support only for Precision Time Protocol (PTP),
> represented by bit-0.
>
> The register is also added to the kvm_arm_vm_scope_fw_regs[]
> list as it maintains its state per-VM.
>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> ---
> arch/arm64/include/asm/kvm_host.h | 2 ++
> arch/arm64/include/uapi/asm/kvm.h | 4 ++++
> arch/arm64/kvm/guest.c | 1 +
> arch/arm64/kvm/hypercalls.c | 22 +++++++++++++++++++++-
> include/kvm/arm_hypercalls.h | 3 +++
> 5 files changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 318148b69279..d999456c4604 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -106,10 +106,12 @@ struct kvm_arch_memory_slot {
> *
> * @hvc_std_bmap: Bitmap of standard secure service calls
> * @hvc_std_hyp_bmap: Bitmap of standard hypervisor service calls
> + * @hvc_vendor_hyp_bmap: Bitmap of vendor specific hypervisor service calls
> */
> struct kvm_hvc_desc {
> u64 hvc_std_bmap;
> u64 hvc_std_hyp_bmap;
> + u64 hvc_vendor_hyp_bmap;
> };
>
> struct kvm_arch {
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index 9a2caead7359..ed470bde13d8 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -299,6 +299,10 @@ struct kvm_arm_copy_mte_tags {
> #define KVM_REG_ARM_STD_HYP_BIT_PV_TIME BIT(0)
> #define KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
>
> +#define KVM_REG_ARM_VENDOR_HYP_BMAP KVM_REG_ARM_FW_BMAP_REG(2)
> +#define KVM_REG_ARM_VENDOR_HYP_BIT_PTP BIT(0)
> +#define KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
> +
> /* SVE registers */
> #define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
>
> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> index c42426d6137e..fc3656f91aed 100644
> --- a/arch/arm64/kvm/guest.c
> +++ b/arch/arm64/kvm/guest.c
> @@ -67,6 +67,7 @@ static const u64 kvm_arm_vm_scope_fw_regs[] = {
> KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> KVM_REG_ARM_STD_BMAP,
> KVM_REG_ARM_STD_HYP_BMAP,
> + KVM_REG_ARM_VENDOR_HYP_BMAP,
> };
>
> /**
> diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> index ebc0cc26cf2e..5c5098c8f1f9 100644
> --- a/arch/arm64/kvm/hypercalls.c
> +++ b/arch/arm64/kvm/hypercalls.c
> @@ -79,6 +79,9 @@ static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> case ARM_SMCCC_HV_PV_TIME_ST:
> return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_hyp_bmap,
> KVM_REG_ARM_STD_HYP_BIT_PV_TIME);
> + case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
> + return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_vendor_hyp_bmap,
> + KVM_REG_ARM_VENDOR_HYP_BIT_PTP);
> default:
> /* By default, allow the services that aren't listed here */
> return true;
> @@ -162,7 +165,14 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> break;
> case ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID:
> val[0] = BIT(ARM_SMCCC_KVM_FUNC_FEATURES);
> - val[0] |= BIT(ARM_SMCCC_KVM_FUNC_PTP);
> +
> + /*
> + * The feature bits exposed to user-space doesn't include
> + * ARM_SMCCC_KVM_FUNC_FEATURES. However, we expose this to
> + * the guest as bit-0. Hence, left-shift the user-space
> + * exposed bitmap by 1 to accommodate this.
> + */
> + val[0] |= hvc_desc->hvc_vendor_hyp_bmap << 1;
Having an off-by-one difference between the userspace and guest
representations of this bitmap seems like it could be a source of bugs
in the future. Its also impossible for the guest to completely hide the
vendor range if it so chooses.
Why not tie ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID and
ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID to BIT(0)? PTP would then
become BIT(1).
> break;
> case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
> kvm_ptp_get_time(vcpu, val);
> @@ -188,6 +198,7 @@ static const u64 kvm_arm_fw_reg_ids[] = {
> KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> KVM_REG_ARM_STD_BMAP,
> KVM_REG_ARM_STD_HYP_BMAP,
> + KVM_REG_ARM_VENDOR_HYP_BMAP,
> };
>
> void kvm_arm_init_hypercalls(struct kvm *kvm)
> @@ -196,6 +207,7 @@ void kvm_arm_init_hypercalls(struct kvm *kvm)
>
> hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
> hvc_desc->hvc_std_hyp_bmap = ARM_SMCCC_STD_HYP_FEATURES;
> + hvc_desc->hvc_vendor_hyp_bmap = ARM_SMCCC_VENDOR_HYP_FEATURES;
> }
>
> int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> @@ -285,6 +297,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> case KVM_REG_ARM_STD_HYP_BMAP:
> val = READ_ONCE(hvc_desc->hvc_std_hyp_bmap);
> break;
> + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> + val = READ_ONCE(hvc_desc->hvc_vendor_hyp_bmap);
> + break;
> default:
> return -ENOENT;
> }
> @@ -311,6 +326,10 @@ static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
> fw_reg_bmap = &hvc_desc->hvc_std_hyp_bmap;
> fw_reg_features = ARM_SMCCC_STD_HYP_FEATURES;
> break;
> + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> + fw_reg_bmap = &hvc_desc->hvc_vendor_hyp_bmap;
> + fw_reg_features = ARM_SMCCC_VENDOR_HYP_FEATURES;
> + break;
> default:
> return -ENOENT;
> }
> @@ -416,6 +435,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> return 0;
> case KVM_REG_ARM_STD_BMAP:
> case KVM_REG_ARM_STD_HYP_BMAP:
> + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
> default:
> return -ENOENT;
> diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> index a1cb6e839c74..91be758ca58e 100644
> --- a/include/kvm/arm_hypercalls.h
> +++ b/include/kvm/arm_hypercalls.h
> @@ -12,6 +12,9 @@
> #define ARM_SMCCC_STD_HYP_FEATURES \
> GENMASK_ULL(KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX, 0)
>
> +#define ARM_SMCCC_VENDOR_HYP_FEATURES \
> + GENMASK_ULL(KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX, 0)
> +
> int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
>
> static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
> --
> 2.35.1.473.g83b2b277ed-goog
>
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 07/13] KVM: arm64: Add vendor hypervisor firmware register
@ 2022-03-14 19:59 ` Oliver Upton
0 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-14 19:59 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Thu, Feb 24, 2022 at 05:25:53PM +0000, Raghavendra Rao Ananta wrote:
> Introduce the firmware register to hold the vendor specific
> hypervisor service calls (owner value 6) as a bitmap. The
> bitmap represents the features that'll be enabled for the
> guest, as configured by the user-space. Currently, this
> includes support only for Precision Time Protocol (PTP),
> represented by bit-0.
>
> The register is also added to the kvm_arm_vm_scope_fw_regs[]
> list as it maintains its state per-VM.
>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> ---
> arch/arm64/include/asm/kvm_host.h | 2 ++
> arch/arm64/include/uapi/asm/kvm.h | 4 ++++
> arch/arm64/kvm/guest.c | 1 +
> arch/arm64/kvm/hypercalls.c | 22 +++++++++++++++++++++-
> include/kvm/arm_hypercalls.h | 3 +++
> 5 files changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 318148b69279..d999456c4604 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -106,10 +106,12 @@ struct kvm_arch_memory_slot {
> *
> * @hvc_std_bmap: Bitmap of standard secure service calls
> * @hvc_std_hyp_bmap: Bitmap of standard hypervisor service calls
> + * @hvc_vendor_hyp_bmap: Bitmap of vendor specific hypervisor service calls
> */
> struct kvm_hvc_desc {
> u64 hvc_std_bmap;
> u64 hvc_std_hyp_bmap;
> + u64 hvc_vendor_hyp_bmap;
> };
>
> struct kvm_arch {
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index 9a2caead7359..ed470bde13d8 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -299,6 +299,10 @@ struct kvm_arm_copy_mte_tags {
> #define KVM_REG_ARM_STD_HYP_BIT_PV_TIME BIT(0)
> #define KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
>
> +#define KVM_REG_ARM_VENDOR_HYP_BMAP KVM_REG_ARM_FW_BMAP_REG(2)
> +#define KVM_REG_ARM_VENDOR_HYP_BIT_PTP BIT(0)
> +#define KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
> +
> /* SVE registers */
> #define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
>
> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> index c42426d6137e..fc3656f91aed 100644
> --- a/arch/arm64/kvm/guest.c
> +++ b/arch/arm64/kvm/guest.c
> @@ -67,6 +67,7 @@ static const u64 kvm_arm_vm_scope_fw_regs[] = {
> KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> KVM_REG_ARM_STD_BMAP,
> KVM_REG_ARM_STD_HYP_BMAP,
> + KVM_REG_ARM_VENDOR_HYP_BMAP,
> };
>
> /**
> diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> index ebc0cc26cf2e..5c5098c8f1f9 100644
> --- a/arch/arm64/kvm/hypercalls.c
> +++ b/arch/arm64/kvm/hypercalls.c
> @@ -79,6 +79,9 @@ static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> case ARM_SMCCC_HV_PV_TIME_ST:
> return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_hyp_bmap,
> KVM_REG_ARM_STD_HYP_BIT_PV_TIME);
> + case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
> + return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_vendor_hyp_bmap,
> + KVM_REG_ARM_VENDOR_HYP_BIT_PTP);
> default:
> /* By default, allow the services that aren't listed here */
> return true;
> @@ -162,7 +165,14 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> break;
> case ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID:
> val[0] = BIT(ARM_SMCCC_KVM_FUNC_FEATURES);
> - val[0] |= BIT(ARM_SMCCC_KVM_FUNC_PTP);
> +
> + /*
> + * The feature bits exposed to user-space doesn't include
> + * ARM_SMCCC_KVM_FUNC_FEATURES. However, we expose this to
> + * the guest as bit-0. Hence, left-shift the user-space
> + * exposed bitmap by 1 to accommodate this.
> + */
> + val[0] |= hvc_desc->hvc_vendor_hyp_bmap << 1;
Having an off-by-one difference between the userspace and guest
representations of this bitmap seems like it could be a source of bugs
in the future. Its also impossible for the guest to completely hide the
vendor range if it so chooses.
Why not tie ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID and
ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID to BIT(0)? PTP would then
become BIT(1).
> break;
> case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
> kvm_ptp_get_time(vcpu, val);
> @@ -188,6 +198,7 @@ static const u64 kvm_arm_fw_reg_ids[] = {
> KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> KVM_REG_ARM_STD_BMAP,
> KVM_REG_ARM_STD_HYP_BMAP,
> + KVM_REG_ARM_VENDOR_HYP_BMAP,
> };
>
> void kvm_arm_init_hypercalls(struct kvm *kvm)
> @@ -196,6 +207,7 @@ void kvm_arm_init_hypercalls(struct kvm *kvm)
>
> hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
> hvc_desc->hvc_std_hyp_bmap = ARM_SMCCC_STD_HYP_FEATURES;
> + hvc_desc->hvc_vendor_hyp_bmap = ARM_SMCCC_VENDOR_HYP_FEATURES;
> }
>
> int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> @@ -285,6 +297,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> case KVM_REG_ARM_STD_HYP_BMAP:
> val = READ_ONCE(hvc_desc->hvc_std_hyp_bmap);
> break;
> + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> + val = READ_ONCE(hvc_desc->hvc_vendor_hyp_bmap);
> + break;
> default:
> return -ENOENT;
> }
> @@ -311,6 +326,10 @@ static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
> fw_reg_bmap = &hvc_desc->hvc_std_hyp_bmap;
> fw_reg_features = ARM_SMCCC_STD_HYP_FEATURES;
> break;
> + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> + fw_reg_bmap = &hvc_desc->hvc_vendor_hyp_bmap;
> + fw_reg_features = ARM_SMCCC_VENDOR_HYP_FEATURES;
> + break;
> default:
> return -ENOENT;
> }
> @@ -416,6 +435,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> return 0;
> case KVM_REG_ARM_STD_BMAP:
> case KVM_REG_ARM_STD_HYP_BMAP:
> + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
> default:
> return -ENOENT;
> diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> index a1cb6e839c74..91be758ca58e 100644
> --- a/include/kvm/arm_hypercalls.h
> +++ b/include/kvm/arm_hypercalls.h
> @@ -12,6 +12,9 @@
> #define ARM_SMCCC_STD_HYP_FEATURES \
> GENMASK_ULL(KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX, 0)
>
> +#define ARM_SMCCC_VENDOR_HYP_FEATURES \
> + GENMASK_ULL(KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX, 0)
> +
> int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
>
> static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
> --
> 2.35.1.473.g83b2b277ed-goog
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 07/13] KVM: arm64: Add vendor hypervisor firmware register
2022-03-14 19:59 ` Oliver Upton
(?)
@ 2022-03-15 0:30 ` Raghavendra Rao Ananta
-1 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-03-15 0:30 UTC (permalink / raw)
To: Oliver Upton
Cc: kvm, Will Deacon, Marc Zyngier, Peter Shier, linux-kernel,
Catalin Marinas, Paolo Bonzini, kvmarm, linux-arm-kernel
On Mon, Mar 14, 2022 at 12:59 PM Oliver Upton <oupton@google.com> wrote:
>
> On Thu, Feb 24, 2022 at 05:25:53PM +0000, Raghavendra Rao Ananta wrote:
> > Introduce the firmware register to hold the vendor specific
> > hypervisor service calls (owner value 6) as a bitmap. The
> > bitmap represents the features that'll be enabled for the
> > guest, as configured by the user-space. Currently, this
> > includes support only for Precision Time Protocol (PTP),
> > represented by bit-0.
> >
> > The register is also added to the kvm_arm_vm_scope_fw_regs[]
> > list as it maintains its state per-VM.
> >
> > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > ---
> > arch/arm64/include/asm/kvm_host.h | 2 ++
> > arch/arm64/include/uapi/asm/kvm.h | 4 ++++
> > arch/arm64/kvm/guest.c | 1 +
> > arch/arm64/kvm/hypercalls.c | 22 +++++++++++++++++++++-
> > include/kvm/arm_hypercalls.h | 3 +++
> > 5 files changed, 31 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > index 318148b69279..d999456c4604 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -106,10 +106,12 @@ struct kvm_arch_memory_slot {
> > *
> > * @hvc_std_bmap: Bitmap of standard secure service calls
> > * @hvc_std_hyp_bmap: Bitmap of standard hypervisor service calls
> > + * @hvc_vendor_hyp_bmap: Bitmap of vendor specific hypervisor service calls
> > */
> > struct kvm_hvc_desc {
> > u64 hvc_std_bmap;
> > u64 hvc_std_hyp_bmap;
> > + u64 hvc_vendor_hyp_bmap;
> > };
> >
> > struct kvm_arch {
> > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > index 9a2caead7359..ed470bde13d8 100644
> > --- a/arch/arm64/include/uapi/asm/kvm.h
> > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > @@ -299,6 +299,10 @@ struct kvm_arm_copy_mte_tags {
> > #define KVM_REG_ARM_STD_HYP_BIT_PV_TIME BIT(0)
> > #define KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
> >
> > +#define KVM_REG_ARM_VENDOR_HYP_BMAP KVM_REG_ARM_FW_BMAP_REG(2)
> > +#define KVM_REG_ARM_VENDOR_HYP_BIT_PTP BIT(0)
> > +#define KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
> > +
> > /* SVE registers */
> > #define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
> >
> > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> > index c42426d6137e..fc3656f91aed 100644
> > --- a/arch/arm64/kvm/guest.c
> > +++ b/arch/arm64/kvm/guest.c
> > @@ -67,6 +67,7 @@ static const u64 kvm_arm_vm_scope_fw_regs[] = {
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > KVM_REG_ARM_STD_BMAP,
> > KVM_REG_ARM_STD_HYP_BMAP,
> > + KVM_REG_ARM_VENDOR_HYP_BMAP,
> > };
> >
> > /**
> > diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> > index ebc0cc26cf2e..5c5098c8f1f9 100644
> > --- a/arch/arm64/kvm/hypercalls.c
> > +++ b/arch/arm64/kvm/hypercalls.c
> > @@ -79,6 +79,9 @@ static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> > case ARM_SMCCC_HV_PV_TIME_ST:
> > return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_hyp_bmap,
> > KVM_REG_ARM_STD_HYP_BIT_PV_TIME);
> > + case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
> > + return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_vendor_hyp_bmap,
> > + KVM_REG_ARM_VENDOR_HYP_BIT_PTP);
> > default:
> > /* By default, allow the services that aren't listed here */
> > return true;
> > @@ -162,7 +165,14 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > break;
> > case ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID:
> > val[0] = BIT(ARM_SMCCC_KVM_FUNC_FEATURES);
> > - val[0] |= BIT(ARM_SMCCC_KVM_FUNC_PTP);
> > +
> > + /*
> > + * The feature bits exposed to user-space doesn't include
> > + * ARM_SMCCC_KVM_FUNC_FEATURES. However, we expose this to
> > + * the guest as bit-0. Hence, left-shift the user-space
> > + * exposed bitmap by 1 to accommodate this.
> > + */
> > + val[0] |= hvc_desc->hvc_vendor_hyp_bmap << 1;
>
> Having an off-by-one difference between the userspace and guest
> representations of this bitmap seems like it could be a source of bugs
> in the future. Its also impossible for the guest to completely hide the
> vendor range if it so chooses.
>
> Why not tie ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID and
> ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID to BIT(0)? PTP would then
> become BIT(1).
>
I agree it's a little asymmetrical. But exposing a bit for the
func_ids that you mentioned means providing a capability to disable
them by the userspace. This would block the guests from even
discovering the space. If it's not too ugly, we can maintain certain
bits to always remain read-only to the user-space. On the other hand,
we can simply ignore what the userspace configure and simply treat it
as a userspace bug. What do you think?
Regards,
Raghavendra
> > break;
> > case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
> > kvm_ptp_get_time(vcpu, val);
> > @@ -188,6 +198,7 @@ static const u64 kvm_arm_fw_reg_ids[] = {
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > KVM_REG_ARM_STD_BMAP,
> > KVM_REG_ARM_STD_HYP_BMAP,
> > + KVM_REG_ARM_VENDOR_HYP_BMAP,
> > };
> >
> > void kvm_arm_init_hypercalls(struct kvm *kvm)
> > @@ -196,6 +207,7 @@ void kvm_arm_init_hypercalls(struct kvm *kvm)
> >
> > hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
> > hvc_desc->hvc_std_hyp_bmap = ARM_SMCCC_STD_HYP_FEATURES;
> > + hvc_desc->hvc_vendor_hyp_bmap = ARM_SMCCC_VENDOR_HYP_FEATURES;
> > }
> >
> > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> > @@ -285,6 +297,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > case KVM_REG_ARM_STD_HYP_BMAP:
> > val = READ_ONCE(hvc_desc->hvc_std_hyp_bmap);
> > break;
> > + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> > + val = READ_ONCE(hvc_desc->hvc_vendor_hyp_bmap);
> > + break;
> > default:
> > return -ENOENT;
> > }
> > @@ -311,6 +326,10 @@ static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
> > fw_reg_bmap = &hvc_desc->hvc_std_hyp_bmap;
> > fw_reg_features = ARM_SMCCC_STD_HYP_FEATURES;
> > break;
> > + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> > + fw_reg_bmap = &hvc_desc->hvc_vendor_hyp_bmap;
> > + fw_reg_features = ARM_SMCCC_VENDOR_HYP_FEATURES;
> > + break;
> > default:
> > return -ENOENT;
> > }
> > @@ -416,6 +435,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > return 0;
> > case KVM_REG_ARM_STD_BMAP:
> > case KVM_REG_ARM_STD_HYP_BMAP:
> > + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> > return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
> > default:
> > return -ENOENT;
> > diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> > index a1cb6e839c74..91be758ca58e 100644
> > --- a/include/kvm/arm_hypercalls.h
> > +++ b/include/kvm/arm_hypercalls.h
> > @@ -12,6 +12,9 @@
> > #define ARM_SMCCC_STD_HYP_FEATURES \
> > GENMASK_ULL(KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX, 0)
> >
> > +#define ARM_SMCCC_VENDOR_HYP_FEATURES \
> > + GENMASK_ULL(KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX, 0)
> > +
> > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
> >
> > static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
> > --
> > 2.35.1.473.g83b2b277ed-goog
> >
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 07/13] KVM: arm64: Add vendor hypervisor firmware register
@ 2022-03-15 0:30 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-03-15 0:30 UTC (permalink / raw)
To: Oliver Upton
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Mon, Mar 14, 2022 at 12:59 PM Oliver Upton <oupton@google.com> wrote:
>
> On Thu, Feb 24, 2022 at 05:25:53PM +0000, Raghavendra Rao Ananta wrote:
> > Introduce the firmware register to hold the vendor specific
> > hypervisor service calls (owner value 6) as a bitmap. The
> > bitmap represents the features that'll be enabled for the
> > guest, as configured by the user-space. Currently, this
> > includes support only for Precision Time Protocol (PTP),
> > represented by bit-0.
> >
> > The register is also added to the kvm_arm_vm_scope_fw_regs[]
> > list as it maintains its state per-VM.
> >
> > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > ---
> > arch/arm64/include/asm/kvm_host.h | 2 ++
> > arch/arm64/include/uapi/asm/kvm.h | 4 ++++
> > arch/arm64/kvm/guest.c | 1 +
> > arch/arm64/kvm/hypercalls.c | 22 +++++++++++++++++++++-
> > include/kvm/arm_hypercalls.h | 3 +++
> > 5 files changed, 31 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > index 318148b69279..d999456c4604 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -106,10 +106,12 @@ struct kvm_arch_memory_slot {
> > *
> > * @hvc_std_bmap: Bitmap of standard secure service calls
> > * @hvc_std_hyp_bmap: Bitmap of standard hypervisor service calls
> > + * @hvc_vendor_hyp_bmap: Bitmap of vendor specific hypervisor service calls
> > */
> > struct kvm_hvc_desc {
> > u64 hvc_std_bmap;
> > u64 hvc_std_hyp_bmap;
> > + u64 hvc_vendor_hyp_bmap;
> > };
> >
> > struct kvm_arch {
> > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > index 9a2caead7359..ed470bde13d8 100644
> > --- a/arch/arm64/include/uapi/asm/kvm.h
> > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > @@ -299,6 +299,10 @@ struct kvm_arm_copy_mte_tags {
> > #define KVM_REG_ARM_STD_HYP_BIT_PV_TIME BIT(0)
> > #define KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
> >
> > +#define KVM_REG_ARM_VENDOR_HYP_BMAP KVM_REG_ARM_FW_BMAP_REG(2)
> > +#define KVM_REG_ARM_VENDOR_HYP_BIT_PTP BIT(0)
> > +#define KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
> > +
> > /* SVE registers */
> > #define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
> >
> > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> > index c42426d6137e..fc3656f91aed 100644
> > --- a/arch/arm64/kvm/guest.c
> > +++ b/arch/arm64/kvm/guest.c
> > @@ -67,6 +67,7 @@ static const u64 kvm_arm_vm_scope_fw_regs[] = {
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > KVM_REG_ARM_STD_BMAP,
> > KVM_REG_ARM_STD_HYP_BMAP,
> > + KVM_REG_ARM_VENDOR_HYP_BMAP,
> > };
> >
> > /**
> > diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> > index ebc0cc26cf2e..5c5098c8f1f9 100644
> > --- a/arch/arm64/kvm/hypercalls.c
> > +++ b/arch/arm64/kvm/hypercalls.c
> > @@ -79,6 +79,9 @@ static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> > case ARM_SMCCC_HV_PV_TIME_ST:
> > return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_hyp_bmap,
> > KVM_REG_ARM_STD_HYP_BIT_PV_TIME);
> > + case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
> > + return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_vendor_hyp_bmap,
> > + KVM_REG_ARM_VENDOR_HYP_BIT_PTP);
> > default:
> > /* By default, allow the services that aren't listed here */
> > return true;
> > @@ -162,7 +165,14 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > break;
> > case ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID:
> > val[0] = BIT(ARM_SMCCC_KVM_FUNC_FEATURES);
> > - val[0] |= BIT(ARM_SMCCC_KVM_FUNC_PTP);
> > +
> > + /*
> > + * The feature bits exposed to user-space doesn't include
> > + * ARM_SMCCC_KVM_FUNC_FEATURES. However, we expose this to
> > + * the guest as bit-0. Hence, left-shift the user-space
> > + * exposed bitmap by 1 to accommodate this.
> > + */
> > + val[0] |= hvc_desc->hvc_vendor_hyp_bmap << 1;
>
> Having an off-by-one difference between the userspace and guest
> representations of this bitmap seems like it could be a source of bugs
> in the future. Its also impossible for the guest to completely hide the
> vendor range if it so chooses.
>
> Why not tie ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID and
> ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID to BIT(0)? PTP would then
> become BIT(1).
>
I agree it's a little asymmetrical. But exposing a bit for the
func_ids that you mentioned means providing a capability to disable
them by the userspace. This would block the guests from even
discovering the space. If it's not too ugly, we can maintain certain
bits to always remain read-only to the user-space. On the other hand,
we can simply ignore what the userspace configure and simply treat it
as a userspace bug. What do you think?
Regards,
Raghavendra
> > break;
> > case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
> > kvm_ptp_get_time(vcpu, val);
> > @@ -188,6 +198,7 @@ static const u64 kvm_arm_fw_reg_ids[] = {
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > KVM_REG_ARM_STD_BMAP,
> > KVM_REG_ARM_STD_HYP_BMAP,
> > + KVM_REG_ARM_VENDOR_HYP_BMAP,
> > };
> >
> > void kvm_arm_init_hypercalls(struct kvm *kvm)
> > @@ -196,6 +207,7 @@ void kvm_arm_init_hypercalls(struct kvm *kvm)
> >
> > hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
> > hvc_desc->hvc_std_hyp_bmap = ARM_SMCCC_STD_HYP_FEATURES;
> > + hvc_desc->hvc_vendor_hyp_bmap = ARM_SMCCC_VENDOR_HYP_FEATURES;
> > }
> >
> > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> > @@ -285,6 +297,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > case KVM_REG_ARM_STD_HYP_BMAP:
> > val = READ_ONCE(hvc_desc->hvc_std_hyp_bmap);
> > break;
> > + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> > + val = READ_ONCE(hvc_desc->hvc_vendor_hyp_bmap);
> > + break;
> > default:
> > return -ENOENT;
> > }
> > @@ -311,6 +326,10 @@ static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
> > fw_reg_bmap = &hvc_desc->hvc_std_hyp_bmap;
> > fw_reg_features = ARM_SMCCC_STD_HYP_FEATURES;
> > break;
> > + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> > + fw_reg_bmap = &hvc_desc->hvc_vendor_hyp_bmap;
> > + fw_reg_features = ARM_SMCCC_VENDOR_HYP_FEATURES;
> > + break;
> > default:
> > return -ENOENT;
> > }
> > @@ -416,6 +435,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > return 0;
> > case KVM_REG_ARM_STD_BMAP:
> > case KVM_REG_ARM_STD_HYP_BMAP:
> > + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> > return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
> > default:
> > return -ENOENT;
> > diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> > index a1cb6e839c74..91be758ca58e 100644
> > --- a/include/kvm/arm_hypercalls.h
> > +++ b/include/kvm/arm_hypercalls.h
> > @@ -12,6 +12,9 @@
> > #define ARM_SMCCC_STD_HYP_FEATURES \
> > GENMASK_ULL(KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX, 0)
> >
> > +#define ARM_SMCCC_VENDOR_HYP_FEATURES \
> > + GENMASK_ULL(KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX, 0)
> > +
> > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
> >
> > static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
> > --
> > 2.35.1.473.g83b2b277ed-goog
> >
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 07/13] KVM: arm64: Add vendor hypervisor firmware register
@ 2022-03-15 0:30 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-03-15 0:30 UTC (permalink / raw)
To: Oliver Upton
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Mon, Mar 14, 2022 at 12:59 PM Oliver Upton <oupton@google.com> wrote:
>
> On Thu, Feb 24, 2022 at 05:25:53PM +0000, Raghavendra Rao Ananta wrote:
> > Introduce the firmware register to hold the vendor specific
> > hypervisor service calls (owner value 6) as a bitmap. The
> > bitmap represents the features that'll be enabled for the
> > guest, as configured by the user-space. Currently, this
> > includes support only for Precision Time Protocol (PTP),
> > represented by bit-0.
> >
> > The register is also added to the kvm_arm_vm_scope_fw_regs[]
> > list as it maintains its state per-VM.
> >
> > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > ---
> > arch/arm64/include/asm/kvm_host.h | 2 ++
> > arch/arm64/include/uapi/asm/kvm.h | 4 ++++
> > arch/arm64/kvm/guest.c | 1 +
> > arch/arm64/kvm/hypercalls.c | 22 +++++++++++++++++++++-
> > include/kvm/arm_hypercalls.h | 3 +++
> > 5 files changed, 31 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > index 318148b69279..d999456c4604 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -106,10 +106,12 @@ struct kvm_arch_memory_slot {
> > *
> > * @hvc_std_bmap: Bitmap of standard secure service calls
> > * @hvc_std_hyp_bmap: Bitmap of standard hypervisor service calls
> > + * @hvc_vendor_hyp_bmap: Bitmap of vendor specific hypervisor service calls
> > */
> > struct kvm_hvc_desc {
> > u64 hvc_std_bmap;
> > u64 hvc_std_hyp_bmap;
> > + u64 hvc_vendor_hyp_bmap;
> > };
> >
> > struct kvm_arch {
> > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > index 9a2caead7359..ed470bde13d8 100644
> > --- a/arch/arm64/include/uapi/asm/kvm.h
> > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > @@ -299,6 +299,10 @@ struct kvm_arm_copy_mte_tags {
> > #define KVM_REG_ARM_STD_HYP_BIT_PV_TIME BIT(0)
> > #define KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
> >
> > +#define KVM_REG_ARM_VENDOR_HYP_BMAP KVM_REG_ARM_FW_BMAP_REG(2)
> > +#define KVM_REG_ARM_VENDOR_HYP_BIT_PTP BIT(0)
> > +#define KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
> > +
> > /* SVE registers */
> > #define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
> >
> > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> > index c42426d6137e..fc3656f91aed 100644
> > --- a/arch/arm64/kvm/guest.c
> > +++ b/arch/arm64/kvm/guest.c
> > @@ -67,6 +67,7 @@ static const u64 kvm_arm_vm_scope_fw_regs[] = {
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > KVM_REG_ARM_STD_BMAP,
> > KVM_REG_ARM_STD_HYP_BMAP,
> > + KVM_REG_ARM_VENDOR_HYP_BMAP,
> > };
> >
> > /**
> > diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> > index ebc0cc26cf2e..5c5098c8f1f9 100644
> > --- a/arch/arm64/kvm/hypercalls.c
> > +++ b/arch/arm64/kvm/hypercalls.c
> > @@ -79,6 +79,9 @@ static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> > case ARM_SMCCC_HV_PV_TIME_ST:
> > return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_hyp_bmap,
> > KVM_REG_ARM_STD_HYP_BIT_PV_TIME);
> > + case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
> > + return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_vendor_hyp_bmap,
> > + KVM_REG_ARM_VENDOR_HYP_BIT_PTP);
> > default:
> > /* By default, allow the services that aren't listed here */
> > return true;
> > @@ -162,7 +165,14 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > break;
> > case ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID:
> > val[0] = BIT(ARM_SMCCC_KVM_FUNC_FEATURES);
> > - val[0] |= BIT(ARM_SMCCC_KVM_FUNC_PTP);
> > +
> > + /*
> > + * The feature bits exposed to user-space doesn't include
> > + * ARM_SMCCC_KVM_FUNC_FEATURES. However, we expose this to
> > + * the guest as bit-0. Hence, left-shift the user-space
> > + * exposed bitmap by 1 to accommodate this.
> > + */
> > + val[0] |= hvc_desc->hvc_vendor_hyp_bmap << 1;
>
> Having an off-by-one difference between the userspace and guest
> representations of this bitmap seems like it could be a source of bugs
> in the future. Its also impossible for the guest to completely hide the
> vendor range if it so chooses.
>
> Why not tie ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID and
> ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID to BIT(0)? PTP would then
> become BIT(1).
>
I agree it's a little asymmetrical. But exposing a bit for the
func_ids that you mentioned means providing a capability to disable
them by the userspace. This would block the guests from even
discovering the space. If it's not too ugly, we can maintain certain
bits to always remain read-only to the user-space. On the other hand,
we can simply ignore what the userspace configure and simply treat it
as a userspace bug. What do you think?
Regards,
Raghavendra
> > break;
> > case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
> > kvm_ptp_get_time(vcpu, val);
> > @@ -188,6 +198,7 @@ static const u64 kvm_arm_fw_reg_ids[] = {
> > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > KVM_REG_ARM_STD_BMAP,
> > KVM_REG_ARM_STD_HYP_BMAP,
> > + KVM_REG_ARM_VENDOR_HYP_BMAP,
> > };
> >
> > void kvm_arm_init_hypercalls(struct kvm *kvm)
> > @@ -196,6 +207,7 @@ void kvm_arm_init_hypercalls(struct kvm *kvm)
> >
> > hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
> > hvc_desc->hvc_std_hyp_bmap = ARM_SMCCC_STD_HYP_FEATURES;
> > + hvc_desc->hvc_vendor_hyp_bmap = ARM_SMCCC_VENDOR_HYP_FEATURES;
> > }
> >
> > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> > @@ -285,6 +297,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > case KVM_REG_ARM_STD_HYP_BMAP:
> > val = READ_ONCE(hvc_desc->hvc_std_hyp_bmap);
> > break;
> > + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> > + val = READ_ONCE(hvc_desc->hvc_vendor_hyp_bmap);
> > + break;
> > default:
> > return -ENOENT;
> > }
> > @@ -311,6 +326,10 @@ static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
> > fw_reg_bmap = &hvc_desc->hvc_std_hyp_bmap;
> > fw_reg_features = ARM_SMCCC_STD_HYP_FEATURES;
> > break;
> > + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> > + fw_reg_bmap = &hvc_desc->hvc_vendor_hyp_bmap;
> > + fw_reg_features = ARM_SMCCC_VENDOR_HYP_FEATURES;
> > + break;
> > default:
> > return -ENOENT;
> > }
> > @@ -416,6 +435,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > return 0;
> > case KVM_REG_ARM_STD_BMAP:
> > case KVM_REG_ARM_STD_HYP_BMAP:
> > + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> > return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
> > default:
> > return -ENOENT;
> > diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> > index a1cb6e839c74..91be758ca58e 100644
> > --- a/include/kvm/arm_hypercalls.h
> > +++ b/include/kvm/arm_hypercalls.h
> > @@ -12,6 +12,9 @@
> > #define ARM_SMCCC_STD_HYP_FEATURES \
> > GENMASK_ULL(KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX, 0)
> >
> > +#define ARM_SMCCC_VENDOR_HYP_FEATURES \
> > + GENMASK_ULL(KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX, 0)
> > +
> > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
> >
> > static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
> > --
> > 2.35.1.473.g83b2b277ed-goog
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 07/13] KVM: arm64: Add vendor hypervisor firmware register
2022-03-15 0:30 ` Raghavendra Rao Ananta
(?)
@ 2022-03-15 6:41 ` Oliver Upton
-1 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-15 6:41 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: kvm, Will Deacon, Marc Zyngier, Peter Shier, linux-kernel,
Catalin Marinas, Paolo Bonzini, kvmarm, linux-arm-kernel
On Mon, Mar 14, 2022 at 05:30:15PM -0700, Raghavendra Rao Ananta wrote:
> On Mon, Mar 14, 2022 at 12:59 PM Oliver Upton <oupton@google.com> wrote:
> >
> > On Thu, Feb 24, 2022 at 05:25:53PM +0000, Raghavendra Rao Ananta wrote:
> > > Introduce the firmware register to hold the vendor specific
> > > hypervisor service calls (owner value 6) as a bitmap. The
> > > bitmap represents the features that'll be enabled for the
> > > guest, as configured by the user-space. Currently, this
> > > includes support only for Precision Time Protocol (PTP),
> > > represented by bit-0.
> > >
> > > The register is also added to the kvm_arm_vm_scope_fw_regs[]
> > > list as it maintains its state per-VM.
> > >
> > > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > > ---
> > > arch/arm64/include/asm/kvm_host.h | 2 ++
> > > arch/arm64/include/uapi/asm/kvm.h | 4 ++++
> > > arch/arm64/kvm/guest.c | 1 +
> > > arch/arm64/kvm/hypercalls.c | 22 +++++++++++++++++++++-
> > > include/kvm/arm_hypercalls.h | 3 +++
> > > 5 files changed, 31 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > > index 318148b69279..d999456c4604 100644
> > > --- a/arch/arm64/include/asm/kvm_host.h
> > > +++ b/arch/arm64/include/asm/kvm_host.h
> > > @@ -106,10 +106,12 @@ struct kvm_arch_memory_slot {
> > > *
> > > * @hvc_std_bmap: Bitmap of standard secure service calls
> > > * @hvc_std_hyp_bmap: Bitmap of standard hypervisor service calls
> > > + * @hvc_vendor_hyp_bmap: Bitmap of vendor specific hypervisor service calls
> > > */
> > > struct kvm_hvc_desc {
> > > u64 hvc_std_bmap;
> > > u64 hvc_std_hyp_bmap;
> > > + u64 hvc_vendor_hyp_bmap;
> > > };
> > >
> > > struct kvm_arch {
> > > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > > index 9a2caead7359..ed470bde13d8 100644
> > > --- a/arch/arm64/include/uapi/asm/kvm.h
> > > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > > @@ -299,6 +299,10 @@ struct kvm_arm_copy_mte_tags {
> > > #define KVM_REG_ARM_STD_HYP_BIT_PV_TIME BIT(0)
> > > #define KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
> > >
> > > +#define KVM_REG_ARM_VENDOR_HYP_BMAP KVM_REG_ARM_FW_BMAP_REG(2)
> > > +#define KVM_REG_ARM_VENDOR_HYP_BIT_PTP BIT(0)
> > > +#define KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
> > > +
> > > /* SVE registers */
> > > #define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
> > >
> > > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> > > index c42426d6137e..fc3656f91aed 100644
> > > --- a/arch/arm64/kvm/guest.c
> > > +++ b/arch/arm64/kvm/guest.c
> > > @@ -67,6 +67,7 @@ static const u64 kvm_arm_vm_scope_fw_regs[] = {
> > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > > KVM_REG_ARM_STD_BMAP,
> > > KVM_REG_ARM_STD_HYP_BMAP,
> > > + KVM_REG_ARM_VENDOR_HYP_BMAP,
> > > };
> > >
> > > /**
> > > diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> > > index ebc0cc26cf2e..5c5098c8f1f9 100644
> > > --- a/arch/arm64/kvm/hypercalls.c
> > > +++ b/arch/arm64/kvm/hypercalls.c
> > > @@ -79,6 +79,9 @@ static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> > > case ARM_SMCCC_HV_PV_TIME_ST:
> > > return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_hyp_bmap,
> > > KVM_REG_ARM_STD_HYP_BIT_PV_TIME);
> > > + case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
> > > + return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_vendor_hyp_bmap,
> > > + KVM_REG_ARM_VENDOR_HYP_BIT_PTP);
> > > default:
> > > /* By default, allow the services that aren't listed here */
> > > return true;
> > > @@ -162,7 +165,14 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > > break;
> > > case ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID:
> > > val[0] = BIT(ARM_SMCCC_KVM_FUNC_FEATURES);
> > > - val[0] |= BIT(ARM_SMCCC_KVM_FUNC_PTP);
> > > +
> > > + /*
> > > + * The feature bits exposed to user-space doesn't include
> > > + * ARM_SMCCC_KVM_FUNC_FEATURES. However, we expose this to
> > > + * the guest as bit-0. Hence, left-shift the user-space
> > > + * exposed bitmap by 1 to accommodate this.
> > > + */
> > > + val[0] |= hvc_desc->hvc_vendor_hyp_bmap << 1;
> >
> > Having an off-by-one difference between the userspace and guest
> > representations of this bitmap seems like it could be a source of bugs
> > in the future. Its also impossible for the guest to completely hide the
> > vendor range if it so chooses.
> >
> > Why not tie ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID and
> > ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID to BIT(0)? PTP would then
> > become BIT(1).
> >
> I agree it's a little asymmetrical. But exposing a bit for the
> func_ids that you mentioned means providing a capability to disable
> them by the userspace. This would block the guests from even
> discovering the space. If it's not too ugly, we can maintain certain
> bits to always remain read-only to the user-space. On the other hand,
> we can simply ignore what the userspace configure and simply treat it
> as a userspace bug. What do you think?
I think that assigning a bit to the aforementioned hypercalls would be
best. If userspace decides to hide all the features enumerated in the
subrange then there isn't much point to the guest knowing that the range
even exists. It shouldn't amount to much for userspace, as it will
likely just keep the default value and only worry about these registers
when migrating.
Apologies if I'm being pedantic, but such a subtle implementation detail
could be overlooked in future changes.
--
Oliver
> > > break;
> > > case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
> > > kvm_ptp_get_time(vcpu, val);
> > > @@ -188,6 +198,7 @@ static const u64 kvm_arm_fw_reg_ids[] = {
> > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > > KVM_REG_ARM_STD_BMAP,
> > > KVM_REG_ARM_STD_HYP_BMAP,
> > > + KVM_REG_ARM_VENDOR_HYP_BMAP,
> > > };
> > >
> > > void kvm_arm_init_hypercalls(struct kvm *kvm)
> > > @@ -196,6 +207,7 @@ void kvm_arm_init_hypercalls(struct kvm *kvm)
> > >
> > > hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
> > > hvc_desc->hvc_std_hyp_bmap = ARM_SMCCC_STD_HYP_FEATURES;
> > > + hvc_desc->hvc_vendor_hyp_bmap = ARM_SMCCC_VENDOR_HYP_FEATURES;
> > > }
> > >
> > > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> > > @@ -285,6 +297,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > case KVM_REG_ARM_STD_HYP_BMAP:
> > > val = READ_ONCE(hvc_desc->hvc_std_hyp_bmap);
> > > break;
> > > + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> > > + val = READ_ONCE(hvc_desc->hvc_vendor_hyp_bmap);
> > > + break;
> > > default:
> > > return -ENOENT;
> > > }
> > > @@ -311,6 +326,10 @@ static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
> > > fw_reg_bmap = &hvc_desc->hvc_std_hyp_bmap;
> > > fw_reg_features = ARM_SMCCC_STD_HYP_FEATURES;
> > > break;
> > > + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> > > + fw_reg_bmap = &hvc_desc->hvc_vendor_hyp_bmap;
> > > + fw_reg_features = ARM_SMCCC_VENDOR_HYP_FEATURES;
> > > + break;
> > > default:
> > > return -ENOENT;
> > > }
> > > @@ -416,6 +435,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > return 0;
> > > case KVM_REG_ARM_STD_BMAP:
> > > case KVM_REG_ARM_STD_HYP_BMAP:
> > > + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> > > return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
> > > default:
> > > return -ENOENT;
> > > diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> > > index a1cb6e839c74..91be758ca58e 100644
> > > --- a/include/kvm/arm_hypercalls.h
> > > +++ b/include/kvm/arm_hypercalls.h
> > > @@ -12,6 +12,9 @@
> > > #define ARM_SMCCC_STD_HYP_FEATURES \
> > > GENMASK_ULL(KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX, 0)
> > >
> > > +#define ARM_SMCCC_VENDOR_HYP_FEATURES \
> > > + GENMASK_ULL(KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX, 0)
> > > +
> > > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
> > >
> > > static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
> > > --
> > > 2.35.1.473.g83b2b277ed-goog
> > >
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 07/13] KVM: arm64: Add vendor hypervisor firmware register
@ 2022-03-15 6:41 ` Oliver Upton
0 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-15 6:41 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Mon, Mar 14, 2022 at 05:30:15PM -0700, Raghavendra Rao Ananta wrote:
> On Mon, Mar 14, 2022 at 12:59 PM Oliver Upton <oupton@google.com> wrote:
> >
> > On Thu, Feb 24, 2022 at 05:25:53PM +0000, Raghavendra Rao Ananta wrote:
> > > Introduce the firmware register to hold the vendor specific
> > > hypervisor service calls (owner value 6) as a bitmap. The
> > > bitmap represents the features that'll be enabled for the
> > > guest, as configured by the user-space. Currently, this
> > > includes support only for Precision Time Protocol (PTP),
> > > represented by bit-0.
> > >
> > > The register is also added to the kvm_arm_vm_scope_fw_regs[]
> > > list as it maintains its state per-VM.
> > >
> > > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > > ---
> > > arch/arm64/include/asm/kvm_host.h | 2 ++
> > > arch/arm64/include/uapi/asm/kvm.h | 4 ++++
> > > arch/arm64/kvm/guest.c | 1 +
> > > arch/arm64/kvm/hypercalls.c | 22 +++++++++++++++++++++-
> > > include/kvm/arm_hypercalls.h | 3 +++
> > > 5 files changed, 31 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > > index 318148b69279..d999456c4604 100644
> > > --- a/arch/arm64/include/asm/kvm_host.h
> > > +++ b/arch/arm64/include/asm/kvm_host.h
> > > @@ -106,10 +106,12 @@ struct kvm_arch_memory_slot {
> > > *
> > > * @hvc_std_bmap: Bitmap of standard secure service calls
> > > * @hvc_std_hyp_bmap: Bitmap of standard hypervisor service calls
> > > + * @hvc_vendor_hyp_bmap: Bitmap of vendor specific hypervisor service calls
> > > */
> > > struct kvm_hvc_desc {
> > > u64 hvc_std_bmap;
> > > u64 hvc_std_hyp_bmap;
> > > + u64 hvc_vendor_hyp_bmap;
> > > };
> > >
> > > struct kvm_arch {
> > > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > > index 9a2caead7359..ed470bde13d8 100644
> > > --- a/arch/arm64/include/uapi/asm/kvm.h
> > > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > > @@ -299,6 +299,10 @@ struct kvm_arm_copy_mte_tags {
> > > #define KVM_REG_ARM_STD_HYP_BIT_PV_TIME BIT(0)
> > > #define KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
> > >
> > > +#define KVM_REG_ARM_VENDOR_HYP_BMAP KVM_REG_ARM_FW_BMAP_REG(2)
> > > +#define KVM_REG_ARM_VENDOR_HYP_BIT_PTP BIT(0)
> > > +#define KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
> > > +
> > > /* SVE registers */
> > > #define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
> > >
> > > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> > > index c42426d6137e..fc3656f91aed 100644
> > > --- a/arch/arm64/kvm/guest.c
> > > +++ b/arch/arm64/kvm/guest.c
> > > @@ -67,6 +67,7 @@ static const u64 kvm_arm_vm_scope_fw_regs[] = {
> > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > > KVM_REG_ARM_STD_BMAP,
> > > KVM_REG_ARM_STD_HYP_BMAP,
> > > + KVM_REG_ARM_VENDOR_HYP_BMAP,
> > > };
> > >
> > > /**
> > > diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> > > index ebc0cc26cf2e..5c5098c8f1f9 100644
> > > --- a/arch/arm64/kvm/hypercalls.c
> > > +++ b/arch/arm64/kvm/hypercalls.c
> > > @@ -79,6 +79,9 @@ static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> > > case ARM_SMCCC_HV_PV_TIME_ST:
> > > return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_hyp_bmap,
> > > KVM_REG_ARM_STD_HYP_BIT_PV_TIME);
> > > + case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
> > > + return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_vendor_hyp_bmap,
> > > + KVM_REG_ARM_VENDOR_HYP_BIT_PTP);
> > > default:
> > > /* By default, allow the services that aren't listed here */
> > > return true;
> > > @@ -162,7 +165,14 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > > break;
> > > case ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID:
> > > val[0] = BIT(ARM_SMCCC_KVM_FUNC_FEATURES);
> > > - val[0] |= BIT(ARM_SMCCC_KVM_FUNC_PTP);
> > > +
> > > + /*
> > > + * The feature bits exposed to user-space doesn't include
> > > + * ARM_SMCCC_KVM_FUNC_FEATURES. However, we expose this to
> > > + * the guest as bit-0. Hence, left-shift the user-space
> > > + * exposed bitmap by 1 to accommodate this.
> > > + */
> > > + val[0] |= hvc_desc->hvc_vendor_hyp_bmap << 1;
> >
> > Having an off-by-one difference between the userspace and guest
> > representations of this bitmap seems like it could be a source of bugs
> > in the future. Its also impossible for the guest to completely hide the
> > vendor range if it so chooses.
> >
> > Why not tie ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID and
> > ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID to BIT(0)? PTP would then
> > become BIT(1).
> >
> I agree it's a little asymmetrical. But exposing a bit for the
> func_ids that you mentioned means providing a capability to disable
> them by the userspace. This would block the guests from even
> discovering the space. If it's not too ugly, we can maintain certain
> bits to always remain read-only to the user-space. On the other hand,
> we can simply ignore what the userspace configure and simply treat it
> as a userspace bug. What do you think?
I think that assigning a bit to the aforementioned hypercalls would be
best. If userspace decides to hide all the features enumerated in the
subrange then there isn't much point to the guest knowing that the range
even exists. It shouldn't amount to much for userspace, as it will
likely just keep the default value and only worry about these registers
when migrating.
Apologies if I'm being pedantic, but such a subtle implementation detail
could be overlooked in future changes.
--
Oliver
> > > break;
> > > case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
> > > kvm_ptp_get_time(vcpu, val);
> > > @@ -188,6 +198,7 @@ static const u64 kvm_arm_fw_reg_ids[] = {
> > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > > KVM_REG_ARM_STD_BMAP,
> > > KVM_REG_ARM_STD_HYP_BMAP,
> > > + KVM_REG_ARM_VENDOR_HYP_BMAP,
> > > };
> > >
> > > void kvm_arm_init_hypercalls(struct kvm *kvm)
> > > @@ -196,6 +207,7 @@ void kvm_arm_init_hypercalls(struct kvm *kvm)
> > >
> > > hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
> > > hvc_desc->hvc_std_hyp_bmap = ARM_SMCCC_STD_HYP_FEATURES;
> > > + hvc_desc->hvc_vendor_hyp_bmap = ARM_SMCCC_VENDOR_HYP_FEATURES;
> > > }
> > >
> > > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> > > @@ -285,6 +297,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > case KVM_REG_ARM_STD_HYP_BMAP:
> > > val = READ_ONCE(hvc_desc->hvc_std_hyp_bmap);
> > > break;
> > > + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> > > + val = READ_ONCE(hvc_desc->hvc_vendor_hyp_bmap);
> > > + break;
> > > default:
> > > return -ENOENT;
> > > }
> > > @@ -311,6 +326,10 @@ static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
> > > fw_reg_bmap = &hvc_desc->hvc_std_hyp_bmap;
> > > fw_reg_features = ARM_SMCCC_STD_HYP_FEATURES;
> > > break;
> > > + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> > > + fw_reg_bmap = &hvc_desc->hvc_vendor_hyp_bmap;
> > > + fw_reg_features = ARM_SMCCC_VENDOR_HYP_FEATURES;
> > > + break;
> > > default:
> > > return -ENOENT;
> > > }
> > > @@ -416,6 +435,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > return 0;
> > > case KVM_REG_ARM_STD_BMAP:
> > > case KVM_REG_ARM_STD_HYP_BMAP:
> > > + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> > > return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
> > > default:
> > > return -ENOENT;
> > > diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> > > index a1cb6e839c74..91be758ca58e 100644
> > > --- a/include/kvm/arm_hypercalls.h
> > > +++ b/include/kvm/arm_hypercalls.h
> > > @@ -12,6 +12,9 @@
> > > #define ARM_SMCCC_STD_HYP_FEATURES \
> > > GENMASK_ULL(KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX, 0)
> > >
> > > +#define ARM_SMCCC_VENDOR_HYP_FEATURES \
> > > + GENMASK_ULL(KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX, 0)
> > > +
> > > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
> > >
> > > static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
> > > --
> > > 2.35.1.473.g83b2b277ed-goog
> > >
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 07/13] KVM: arm64: Add vendor hypervisor firmware register
@ 2022-03-15 6:41 ` Oliver Upton
0 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-15 6:41 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Mon, Mar 14, 2022 at 05:30:15PM -0700, Raghavendra Rao Ananta wrote:
> On Mon, Mar 14, 2022 at 12:59 PM Oliver Upton <oupton@google.com> wrote:
> >
> > On Thu, Feb 24, 2022 at 05:25:53PM +0000, Raghavendra Rao Ananta wrote:
> > > Introduce the firmware register to hold the vendor specific
> > > hypervisor service calls (owner value 6) as a bitmap. The
> > > bitmap represents the features that'll be enabled for the
> > > guest, as configured by the user-space. Currently, this
> > > includes support only for Precision Time Protocol (PTP),
> > > represented by bit-0.
> > >
> > > The register is also added to the kvm_arm_vm_scope_fw_regs[]
> > > list as it maintains its state per-VM.
> > >
> > > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > > ---
> > > arch/arm64/include/asm/kvm_host.h | 2 ++
> > > arch/arm64/include/uapi/asm/kvm.h | 4 ++++
> > > arch/arm64/kvm/guest.c | 1 +
> > > arch/arm64/kvm/hypercalls.c | 22 +++++++++++++++++++++-
> > > include/kvm/arm_hypercalls.h | 3 +++
> > > 5 files changed, 31 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > > index 318148b69279..d999456c4604 100644
> > > --- a/arch/arm64/include/asm/kvm_host.h
> > > +++ b/arch/arm64/include/asm/kvm_host.h
> > > @@ -106,10 +106,12 @@ struct kvm_arch_memory_slot {
> > > *
> > > * @hvc_std_bmap: Bitmap of standard secure service calls
> > > * @hvc_std_hyp_bmap: Bitmap of standard hypervisor service calls
> > > + * @hvc_vendor_hyp_bmap: Bitmap of vendor specific hypervisor service calls
> > > */
> > > struct kvm_hvc_desc {
> > > u64 hvc_std_bmap;
> > > u64 hvc_std_hyp_bmap;
> > > + u64 hvc_vendor_hyp_bmap;
> > > };
> > >
> > > struct kvm_arch {
> > > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > > index 9a2caead7359..ed470bde13d8 100644
> > > --- a/arch/arm64/include/uapi/asm/kvm.h
> > > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > > @@ -299,6 +299,10 @@ struct kvm_arm_copy_mte_tags {
> > > #define KVM_REG_ARM_STD_HYP_BIT_PV_TIME BIT(0)
> > > #define KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
> > >
> > > +#define KVM_REG_ARM_VENDOR_HYP_BMAP KVM_REG_ARM_FW_BMAP_REG(2)
> > > +#define KVM_REG_ARM_VENDOR_HYP_BIT_PTP BIT(0)
> > > +#define KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
> > > +
> > > /* SVE registers */
> > > #define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
> > >
> > > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> > > index c42426d6137e..fc3656f91aed 100644
> > > --- a/arch/arm64/kvm/guest.c
> > > +++ b/arch/arm64/kvm/guest.c
> > > @@ -67,6 +67,7 @@ static const u64 kvm_arm_vm_scope_fw_regs[] = {
> > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > > KVM_REG_ARM_STD_BMAP,
> > > KVM_REG_ARM_STD_HYP_BMAP,
> > > + KVM_REG_ARM_VENDOR_HYP_BMAP,
> > > };
> > >
> > > /**
> > > diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> > > index ebc0cc26cf2e..5c5098c8f1f9 100644
> > > --- a/arch/arm64/kvm/hypercalls.c
> > > +++ b/arch/arm64/kvm/hypercalls.c
> > > @@ -79,6 +79,9 @@ static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> > > case ARM_SMCCC_HV_PV_TIME_ST:
> > > return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_hyp_bmap,
> > > KVM_REG_ARM_STD_HYP_BIT_PV_TIME);
> > > + case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
> > > + return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_vendor_hyp_bmap,
> > > + KVM_REG_ARM_VENDOR_HYP_BIT_PTP);
> > > default:
> > > /* By default, allow the services that aren't listed here */
> > > return true;
> > > @@ -162,7 +165,14 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > > break;
> > > case ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID:
> > > val[0] = BIT(ARM_SMCCC_KVM_FUNC_FEATURES);
> > > - val[0] |= BIT(ARM_SMCCC_KVM_FUNC_PTP);
> > > +
> > > + /*
> > > + * The feature bits exposed to user-space doesn't include
> > > + * ARM_SMCCC_KVM_FUNC_FEATURES. However, we expose this to
> > > + * the guest as bit-0. Hence, left-shift the user-space
> > > + * exposed bitmap by 1 to accommodate this.
> > > + */
> > > + val[0] |= hvc_desc->hvc_vendor_hyp_bmap << 1;
> >
> > Having an off-by-one difference between the userspace and guest
> > representations of this bitmap seems like it could be a source of bugs
> > in the future. Its also impossible for the guest to completely hide the
> > vendor range if it so chooses.
> >
> > Why not tie ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID and
> > ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID to BIT(0)? PTP would then
> > become BIT(1).
> >
> I agree it's a little asymmetrical. But exposing a bit for the
> func_ids that you mentioned means providing a capability to disable
> them by the userspace. This would block the guests from even
> discovering the space. If it's not too ugly, we can maintain certain
> bits to always remain read-only to the user-space. On the other hand,
> we can simply ignore what the userspace configure and simply treat it
> as a userspace bug. What do you think?
I think that assigning a bit to the aforementioned hypercalls would be
best. If userspace decides to hide all the features enumerated in the
subrange then there isn't much point to the guest knowing that the range
even exists. It shouldn't amount to much for userspace, as it will
likely just keep the default value and only worry about these registers
when migrating.
Apologies if I'm being pedantic, but such a subtle implementation detail
could be overlooked in future changes.
--
Oliver
> > > break;
> > > case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
> > > kvm_ptp_get_time(vcpu, val);
> > > @@ -188,6 +198,7 @@ static const u64 kvm_arm_fw_reg_ids[] = {
> > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > > KVM_REG_ARM_STD_BMAP,
> > > KVM_REG_ARM_STD_HYP_BMAP,
> > > + KVM_REG_ARM_VENDOR_HYP_BMAP,
> > > };
> > >
> > > void kvm_arm_init_hypercalls(struct kvm *kvm)
> > > @@ -196,6 +207,7 @@ void kvm_arm_init_hypercalls(struct kvm *kvm)
> > >
> > > hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
> > > hvc_desc->hvc_std_hyp_bmap = ARM_SMCCC_STD_HYP_FEATURES;
> > > + hvc_desc->hvc_vendor_hyp_bmap = ARM_SMCCC_VENDOR_HYP_FEATURES;
> > > }
> > >
> > > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> > > @@ -285,6 +297,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > case KVM_REG_ARM_STD_HYP_BMAP:
> > > val = READ_ONCE(hvc_desc->hvc_std_hyp_bmap);
> > > break;
> > > + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> > > + val = READ_ONCE(hvc_desc->hvc_vendor_hyp_bmap);
> > > + break;
> > > default:
> > > return -ENOENT;
> > > }
> > > @@ -311,6 +326,10 @@ static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
> > > fw_reg_bmap = &hvc_desc->hvc_std_hyp_bmap;
> > > fw_reg_features = ARM_SMCCC_STD_HYP_FEATURES;
> > > break;
> > > + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> > > + fw_reg_bmap = &hvc_desc->hvc_vendor_hyp_bmap;
> > > + fw_reg_features = ARM_SMCCC_VENDOR_HYP_FEATURES;
> > > + break;
> > > default:
> > > return -ENOENT;
> > > }
> > > @@ -416,6 +435,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > return 0;
> > > case KVM_REG_ARM_STD_BMAP:
> > > case KVM_REG_ARM_STD_HYP_BMAP:
> > > + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> > > return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
> > > default:
> > > return -ENOENT;
> > > diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> > > index a1cb6e839c74..91be758ca58e 100644
> > > --- a/include/kvm/arm_hypercalls.h
> > > +++ b/include/kvm/arm_hypercalls.h
> > > @@ -12,6 +12,9 @@
> > > #define ARM_SMCCC_STD_HYP_FEATURES \
> > > GENMASK_ULL(KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX, 0)
> > >
> > > +#define ARM_SMCCC_VENDOR_HYP_FEATURES \
> > > + GENMASK_ULL(KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX, 0)
> > > +
> > > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
> > >
> > > static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
> > > --
> > > 2.35.1.473.g83b2b277ed-goog
> > >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 07/13] KVM: arm64: Add vendor hypervisor firmware register
2022-03-15 6:41 ` Oliver Upton
(?)
@ 2022-03-15 17:53 ` Raghavendra Rao Ananta
-1 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-03-15 17:53 UTC (permalink / raw)
To: Oliver Upton
Cc: kvm, Will Deacon, Marc Zyngier, Peter Shier, linux-kernel,
Catalin Marinas, Paolo Bonzini, kvmarm, linux-arm-kernel
On Mon, Mar 14, 2022 at 11:41 PM Oliver Upton <oupton@google.com> wrote:
>
> On Mon, Mar 14, 2022 at 05:30:15PM -0700, Raghavendra Rao Ananta wrote:
> > On Mon, Mar 14, 2022 at 12:59 PM Oliver Upton <oupton@google.com> wrote:
> > >
> > > On Thu, Feb 24, 2022 at 05:25:53PM +0000, Raghavendra Rao Ananta wrote:
> > > > Introduce the firmware register to hold the vendor specific
> > > > hypervisor service calls (owner value 6) as a bitmap. The
> > > > bitmap represents the features that'll be enabled for the
> > > > guest, as configured by the user-space. Currently, this
> > > > includes support only for Precision Time Protocol (PTP),
> > > > represented by bit-0.
> > > >
> > > > The register is also added to the kvm_arm_vm_scope_fw_regs[]
> > > > list as it maintains its state per-VM.
> > > >
> > > > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > > > ---
> > > > arch/arm64/include/asm/kvm_host.h | 2 ++
> > > > arch/arm64/include/uapi/asm/kvm.h | 4 ++++
> > > > arch/arm64/kvm/guest.c | 1 +
> > > > arch/arm64/kvm/hypercalls.c | 22 +++++++++++++++++++++-
> > > > include/kvm/arm_hypercalls.h | 3 +++
> > > > 5 files changed, 31 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > > > index 318148b69279..d999456c4604 100644
> > > > --- a/arch/arm64/include/asm/kvm_host.h
> > > > +++ b/arch/arm64/include/asm/kvm_host.h
> > > > @@ -106,10 +106,12 @@ struct kvm_arch_memory_slot {
> > > > *
> > > > * @hvc_std_bmap: Bitmap of standard secure service calls
> > > > * @hvc_std_hyp_bmap: Bitmap of standard hypervisor service calls
> > > > + * @hvc_vendor_hyp_bmap: Bitmap of vendor specific hypervisor service calls
> > > > */
> > > > struct kvm_hvc_desc {
> > > > u64 hvc_std_bmap;
> > > > u64 hvc_std_hyp_bmap;
> > > > + u64 hvc_vendor_hyp_bmap;
> > > > };
> > > >
> > > > struct kvm_arch {
> > > > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > > > index 9a2caead7359..ed470bde13d8 100644
> > > > --- a/arch/arm64/include/uapi/asm/kvm.h
> > > > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > > > @@ -299,6 +299,10 @@ struct kvm_arm_copy_mte_tags {
> > > > #define KVM_REG_ARM_STD_HYP_BIT_PV_TIME BIT(0)
> > > > #define KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
> > > >
> > > > +#define KVM_REG_ARM_VENDOR_HYP_BMAP KVM_REG_ARM_FW_BMAP_REG(2)
> > > > +#define KVM_REG_ARM_VENDOR_HYP_BIT_PTP BIT(0)
> > > > +#define KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
> > > > +
> > > > /* SVE registers */
> > > > #define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
> > > >
> > > > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> > > > index c42426d6137e..fc3656f91aed 100644
> > > > --- a/arch/arm64/kvm/guest.c
> > > > +++ b/arch/arm64/kvm/guest.c
> > > > @@ -67,6 +67,7 @@ static const u64 kvm_arm_vm_scope_fw_regs[] = {
> > > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > > > KVM_REG_ARM_STD_BMAP,
> > > > KVM_REG_ARM_STD_HYP_BMAP,
> > > > + KVM_REG_ARM_VENDOR_HYP_BMAP,
> > > > };
> > > >
> > > > /**
> > > > diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> > > > index ebc0cc26cf2e..5c5098c8f1f9 100644
> > > > --- a/arch/arm64/kvm/hypercalls.c
> > > > +++ b/arch/arm64/kvm/hypercalls.c
> > > > @@ -79,6 +79,9 @@ static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> > > > case ARM_SMCCC_HV_PV_TIME_ST:
> > > > return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_hyp_bmap,
> > > > KVM_REG_ARM_STD_HYP_BIT_PV_TIME);
> > > > + case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
> > > > + return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_vendor_hyp_bmap,
> > > > + KVM_REG_ARM_VENDOR_HYP_BIT_PTP);
> > > > default:
> > > > /* By default, allow the services that aren't listed here */
> > > > return true;
> > > > @@ -162,7 +165,14 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > > > break;
> > > > case ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID:
> > > > val[0] = BIT(ARM_SMCCC_KVM_FUNC_FEATURES);
> > > > - val[0] |= BIT(ARM_SMCCC_KVM_FUNC_PTP);
> > > > +
> > > > + /*
> > > > + * The feature bits exposed to user-space doesn't include
> > > > + * ARM_SMCCC_KVM_FUNC_FEATURES. However, we expose this to
> > > > + * the guest as bit-0. Hence, left-shift the user-space
> > > > + * exposed bitmap by 1 to accommodate this.
> > > > + */
> > > > + val[0] |= hvc_desc->hvc_vendor_hyp_bmap << 1;
> > >
> > > Having an off-by-one difference between the userspace and guest
> > > representations of this bitmap seems like it could be a source of bugs
> > > in the future. Its also impossible for the guest to completely hide the
> > > vendor range if it so chooses.
> > >
> > > Why not tie ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID and
> > > ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID to BIT(0)? PTP would then
> > > become BIT(1).
> > >
> > I agree it's a little asymmetrical. But exposing a bit for the
> > func_ids that you mentioned means providing a capability to disable
> > them by the userspace. This would block the guests from even
> > discovering the space. If it's not too ugly, we can maintain certain
> > bits to always remain read-only to the user-space. On the other hand,
> > we can simply ignore what the userspace configure and simply treat it
> > as a userspace bug. What do you think?
>
> I think that assigning a bit to the aforementioned hypercalls would be
> best. If userspace decides to hide all the features enumerated in the
> subrange then there isn't much point to the guest knowing that the range
> even exists. It shouldn't amount to much for userspace, as it will
> likely just keep the default value and only worry about these registers
> when migrating.
>
Sure, I'll include a bit for these as well.
Thanks,
Raghavenadra
> Apologies if I'm being pedantic, but such a subtle implementation detail
> could be overlooked in future changes.
>
> --
> Oliver
>
> > > > break;
> > > > case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
> > > > kvm_ptp_get_time(vcpu, val);
> > > > @@ -188,6 +198,7 @@ static const u64 kvm_arm_fw_reg_ids[] = {
> > > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > > > KVM_REG_ARM_STD_BMAP,
> > > > KVM_REG_ARM_STD_HYP_BMAP,
> > > > + KVM_REG_ARM_VENDOR_HYP_BMAP,
> > > > };
> > > >
> > > > void kvm_arm_init_hypercalls(struct kvm *kvm)
> > > > @@ -196,6 +207,7 @@ void kvm_arm_init_hypercalls(struct kvm *kvm)
> > > >
> > > > hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
> > > > hvc_desc->hvc_std_hyp_bmap = ARM_SMCCC_STD_HYP_FEATURES;
> > > > + hvc_desc->hvc_vendor_hyp_bmap = ARM_SMCCC_VENDOR_HYP_FEATURES;
> > > > }
> > > >
> > > > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> > > > @@ -285,6 +297,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > > case KVM_REG_ARM_STD_HYP_BMAP:
> > > > val = READ_ONCE(hvc_desc->hvc_std_hyp_bmap);
> > > > break;
> > > > + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> > > > + val = READ_ONCE(hvc_desc->hvc_vendor_hyp_bmap);
> > > > + break;
> > > > default:
> > > > return -ENOENT;
> > > > }
> > > > @@ -311,6 +326,10 @@ static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
> > > > fw_reg_bmap = &hvc_desc->hvc_std_hyp_bmap;
> > > > fw_reg_features = ARM_SMCCC_STD_HYP_FEATURES;
> > > > break;
> > > > + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> > > > + fw_reg_bmap = &hvc_desc->hvc_vendor_hyp_bmap;
> > > > + fw_reg_features = ARM_SMCCC_VENDOR_HYP_FEATURES;
> > > > + break;
> > > > default:
> > > > return -ENOENT;
> > > > }
> > > > @@ -416,6 +435,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > > return 0;
> > > > case KVM_REG_ARM_STD_BMAP:
> > > > case KVM_REG_ARM_STD_HYP_BMAP:
> > > > + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> > > > return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
> > > > default:
> > > > return -ENOENT;
> > > > diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> > > > index a1cb6e839c74..91be758ca58e 100644
> > > > --- a/include/kvm/arm_hypercalls.h
> > > > +++ b/include/kvm/arm_hypercalls.h
> > > > @@ -12,6 +12,9 @@
> > > > #define ARM_SMCCC_STD_HYP_FEATURES \
> > > > GENMASK_ULL(KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX, 0)
> > > >
> > > > +#define ARM_SMCCC_VENDOR_HYP_FEATURES \
> > > > + GENMASK_ULL(KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX, 0)
> > > > +
> > > > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
> > > >
> > > > static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
> > > > --
> > > > 2.35.1.473.g83b2b277ed-goog
> > > >
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 07/13] KVM: arm64: Add vendor hypervisor firmware register
@ 2022-03-15 17:53 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-03-15 17:53 UTC (permalink / raw)
To: Oliver Upton
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Mon, Mar 14, 2022 at 11:41 PM Oliver Upton <oupton@google.com> wrote:
>
> On Mon, Mar 14, 2022 at 05:30:15PM -0700, Raghavendra Rao Ananta wrote:
> > On Mon, Mar 14, 2022 at 12:59 PM Oliver Upton <oupton@google.com> wrote:
> > >
> > > On Thu, Feb 24, 2022 at 05:25:53PM +0000, Raghavendra Rao Ananta wrote:
> > > > Introduce the firmware register to hold the vendor specific
> > > > hypervisor service calls (owner value 6) as a bitmap. The
> > > > bitmap represents the features that'll be enabled for the
> > > > guest, as configured by the user-space. Currently, this
> > > > includes support only for Precision Time Protocol (PTP),
> > > > represented by bit-0.
> > > >
> > > > The register is also added to the kvm_arm_vm_scope_fw_regs[]
> > > > list as it maintains its state per-VM.
> > > >
> > > > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > > > ---
> > > > arch/arm64/include/asm/kvm_host.h | 2 ++
> > > > arch/arm64/include/uapi/asm/kvm.h | 4 ++++
> > > > arch/arm64/kvm/guest.c | 1 +
> > > > arch/arm64/kvm/hypercalls.c | 22 +++++++++++++++++++++-
> > > > include/kvm/arm_hypercalls.h | 3 +++
> > > > 5 files changed, 31 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > > > index 318148b69279..d999456c4604 100644
> > > > --- a/arch/arm64/include/asm/kvm_host.h
> > > > +++ b/arch/arm64/include/asm/kvm_host.h
> > > > @@ -106,10 +106,12 @@ struct kvm_arch_memory_slot {
> > > > *
> > > > * @hvc_std_bmap: Bitmap of standard secure service calls
> > > > * @hvc_std_hyp_bmap: Bitmap of standard hypervisor service calls
> > > > + * @hvc_vendor_hyp_bmap: Bitmap of vendor specific hypervisor service calls
> > > > */
> > > > struct kvm_hvc_desc {
> > > > u64 hvc_std_bmap;
> > > > u64 hvc_std_hyp_bmap;
> > > > + u64 hvc_vendor_hyp_bmap;
> > > > };
> > > >
> > > > struct kvm_arch {
> > > > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > > > index 9a2caead7359..ed470bde13d8 100644
> > > > --- a/arch/arm64/include/uapi/asm/kvm.h
> > > > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > > > @@ -299,6 +299,10 @@ struct kvm_arm_copy_mte_tags {
> > > > #define KVM_REG_ARM_STD_HYP_BIT_PV_TIME BIT(0)
> > > > #define KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
> > > >
> > > > +#define KVM_REG_ARM_VENDOR_HYP_BMAP KVM_REG_ARM_FW_BMAP_REG(2)
> > > > +#define KVM_REG_ARM_VENDOR_HYP_BIT_PTP BIT(0)
> > > > +#define KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
> > > > +
> > > > /* SVE registers */
> > > > #define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
> > > >
> > > > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> > > > index c42426d6137e..fc3656f91aed 100644
> > > > --- a/arch/arm64/kvm/guest.c
> > > > +++ b/arch/arm64/kvm/guest.c
> > > > @@ -67,6 +67,7 @@ static const u64 kvm_arm_vm_scope_fw_regs[] = {
> > > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > > > KVM_REG_ARM_STD_BMAP,
> > > > KVM_REG_ARM_STD_HYP_BMAP,
> > > > + KVM_REG_ARM_VENDOR_HYP_BMAP,
> > > > };
> > > >
> > > > /**
> > > > diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> > > > index ebc0cc26cf2e..5c5098c8f1f9 100644
> > > > --- a/arch/arm64/kvm/hypercalls.c
> > > > +++ b/arch/arm64/kvm/hypercalls.c
> > > > @@ -79,6 +79,9 @@ static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> > > > case ARM_SMCCC_HV_PV_TIME_ST:
> > > > return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_hyp_bmap,
> > > > KVM_REG_ARM_STD_HYP_BIT_PV_TIME);
> > > > + case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
> > > > + return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_vendor_hyp_bmap,
> > > > + KVM_REG_ARM_VENDOR_HYP_BIT_PTP);
> > > > default:
> > > > /* By default, allow the services that aren't listed here */
> > > > return true;
> > > > @@ -162,7 +165,14 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > > > break;
> > > > case ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID:
> > > > val[0] = BIT(ARM_SMCCC_KVM_FUNC_FEATURES);
> > > > - val[0] |= BIT(ARM_SMCCC_KVM_FUNC_PTP);
> > > > +
> > > > + /*
> > > > + * The feature bits exposed to user-space doesn't include
> > > > + * ARM_SMCCC_KVM_FUNC_FEATURES. However, we expose this to
> > > > + * the guest as bit-0. Hence, left-shift the user-space
> > > > + * exposed bitmap by 1 to accommodate this.
> > > > + */
> > > > + val[0] |= hvc_desc->hvc_vendor_hyp_bmap << 1;
> > >
> > > Having an off-by-one difference between the userspace and guest
> > > representations of this bitmap seems like it could be a source of bugs
> > > in the future. Its also impossible for the guest to completely hide the
> > > vendor range if it so chooses.
> > >
> > > Why not tie ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID and
> > > ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID to BIT(0)? PTP would then
> > > become BIT(1).
> > >
> > I agree it's a little asymmetrical. But exposing a bit for the
> > func_ids that you mentioned means providing a capability to disable
> > them by the userspace. This would block the guests from even
> > discovering the space. If it's not too ugly, we can maintain certain
> > bits to always remain read-only to the user-space. On the other hand,
> > we can simply ignore what the userspace configure and simply treat it
> > as a userspace bug. What do you think?
>
> I think that assigning a bit to the aforementioned hypercalls would be
> best. If userspace decides to hide all the features enumerated in the
> subrange then there isn't much point to the guest knowing that the range
> even exists. It shouldn't amount to much for userspace, as it will
> likely just keep the default value and only worry about these registers
> when migrating.
>
Sure, I'll include a bit for these as well.
Thanks,
Raghavenadra
> Apologies if I'm being pedantic, but such a subtle implementation detail
> could be overlooked in future changes.
>
> --
> Oliver
>
> > > > break;
> > > > case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
> > > > kvm_ptp_get_time(vcpu, val);
> > > > @@ -188,6 +198,7 @@ static const u64 kvm_arm_fw_reg_ids[] = {
> > > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > > > KVM_REG_ARM_STD_BMAP,
> > > > KVM_REG_ARM_STD_HYP_BMAP,
> > > > + KVM_REG_ARM_VENDOR_HYP_BMAP,
> > > > };
> > > >
> > > > void kvm_arm_init_hypercalls(struct kvm *kvm)
> > > > @@ -196,6 +207,7 @@ void kvm_arm_init_hypercalls(struct kvm *kvm)
> > > >
> > > > hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
> > > > hvc_desc->hvc_std_hyp_bmap = ARM_SMCCC_STD_HYP_FEATURES;
> > > > + hvc_desc->hvc_vendor_hyp_bmap = ARM_SMCCC_VENDOR_HYP_FEATURES;
> > > > }
> > > >
> > > > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> > > > @@ -285,6 +297,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > > case KVM_REG_ARM_STD_HYP_BMAP:
> > > > val = READ_ONCE(hvc_desc->hvc_std_hyp_bmap);
> > > > break;
> > > > + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> > > > + val = READ_ONCE(hvc_desc->hvc_vendor_hyp_bmap);
> > > > + break;
> > > > default:
> > > > return -ENOENT;
> > > > }
> > > > @@ -311,6 +326,10 @@ static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
> > > > fw_reg_bmap = &hvc_desc->hvc_std_hyp_bmap;
> > > > fw_reg_features = ARM_SMCCC_STD_HYP_FEATURES;
> > > > break;
> > > > + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> > > > + fw_reg_bmap = &hvc_desc->hvc_vendor_hyp_bmap;
> > > > + fw_reg_features = ARM_SMCCC_VENDOR_HYP_FEATURES;
> > > > + break;
> > > > default:
> > > > return -ENOENT;
> > > > }
> > > > @@ -416,6 +435,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > > return 0;
> > > > case KVM_REG_ARM_STD_BMAP:
> > > > case KVM_REG_ARM_STD_HYP_BMAP:
> > > > + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> > > > return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
> > > > default:
> > > > return -ENOENT;
> > > > diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> > > > index a1cb6e839c74..91be758ca58e 100644
> > > > --- a/include/kvm/arm_hypercalls.h
> > > > +++ b/include/kvm/arm_hypercalls.h
> > > > @@ -12,6 +12,9 @@
> > > > #define ARM_SMCCC_STD_HYP_FEATURES \
> > > > GENMASK_ULL(KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX, 0)
> > > >
> > > > +#define ARM_SMCCC_VENDOR_HYP_FEATURES \
> > > > + GENMASK_ULL(KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX, 0)
> > > > +
> > > > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
> > > >
> > > > static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
> > > > --
> > > > 2.35.1.473.g83b2b277ed-goog
> > > >
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 07/13] KVM: arm64: Add vendor hypervisor firmware register
@ 2022-03-15 17:53 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-03-15 17:53 UTC (permalink / raw)
To: Oliver Upton
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Mon, Mar 14, 2022 at 11:41 PM Oliver Upton <oupton@google.com> wrote:
>
> On Mon, Mar 14, 2022 at 05:30:15PM -0700, Raghavendra Rao Ananta wrote:
> > On Mon, Mar 14, 2022 at 12:59 PM Oliver Upton <oupton@google.com> wrote:
> > >
> > > On Thu, Feb 24, 2022 at 05:25:53PM +0000, Raghavendra Rao Ananta wrote:
> > > > Introduce the firmware register to hold the vendor specific
> > > > hypervisor service calls (owner value 6) as a bitmap. The
> > > > bitmap represents the features that'll be enabled for the
> > > > guest, as configured by the user-space. Currently, this
> > > > includes support only for Precision Time Protocol (PTP),
> > > > represented by bit-0.
> > > >
> > > > The register is also added to the kvm_arm_vm_scope_fw_regs[]
> > > > list as it maintains its state per-VM.
> > > >
> > > > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > > > ---
> > > > arch/arm64/include/asm/kvm_host.h | 2 ++
> > > > arch/arm64/include/uapi/asm/kvm.h | 4 ++++
> > > > arch/arm64/kvm/guest.c | 1 +
> > > > arch/arm64/kvm/hypercalls.c | 22 +++++++++++++++++++++-
> > > > include/kvm/arm_hypercalls.h | 3 +++
> > > > 5 files changed, 31 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > > > index 318148b69279..d999456c4604 100644
> > > > --- a/arch/arm64/include/asm/kvm_host.h
> > > > +++ b/arch/arm64/include/asm/kvm_host.h
> > > > @@ -106,10 +106,12 @@ struct kvm_arch_memory_slot {
> > > > *
> > > > * @hvc_std_bmap: Bitmap of standard secure service calls
> > > > * @hvc_std_hyp_bmap: Bitmap of standard hypervisor service calls
> > > > + * @hvc_vendor_hyp_bmap: Bitmap of vendor specific hypervisor service calls
> > > > */
> > > > struct kvm_hvc_desc {
> > > > u64 hvc_std_bmap;
> > > > u64 hvc_std_hyp_bmap;
> > > > + u64 hvc_vendor_hyp_bmap;
> > > > };
> > > >
> > > > struct kvm_arch {
> > > > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > > > index 9a2caead7359..ed470bde13d8 100644
> > > > --- a/arch/arm64/include/uapi/asm/kvm.h
> > > > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > > > @@ -299,6 +299,10 @@ struct kvm_arm_copy_mte_tags {
> > > > #define KVM_REG_ARM_STD_HYP_BIT_PV_TIME BIT(0)
> > > > #define KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
> > > >
> > > > +#define KVM_REG_ARM_VENDOR_HYP_BMAP KVM_REG_ARM_FW_BMAP_REG(2)
> > > > +#define KVM_REG_ARM_VENDOR_HYP_BIT_PTP BIT(0)
> > > > +#define KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX 0 /* Last valid bit */
> > > > +
> > > > /* SVE registers */
> > > > #define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT)
> > > >
> > > > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> > > > index c42426d6137e..fc3656f91aed 100644
> > > > --- a/arch/arm64/kvm/guest.c
> > > > +++ b/arch/arm64/kvm/guest.c
> > > > @@ -67,6 +67,7 @@ static const u64 kvm_arm_vm_scope_fw_regs[] = {
> > > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > > > KVM_REG_ARM_STD_BMAP,
> > > > KVM_REG_ARM_STD_HYP_BMAP,
> > > > + KVM_REG_ARM_VENDOR_HYP_BMAP,
> > > > };
> > > >
> > > > /**
> > > > diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> > > > index ebc0cc26cf2e..5c5098c8f1f9 100644
> > > > --- a/arch/arm64/kvm/hypercalls.c
> > > > +++ b/arch/arm64/kvm/hypercalls.c
> > > > @@ -79,6 +79,9 @@ static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id)
> > > > case ARM_SMCCC_HV_PV_TIME_ST:
> > > > return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_hyp_bmap,
> > > > KVM_REG_ARM_STD_HYP_BIT_PV_TIME);
> > > > + case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
> > > > + return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_vendor_hyp_bmap,
> > > > + KVM_REG_ARM_VENDOR_HYP_BIT_PTP);
> > > > default:
> > > > /* By default, allow the services that aren't listed here */
> > > > return true;
> > > > @@ -162,7 +165,14 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > > > break;
> > > > case ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID:
> > > > val[0] = BIT(ARM_SMCCC_KVM_FUNC_FEATURES);
> > > > - val[0] |= BIT(ARM_SMCCC_KVM_FUNC_PTP);
> > > > +
> > > > + /*
> > > > + * The feature bits exposed to user-space doesn't include
> > > > + * ARM_SMCCC_KVM_FUNC_FEATURES. However, we expose this to
> > > > + * the guest as bit-0. Hence, left-shift the user-space
> > > > + * exposed bitmap by 1 to accommodate this.
> > > > + */
> > > > + val[0] |= hvc_desc->hvc_vendor_hyp_bmap << 1;
> > >
> > > Having an off-by-one difference between the userspace and guest
> > > representations of this bitmap seems like it could be a source of bugs
> > > in the future. Its also impossible for the guest to completely hide the
> > > vendor range if it so chooses.
> > >
> > > Why not tie ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID and
> > > ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID to BIT(0)? PTP would then
> > > become BIT(1).
> > >
> > I agree it's a little asymmetrical. But exposing a bit for the
> > func_ids that you mentioned means providing a capability to disable
> > them by the userspace. This would block the guests from even
> > discovering the space. If it's not too ugly, we can maintain certain
> > bits to always remain read-only to the user-space. On the other hand,
> > we can simply ignore what the userspace configure and simply treat it
> > as a userspace bug. What do you think?
>
> I think that assigning a bit to the aforementioned hypercalls would be
> best. If userspace decides to hide all the features enumerated in the
> subrange then there isn't much point to the guest knowing that the range
> even exists. It shouldn't amount to much for userspace, as it will
> likely just keep the default value and only worry about these registers
> when migrating.
>
Sure, I'll include a bit for these as well.
Thanks,
Raghavenadra
> Apologies if I'm being pedantic, but such a subtle implementation detail
> could be overlooked in future changes.
>
> --
> Oliver
>
> > > > break;
> > > > case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
> > > > kvm_ptp_get_time(vcpu, val);
> > > > @@ -188,6 +198,7 @@ static const u64 kvm_arm_fw_reg_ids[] = {
> > > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
> > > > KVM_REG_ARM_STD_BMAP,
> > > > KVM_REG_ARM_STD_HYP_BMAP,
> > > > + KVM_REG_ARM_VENDOR_HYP_BMAP,
> > > > };
> > > >
> > > > void kvm_arm_init_hypercalls(struct kvm *kvm)
> > > > @@ -196,6 +207,7 @@ void kvm_arm_init_hypercalls(struct kvm *kvm)
> > > >
> > > > hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES;
> > > > hvc_desc->hvc_std_hyp_bmap = ARM_SMCCC_STD_HYP_FEATURES;
> > > > + hvc_desc->hvc_vendor_hyp_bmap = ARM_SMCCC_VENDOR_HYP_FEATURES;
> > > > }
> > > >
> > > > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
> > > > @@ -285,6 +297,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > > case KVM_REG_ARM_STD_HYP_BMAP:
> > > > val = READ_ONCE(hvc_desc->hvc_std_hyp_bmap);
> > > > break;
> > > > + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> > > > + val = READ_ONCE(hvc_desc->hvc_vendor_hyp_bmap);
> > > > + break;
> > > > default:
> > > > return -ENOENT;
> > > > }
> > > > @@ -311,6 +326,10 @@ static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
> > > > fw_reg_bmap = &hvc_desc->hvc_std_hyp_bmap;
> > > > fw_reg_features = ARM_SMCCC_STD_HYP_FEATURES;
> > > > break;
> > > > + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> > > > + fw_reg_bmap = &hvc_desc->hvc_vendor_hyp_bmap;
> > > > + fw_reg_features = ARM_SMCCC_VENDOR_HYP_FEATURES;
> > > > + break;
> > > > default:
> > > > return -ENOENT;
> > > > }
> > > > @@ -416,6 +435,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> > > > return 0;
> > > > case KVM_REG_ARM_STD_BMAP:
> > > > case KVM_REG_ARM_STD_HYP_BMAP:
> > > > + case KVM_REG_ARM_VENDOR_HYP_BMAP:
> > > > return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val);
> > > > default:
> > > > return -ENOENT;
> > > > diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h
> > > > index a1cb6e839c74..91be758ca58e 100644
> > > > --- a/include/kvm/arm_hypercalls.h
> > > > +++ b/include/kvm/arm_hypercalls.h
> > > > @@ -12,6 +12,9 @@
> > > > #define ARM_SMCCC_STD_HYP_FEATURES \
> > > > GENMASK_ULL(KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX, 0)
> > > >
> > > > +#define ARM_SMCCC_VENDOR_HYP_FEATURES \
> > > > + GENMASK_ULL(KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX, 0)
> > > > +
> > > > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
> > > >
> > > > static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
> > > > --
> > > > 2.35.1.473.g83b2b277ed-goog
> > > >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 117+ messages in thread
* [PATCH v4 08/13] Docs: KVM: Add doc for the bitmap firmware registers
2022-02-24 17:25 ` Raghavendra Rao Ananta
(?)
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
-1 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: kvm, Catalin Marinas, Peter Shier, linux-kernel, Paolo Bonzini,
Will Deacon, kvmarm, linux-arm-kernel
Add the documentation for the bitmap firmware registers in
psci.rst. This includes the details for KVM_REG_ARM_STD_BMAP,
KVM_REG_ARM_STD_HYP_BMAP, and KVM_REG_ARM_VENDOR_HYP_BMAP
registers.
Since the document is growing to carry other hypercall related
information, make necessary adjustments to present the document
in a generic sense, rather than being PSCI focused.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
Documentation/virt/kvm/arm/psci.rst | 83 ++++++++++++++++++++++-------
1 file changed, 65 insertions(+), 18 deletions(-)
diff --git a/Documentation/virt/kvm/arm/psci.rst b/Documentation/virt/kvm/arm/psci.rst
index d52c2e83b5b8..bc5c2886ca23 100644
--- a/Documentation/virt/kvm/arm/psci.rst
+++ b/Documentation/virt/kvm/arm/psci.rst
@@ -1,32 +1,32 @@
.. SPDX-License-Identifier: GPL-2.0
-=========================================
-Power State Coordination Interface (PSCI)
-=========================================
+=======================
+ARM Hypercall Interface
+=======================
-KVM implements the PSCI (Power State Coordination Interface)
-specification in order to provide services such as CPU on/off, reset
-and power-off to the guest.
+KVM handles the hypercall services as requested by the guests. New hypercall
+services are regularly made available by the ARM specification or by KVM (as
+vendor services) if they make sense from a virtualization point of view.
-The PSCI specification is regularly updated to provide new features,
-and KVM implements these updates if they make sense from a virtualization
-point of view.
-
-This means that a guest booted on two different versions of KVM can
-observe two different "firmware" revisions. This could cause issues if
-a given guest is tied to a particular PSCI revision (unlikely), or if
-a migration causes a different PSCI version to be exposed out of the
-blue to an unsuspecting guest.
+This means that a guest booted on two different versions of KVM can observe
+two different "firmware" revisions. This could cause issues if a given guest
+is tied to a particular version of a hypercall service, or if a migration
+causes a different version to be exposed out of the blue to an unsuspecting
+guest.
In order to remedy this situation, KVM exposes a set of "firmware
pseudo-registers" that can be manipulated using the GET/SET_ONE_REG
interface. These registers can be saved/restored by userspace, and set
-to a convenient value if required.
+to a convenient value as required.
-The following register is defined:
+The following registers are defined:
* KVM_REG_ARM_PSCI_VERSION:
+ KVM implements the PSCI (Power State Coordination Interface)
+ specification in order to provide services such as CPU on/off, reset
+ and power-off to the guest.
+
- Only valid if the vcpu has the KVM_ARM_VCPU_PSCI_0_2 feature set
(and thus has already been initialized)
- Returns the current PSCI version on GET_ONE_REG (defaulting to the
@@ -74,4 +74,51 @@ The following register is defined:
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED:
The workaround is always active on this vCPU or it is not needed.
-.. [1] https://developer.arm.com/-/media/developer/pdf/ARM_DEN_0070A_Firmware_interfaces_for_mitigating_CVE-2017-5715.pdf
+Contrary to the above registers, the following registers exposes the hypercall
+services in the form of a feature-bitmap. This bitmap is translated to the
+services that are exposed to the guest. There is a register defined per service
+call owner and can be accessed via GET/SET_ONE_REG interface.
+
+By default, these registers are set with the upper limit of the features that
+are supported. User-space can discover this configuration via GET_ONE_REG. If
+unsatisfied, the user-space can write back the desired bitmap back via
+SET_ONE_REG. The features for the registers that are untouched, probably because
+userspace isn't aware of them, will be exposed as is to the guest.
+
+The psuedo-firmware bitmap register are as follows:
+
+* KVM_REG_ARM_STD_BMAP:
+ Controls the bitmap of the ARM Standard Secure Service Calls.
+
+ The following bits are accepted:
+
+ KVM_REG_ARM_STD_BIT_TRNG_V1_0:
+ The bit represents the services offered under v1.0 of ARM True Random
+ Number Generator (TRNG) specification, ARM DEN0098.
+
+* KVM_REG_ARM_STD_HYP_BMAP:
+ Controls the bitmap of the ARM Standard Hypervisor Service Calls.
+
+ The following bits are accepted:
+
+ KVM_REG_ARM_STD_HYP_BIT_PV_TIME:
+ The bit represents the Paravirtualized Time service as represented by
+ ARM DEN0057A.
+
+* KVM_REG_ARM_VENDOR_HYP_BMAP:
+ Controls the bitmap of the Vendor specific Hypervisor Service Calls.
+
+ The following bits are accepted:
+
+ KVM_REG_ARM_VENDOR_HYP_BIT_PTP:
+ The bit represents the Precision Time Protocol KVM service.
+
+Errors:
+
+ ======= =============================================================
+ -ENOENT Unknown register accessed.
+ -EBUSY Attempt a 'write' to the register after the VM has started.
+ -EINVAL Invalid bitmap written to the register.
+ ======= =============================================================
+
+.. [1] https://developer.arm.com/-/media/developer/pdf/ARM_DEN_0070A_Firmware_interfaces_for_mitigating_CVE-2017-5715.pdf
\ No newline at end of file
--
2.35.1.473.g83b2b277ed-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 117+ messages in thread* [PATCH v4 08/13] Docs: KVM: Add doc for the bitmap firmware registers
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: Paolo Bonzini, Catalin Marinas, Will Deacon, Peter Shier,
Ricardo Koller, Oliver Upton, Reiji Watanabe, Jing Zhang,
Raghavendra Rao Anata, linux-arm-kernel, kvmarm, linux-kernel,
kvm
Add the documentation for the bitmap firmware registers in
psci.rst. This includes the details for KVM_REG_ARM_STD_BMAP,
KVM_REG_ARM_STD_HYP_BMAP, and KVM_REG_ARM_VENDOR_HYP_BMAP
registers.
Since the document is growing to carry other hypercall related
information, make necessary adjustments to present the document
in a generic sense, rather than being PSCI focused.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
Documentation/virt/kvm/arm/psci.rst | 83 ++++++++++++++++++++++-------
1 file changed, 65 insertions(+), 18 deletions(-)
diff --git a/Documentation/virt/kvm/arm/psci.rst b/Documentation/virt/kvm/arm/psci.rst
index d52c2e83b5b8..bc5c2886ca23 100644
--- a/Documentation/virt/kvm/arm/psci.rst
+++ b/Documentation/virt/kvm/arm/psci.rst
@@ -1,32 +1,32 @@
.. SPDX-License-Identifier: GPL-2.0
-=========================================
-Power State Coordination Interface (PSCI)
-=========================================
+=======================
+ARM Hypercall Interface
+=======================
-KVM implements the PSCI (Power State Coordination Interface)
-specification in order to provide services such as CPU on/off, reset
-and power-off to the guest.
+KVM handles the hypercall services as requested by the guests. New hypercall
+services are regularly made available by the ARM specification or by KVM (as
+vendor services) if they make sense from a virtualization point of view.
-The PSCI specification is regularly updated to provide new features,
-and KVM implements these updates if they make sense from a virtualization
-point of view.
-
-This means that a guest booted on two different versions of KVM can
-observe two different "firmware" revisions. This could cause issues if
-a given guest is tied to a particular PSCI revision (unlikely), or if
-a migration causes a different PSCI version to be exposed out of the
-blue to an unsuspecting guest.
+This means that a guest booted on two different versions of KVM can observe
+two different "firmware" revisions. This could cause issues if a given guest
+is tied to a particular version of a hypercall service, or if a migration
+causes a different version to be exposed out of the blue to an unsuspecting
+guest.
In order to remedy this situation, KVM exposes a set of "firmware
pseudo-registers" that can be manipulated using the GET/SET_ONE_REG
interface. These registers can be saved/restored by userspace, and set
-to a convenient value if required.
+to a convenient value as required.
-The following register is defined:
+The following registers are defined:
* KVM_REG_ARM_PSCI_VERSION:
+ KVM implements the PSCI (Power State Coordination Interface)
+ specification in order to provide services such as CPU on/off, reset
+ and power-off to the guest.
+
- Only valid if the vcpu has the KVM_ARM_VCPU_PSCI_0_2 feature set
(and thus has already been initialized)
- Returns the current PSCI version on GET_ONE_REG (defaulting to the
@@ -74,4 +74,51 @@ The following register is defined:
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED:
The workaround is always active on this vCPU or it is not needed.
-.. [1] https://developer.arm.com/-/media/developer/pdf/ARM_DEN_0070A_Firmware_interfaces_for_mitigating_CVE-2017-5715.pdf
+Contrary to the above registers, the following registers exposes the hypercall
+services in the form of a feature-bitmap. This bitmap is translated to the
+services that are exposed to the guest. There is a register defined per service
+call owner and can be accessed via GET/SET_ONE_REG interface.
+
+By default, these registers are set with the upper limit of the features that
+are supported. User-space can discover this configuration via GET_ONE_REG. If
+unsatisfied, the user-space can write back the desired bitmap back via
+SET_ONE_REG. The features for the registers that are untouched, probably because
+userspace isn't aware of them, will be exposed as is to the guest.
+
+The psuedo-firmware bitmap register are as follows:
+
+* KVM_REG_ARM_STD_BMAP:
+ Controls the bitmap of the ARM Standard Secure Service Calls.
+
+ The following bits are accepted:
+
+ KVM_REG_ARM_STD_BIT_TRNG_V1_0:
+ The bit represents the services offered under v1.0 of ARM True Random
+ Number Generator (TRNG) specification, ARM DEN0098.
+
+* KVM_REG_ARM_STD_HYP_BMAP:
+ Controls the bitmap of the ARM Standard Hypervisor Service Calls.
+
+ The following bits are accepted:
+
+ KVM_REG_ARM_STD_HYP_BIT_PV_TIME:
+ The bit represents the Paravirtualized Time service as represented by
+ ARM DEN0057A.
+
+* KVM_REG_ARM_VENDOR_HYP_BMAP:
+ Controls the bitmap of the Vendor specific Hypervisor Service Calls.
+
+ The following bits are accepted:
+
+ KVM_REG_ARM_VENDOR_HYP_BIT_PTP:
+ The bit represents the Precision Time Protocol KVM service.
+
+Errors:
+
+ ======= =============================================================
+ -ENOENT Unknown register accessed.
+ -EBUSY Attempt a 'write' to the register after the VM has started.
+ -EINVAL Invalid bitmap written to the register.
+ ======= =============================================================
+
+.. [1] https://developer.arm.com/-/media/developer/pdf/ARM_DEN_0070A_Firmware_interfaces_for_mitigating_CVE-2017-5715.pdf
\ No newline at end of file
--
2.35.1.473.g83b2b277ed-goog
^ permalink raw reply related [flat|nested] 117+ messages in thread* [PATCH v4 08/13] Docs: KVM: Add doc for the bitmap firmware registers
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: Paolo Bonzini, Catalin Marinas, Will Deacon, Peter Shier,
Ricardo Koller, Oliver Upton, Reiji Watanabe, Jing Zhang,
Raghavendra Rao Anata, linux-arm-kernel, kvmarm, linux-kernel,
kvm
Add the documentation for the bitmap firmware registers in
psci.rst. This includes the details for KVM_REG_ARM_STD_BMAP,
KVM_REG_ARM_STD_HYP_BMAP, and KVM_REG_ARM_VENDOR_HYP_BMAP
registers.
Since the document is growing to carry other hypercall related
information, make necessary adjustments to present the document
in a generic sense, rather than being PSCI focused.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
Documentation/virt/kvm/arm/psci.rst | 83 ++++++++++++++++++++++-------
1 file changed, 65 insertions(+), 18 deletions(-)
diff --git a/Documentation/virt/kvm/arm/psci.rst b/Documentation/virt/kvm/arm/psci.rst
index d52c2e83b5b8..bc5c2886ca23 100644
--- a/Documentation/virt/kvm/arm/psci.rst
+++ b/Documentation/virt/kvm/arm/psci.rst
@@ -1,32 +1,32 @@
.. SPDX-License-Identifier: GPL-2.0
-=========================================
-Power State Coordination Interface (PSCI)
-=========================================
+=======================
+ARM Hypercall Interface
+=======================
-KVM implements the PSCI (Power State Coordination Interface)
-specification in order to provide services such as CPU on/off, reset
-and power-off to the guest.
+KVM handles the hypercall services as requested by the guests. New hypercall
+services are regularly made available by the ARM specification or by KVM (as
+vendor services) if they make sense from a virtualization point of view.
-The PSCI specification is regularly updated to provide new features,
-and KVM implements these updates if they make sense from a virtualization
-point of view.
-
-This means that a guest booted on two different versions of KVM can
-observe two different "firmware" revisions. This could cause issues if
-a given guest is tied to a particular PSCI revision (unlikely), or if
-a migration causes a different PSCI version to be exposed out of the
-blue to an unsuspecting guest.
+This means that a guest booted on two different versions of KVM can observe
+two different "firmware" revisions. This could cause issues if a given guest
+is tied to a particular version of a hypercall service, or if a migration
+causes a different version to be exposed out of the blue to an unsuspecting
+guest.
In order to remedy this situation, KVM exposes a set of "firmware
pseudo-registers" that can be manipulated using the GET/SET_ONE_REG
interface. These registers can be saved/restored by userspace, and set
-to a convenient value if required.
+to a convenient value as required.
-The following register is defined:
+The following registers are defined:
* KVM_REG_ARM_PSCI_VERSION:
+ KVM implements the PSCI (Power State Coordination Interface)
+ specification in order to provide services such as CPU on/off, reset
+ and power-off to the guest.
+
- Only valid if the vcpu has the KVM_ARM_VCPU_PSCI_0_2 feature set
(and thus has already been initialized)
- Returns the current PSCI version on GET_ONE_REG (defaulting to the
@@ -74,4 +74,51 @@ The following register is defined:
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED:
The workaround is always active on this vCPU or it is not needed.
-.. [1] https://developer.arm.com/-/media/developer/pdf/ARM_DEN_0070A_Firmware_interfaces_for_mitigating_CVE-2017-5715.pdf
+Contrary to the above registers, the following registers exposes the hypercall
+services in the form of a feature-bitmap. This bitmap is translated to the
+services that are exposed to the guest. There is a register defined per service
+call owner and can be accessed via GET/SET_ONE_REG interface.
+
+By default, these registers are set with the upper limit of the features that
+are supported. User-space can discover this configuration via GET_ONE_REG. If
+unsatisfied, the user-space can write back the desired bitmap back via
+SET_ONE_REG. The features for the registers that are untouched, probably because
+userspace isn't aware of them, will be exposed as is to the guest.
+
+The psuedo-firmware bitmap register are as follows:
+
+* KVM_REG_ARM_STD_BMAP:
+ Controls the bitmap of the ARM Standard Secure Service Calls.
+
+ The following bits are accepted:
+
+ KVM_REG_ARM_STD_BIT_TRNG_V1_0:
+ The bit represents the services offered under v1.0 of ARM True Random
+ Number Generator (TRNG) specification, ARM DEN0098.
+
+* KVM_REG_ARM_STD_HYP_BMAP:
+ Controls the bitmap of the ARM Standard Hypervisor Service Calls.
+
+ The following bits are accepted:
+
+ KVM_REG_ARM_STD_HYP_BIT_PV_TIME:
+ The bit represents the Paravirtualized Time service as represented by
+ ARM DEN0057A.
+
+* KVM_REG_ARM_VENDOR_HYP_BMAP:
+ Controls the bitmap of the Vendor specific Hypervisor Service Calls.
+
+ The following bits are accepted:
+
+ KVM_REG_ARM_VENDOR_HYP_BIT_PTP:
+ The bit represents the Precision Time Protocol KVM service.
+
+Errors:
+
+ ======= =============================================================
+ -ENOENT Unknown register accessed.
+ -EBUSY Attempt a 'write' to the register after the VM has started.
+ -EINVAL Invalid bitmap written to the register.
+ ======= =============================================================
+
+.. [1] https://developer.arm.com/-/media/developer/pdf/ARM_DEN_0070A_Firmware_interfaces_for_mitigating_CVE-2017-5715.pdf
\ No newline at end of file
--
2.35.1.473.g83b2b277ed-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 117+ messages in thread
* [PATCH v4 09/13] Docs: KVM: Rename psci.rst to hypercalls.rst
2022-02-24 17:25 ` Raghavendra Rao Ananta
(?)
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
-1 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: kvm, Catalin Marinas, Peter Shier, linux-kernel, Paolo Bonzini,
Will Deacon, kvmarm, linux-arm-kernel
Since the doc now covers more of general hypercalls'
details, rather than just PSCI, rename the file to a
more appropriate name- hypercalls.rst.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
Documentation/virt/kvm/arm/{psci.rst => hypercalls.rst} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/virt/kvm/arm/{psci.rst => hypercalls.rst} (100%)
diff --git a/Documentation/virt/kvm/arm/psci.rst b/Documentation/virt/kvm/arm/hypercalls.rst
similarity index 100%
rename from Documentation/virt/kvm/arm/psci.rst
rename to Documentation/virt/kvm/arm/hypercalls.rst
--
2.35.1.473.g83b2b277ed-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 117+ messages in thread* [PATCH v4 09/13] Docs: KVM: Rename psci.rst to hypercalls.rst
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: Paolo Bonzini, Catalin Marinas, Will Deacon, Peter Shier,
Ricardo Koller, Oliver Upton, Reiji Watanabe, Jing Zhang,
Raghavendra Rao Anata, linux-arm-kernel, kvmarm, linux-kernel,
kvm
Since the doc now covers more of general hypercalls'
details, rather than just PSCI, rename the file to a
more appropriate name- hypercalls.rst.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
Documentation/virt/kvm/arm/{psci.rst => hypercalls.rst} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/virt/kvm/arm/{psci.rst => hypercalls.rst} (100%)
diff --git a/Documentation/virt/kvm/arm/psci.rst b/Documentation/virt/kvm/arm/hypercalls.rst
similarity index 100%
rename from Documentation/virt/kvm/arm/psci.rst
rename to Documentation/virt/kvm/arm/hypercalls.rst
--
2.35.1.473.g83b2b277ed-goog
^ permalink raw reply [flat|nested] 117+ messages in thread* [PATCH v4 09/13] Docs: KVM: Rename psci.rst to hypercalls.rst
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: Paolo Bonzini, Catalin Marinas, Will Deacon, Peter Shier,
Ricardo Koller, Oliver Upton, Reiji Watanabe, Jing Zhang,
Raghavendra Rao Anata, linux-arm-kernel, kvmarm, linux-kernel,
kvm
Since the doc now covers more of general hypercalls'
details, rather than just PSCI, rename the file to a
more appropriate name- hypercalls.rst.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
Documentation/virt/kvm/arm/{psci.rst => hypercalls.rst} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/virt/kvm/arm/{psci.rst => hypercalls.rst} (100%)
diff --git a/Documentation/virt/kvm/arm/psci.rst b/Documentation/virt/kvm/arm/hypercalls.rst
similarity index 100%
rename from Documentation/virt/kvm/arm/psci.rst
rename to Documentation/virt/kvm/arm/hypercalls.rst
--
2.35.1.473.g83b2b277ed-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 09/13] Docs: KVM: Rename psci.rst to hypercalls.rst
2022-02-24 17:25 ` Raghavendra Rao Ananta
(?)
@ 2022-03-14 20:01 ` Oliver Upton
-1 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-14 20:01 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: kvm, Will Deacon, Marc Zyngier, Peter Shier, linux-kernel,
Catalin Marinas, Paolo Bonzini, kvmarm, linux-arm-kernel
On Thu, Feb 24, 2022 at 05:25:55PM +0000, Raghavendra Rao Ananta wrote:
> Since the doc now covers more of general hypercalls'
> details, rather than just PSCI, rename the file to a
> more appropriate name- hypercalls.rst.
>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
You should move the file before adding to it IMO (switch this patch with
the previous one).
Reviewed-by: Oliver Upton <oupton@google.com>
> ---
> Documentation/virt/kvm/arm/{psci.rst => hypercalls.rst} | 0
> 1 file changed, 0 insertions(+), 0 deletions(-)
> rename Documentation/virt/kvm/arm/{psci.rst => hypercalls.rst} (100%)
>
> diff --git a/Documentation/virt/kvm/arm/psci.rst b/Documentation/virt/kvm/arm/hypercalls.rst
> similarity index 100%
> rename from Documentation/virt/kvm/arm/psci.rst
> rename to Documentation/virt/kvm/arm/hypercalls.rst
> --
> 2.35.1.473.g83b2b277ed-goog
>
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 09/13] Docs: KVM: Rename psci.rst to hypercalls.rst
@ 2022-03-14 20:01 ` Oliver Upton
0 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-14 20:01 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Thu, Feb 24, 2022 at 05:25:55PM +0000, Raghavendra Rao Ananta wrote:
> Since the doc now covers more of general hypercalls'
> details, rather than just PSCI, rename the file to a
> more appropriate name- hypercalls.rst.
>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
You should move the file before adding to it IMO (switch this patch with
the previous one).
Reviewed-by: Oliver Upton <oupton@google.com>
> ---
> Documentation/virt/kvm/arm/{psci.rst => hypercalls.rst} | 0
> 1 file changed, 0 insertions(+), 0 deletions(-)
> rename Documentation/virt/kvm/arm/{psci.rst => hypercalls.rst} (100%)
>
> diff --git a/Documentation/virt/kvm/arm/psci.rst b/Documentation/virt/kvm/arm/hypercalls.rst
> similarity index 100%
> rename from Documentation/virt/kvm/arm/psci.rst
> rename to Documentation/virt/kvm/arm/hypercalls.rst
> --
> 2.35.1.473.g83b2b277ed-goog
>
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 09/13] Docs: KVM: Rename psci.rst to hypercalls.rst
@ 2022-03-14 20:01 ` Oliver Upton
0 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-14 20:01 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Thu, Feb 24, 2022 at 05:25:55PM +0000, Raghavendra Rao Ananta wrote:
> Since the doc now covers more of general hypercalls'
> details, rather than just PSCI, rename the file to a
> more appropriate name- hypercalls.rst.
>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
You should move the file before adding to it IMO (switch this patch with
the previous one).
Reviewed-by: Oliver Upton <oupton@google.com>
> ---
> Documentation/virt/kvm/arm/{psci.rst => hypercalls.rst} | 0
> 1 file changed, 0 insertions(+), 0 deletions(-)
> rename Documentation/virt/kvm/arm/{psci.rst => hypercalls.rst} (100%)
>
> diff --git a/Documentation/virt/kvm/arm/psci.rst b/Documentation/virt/kvm/arm/hypercalls.rst
> similarity index 100%
> rename from Documentation/virt/kvm/arm/psci.rst
> rename to Documentation/virt/kvm/arm/hypercalls.rst
> --
> 2.35.1.473.g83b2b277ed-goog
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 09/13] Docs: KVM: Rename psci.rst to hypercalls.rst
2022-03-14 20:01 ` Oliver Upton
(?)
@ 2022-03-15 0:31 ` Raghavendra Rao Ananta
-1 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-03-15 0:31 UTC (permalink / raw)
To: Oliver Upton
Cc: kvm, Will Deacon, Marc Zyngier, Peter Shier, linux-kernel,
Catalin Marinas, Paolo Bonzini, kvmarm, linux-arm-kernel
On Mon, Mar 14, 2022 at 1:02 PM Oliver Upton <oupton@google.com> wrote:
>
> On Thu, Feb 24, 2022 at 05:25:55PM +0000, Raghavendra Rao Ananta wrote:
> > Since the doc now covers more of general hypercalls'
> > details, rather than just PSCI, rename the file to a
> > more appropriate name- hypercalls.rst.
> >
> > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
>
> You should move the file before adding to it IMO (switch this patch with
> the previous one).
>
Sure, I can do that.
Regards,
Raghavendra
> Reviewed-by: Oliver Upton <oupton@google.com>
>
> > ---
> > Documentation/virt/kvm/arm/{psci.rst => hypercalls.rst} | 0
> > 1 file changed, 0 insertions(+), 0 deletions(-)
> > rename Documentation/virt/kvm/arm/{psci.rst => hypercalls.rst} (100%)
> >
> > diff --git a/Documentation/virt/kvm/arm/psci.rst b/Documentation/virt/kvm/arm/hypercalls.rst
> > similarity index 100%
> > rename from Documentation/virt/kvm/arm/psci.rst
> > rename to Documentation/virt/kvm/arm/hypercalls.rst
> > --
> > 2.35.1.473.g83b2b277ed-goog
> >
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 09/13] Docs: KVM: Rename psci.rst to hypercalls.rst
@ 2022-03-15 0:31 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-03-15 0:31 UTC (permalink / raw)
To: Oliver Upton
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Mon, Mar 14, 2022 at 1:02 PM Oliver Upton <oupton@google.com> wrote:
>
> On Thu, Feb 24, 2022 at 05:25:55PM +0000, Raghavendra Rao Ananta wrote:
> > Since the doc now covers more of general hypercalls'
> > details, rather than just PSCI, rename the file to a
> > more appropriate name- hypercalls.rst.
> >
> > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
>
> You should move the file before adding to it IMO (switch this patch with
> the previous one).
>
Sure, I can do that.
Regards,
Raghavendra
> Reviewed-by: Oliver Upton <oupton@google.com>
>
> > ---
> > Documentation/virt/kvm/arm/{psci.rst => hypercalls.rst} | 0
> > 1 file changed, 0 insertions(+), 0 deletions(-)
> > rename Documentation/virt/kvm/arm/{psci.rst => hypercalls.rst} (100%)
> >
> > diff --git a/Documentation/virt/kvm/arm/psci.rst b/Documentation/virt/kvm/arm/hypercalls.rst
> > similarity index 100%
> > rename from Documentation/virt/kvm/arm/psci.rst
> > rename to Documentation/virt/kvm/arm/hypercalls.rst
> > --
> > 2.35.1.473.g83b2b277ed-goog
> >
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 09/13] Docs: KVM: Rename psci.rst to hypercalls.rst
@ 2022-03-15 0:31 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-03-15 0:31 UTC (permalink / raw)
To: Oliver Upton
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Mon, Mar 14, 2022 at 1:02 PM Oliver Upton <oupton@google.com> wrote:
>
> On Thu, Feb 24, 2022 at 05:25:55PM +0000, Raghavendra Rao Ananta wrote:
> > Since the doc now covers more of general hypercalls'
> > details, rather than just PSCI, rename the file to a
> > more appropriate name- hypercalls.rst.
> >
> > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
>
> You should move the file before adding to it IMO (switch this patch with
> the previous one).
>
Sure, I can do that.
Regards,
Raghavendra
> Reviewed-by: Oliver Upton <oupton@google.com>
>
> > ---
> > Documentation/virt/kvm/arm/{psci.rst => hypercalls.rst} | 0
> > 1 file changed, 0 insertions(+), 0 deletions(-)
> > rename Documentation/virt/kvm/arm/{psci.rst => hypercalls.rst} (100%)
> >
> > diff --git a/Documentation/virt/kvm/arm/psci.rst b/Documentation/virt/kvm/arm/hypercalls.rst
> > similarity index 100%
> > rename from Documentation/virt/kvm/arm/psci.rst
> > rename to Documentation/virt/kvm/arm/hypercalls.rst
> > --
> > 2.35.1.473.g83b2b277ed-goog
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 117+ messages in thread
* [PATCH v4 10/13] tools: Import ARM SMCCC definitions
2022-02-24 17:25 ` Raghavendra Rao Ananta
(?)
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
-1 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: kvm, Catalin Marinas, Peter Shier, linux-kernel, Paolo Bonzini,
Will Deacon, kvmarm, linux-arm-kernel
Import the standard SMCCC definitions from include/linux/arm-smccc.h.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
tools/include/linux/arm-smccc.h | 188 ++++++++++++++++++++++++++++++++
1 file changed, 188 insertions(+)
create mode 100644 tools/include/linux/arm-smccc.h
diff --git a/tools/include/linux/arm-smccc.h b/tools/include/linux/arm-smccc.h
new file mode 100644
index 000000000000..a11c0bbabd5b
--- /dev/null
+++ b/tools/include/linux/arm-smccc.h
@@ -0,0 +1,188 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2015, Linaro Limited
+ */
+#ifndef __LINUX_ARM_SMCCC_H
+#define __LINUX_ARM_SMCCC_H
+
+#include <linux/const.h>
+
+/*
+ * This file provides common defines for ARM SMC Calling Convention as
+ * specified in
+ * https://developer.arm.com/docs/den0028/latest
+ *
+ * This code is up-to-date with version DEN 0028 C
+ */
+
+#define ARM_SMCCC_STD_CALL _AC(0,U)
+#define ARM_SMCCC_FAST_CALL _AC(1,U)
+#define ARM_SMCCC_TYPE_SHIFT 31
+
+#define ARM_SMCCC_SMC_32 0
+#define ARM_SMCCC_SMC_64 1
+#define ARM_SMCCC_CALL_CONV_SHIFT 30
+
+#define ARM_SMCCC_OWNER_MASK 0x3F
+#define ARM_SMCCC_OWNER_SHIFT 24
+
+#define ARM_SMCCC_FUNC_MASK 0xFFFF
+
+#define ARM_SMCCC_IS_FAST_CALL(smc_val) \
+ ((smc_val) & (ARM_SMCCC_FAST_CALL << ARM_SMCCC_TYPE_SHIFT))
+#define ARM_SMCCC_IS_64(smc_val) \
+ ((smc_val) & (ARM_SMCCC_SMC_64 << ARM_SMCCC_CALL_CONV_SHIFT))
+#define ARM_SMCCC_FUNC_NUM(smc_val) ((smc_val) & ARM_SMCCC_FUNC_MASK)
+#define ARM_SMCCC_OWNER_NUM(smc_val) \
+ (((smc_val) >> ARM_SMCCC_OWNER_SHIFT) & ARM_SMCCC_OWNER_MASK)
+
+#define ARM_SMCCC_CALL_VAL(type, calling_convention, owner, func_num) \
+ (((type) << ARM_SMCCC_TYPE_SHIFT) | \
+ ((calling_convention) << ARM_SMCCC_CALL_CONV_SHIFT) | \
+ (((owner) & ARM_SMCCC_OWNER_MASK) << ARM_SMCCC_OWNER_SHIFT) | \
+ ((func_num) & ARM_SMCCC_FUNC_MASK))
+
+#define ARM_SMCCC_OWNER_ARCH 0
+#define ARM_SMCCC_OWNER_CPU 1
+#define ARM_SMCCC_OWNER_SIP 2
+#define ARM_SMCCC_OWNER_OEM 3
+#define ARM_SMCCC_OWNER_STANDARD 4
+#define ARM_SMCCC_OWNER_STANDARD_HYP 5
+#define ARM_SMCCC_OWNER_VENDOR_HYP 6
+#define ARM_SMCCC_OWNER_TRUSTED_APP 48
+#define ARM_SMCCC_OWNER_TRUSTED_APP_END 49
+#define ARM_SMCCC_OWNER_TRUSTED_OS 50
+#define ARM_SMCCC_OWNER_TRUSTED_OS_END 63
+
+#define ARM_SMCCC_FUNC_QUERY_CALL_UID 0xff01
+
+#define ARM_SMCCC_QUIRK_NONE 0
+#define ARM_SMCCC_QUIRK_QCOM_A6 1 /* Save/restore register a6 */
+
+#define ARM_SMCCC_VERSION_1_0 0x10000
+#define ARM_SMCCC_VERSION_1_1 0x10001
+#define ARM_SMCCC_VERSION_1_2 0x10002
+#define ARM_SMCCC_VERSION_1_3 0x10003
+
+#define ARM_SMCCC_1_3_SVE_HINT 0x10000
+
+#define ARM_SMCCC_VERSION_FUNC_ID \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ 0, 0)
+
+#define ARM_SMCCC_ARCH_FEATURES_FUNC_ID \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ 0, 1)
+
+#define ARM_SMCCC_ARCH_SOC_ID \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ 0, 2)
+
+#define ARM_SMCCC_ARCH_WORKAROUND_1 \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ 0, 0x8000)
+
+#define ARM_SMCCC_ARCH_WORKAROUND_2 \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ 0, 0x7fff)
+
+#define ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ ARM_SMCCC_OWNER_VENDOR_HYP, \
+ ARM_SMCCC_FUNC_QUERY_CALL_UID)
+
+/* KVM UID value: 28b46fb6-2ec5-11e9-a9ca-4b564d003a74 */
+#define ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_0 0xb66fb428U
+#define ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_1 0xe911c52eU
+#define ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_2 0x564bcaa9U
+#define ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_3 0x743a004dU
+
+/* KVM "vendor specific" services */
+#define ARM_SMCCC_KVM_FUNC_FEATURES 0
+#define ARM_SMCCC_KVM_FUNC_PTP 1
+#define ARM_SMCCC_KVM_FUNC_FEATURES_2 127
+#define ARM_SMCCC_KVM_NUM_FUNCS 128
+
+#define ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ ARM_SMCCC_OWNER_VENDOR_HYP, \
+ ARM_SMCCC_KVM_FUNC_FEATURES)
+
+#define SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED 1
+
+/*
+ * ptp_kvm is a feature used for time sync between vm and host.
+ * ptp_kvm module in guest kernel will get service from host using
+ * this hypercall ID.
+ */
+#define ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ ARM_SMCCC_OWNER_VENDOR_HYP, \
+ ARM_SMCCC_KVM_FUNC_PTP)
+
+/* ptp_kvm counter type ID */
+#define KVM_PTP_VIRT_COUNTER 0
+#define KVM_PTP_PHYS_COUNTER 1
+
+/* Paravirtualised time calls (defined by ARM DEN0057A) */
+#define ARM_SMCCC_HV_PV_TIME_FEATURES \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_64, \
+ ARM_SMCCC_OWNER_STANDARD_HYP, \
+ 0x20)
+
+#define ARM_SMCCC_HV_PV_TIME_ST \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_64, \
+ ARM_SMCCC_OWNER_STANDARD_HYP, \
+ 0x21)
+
+/* TRNG entropy source calls (defined by ARM DEN0098) */
+#define ARM_SMCCC_TRNG_VERSION \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ ARM_SMCCC_OWNER_STANDARD, \
+ 0x50)
+
+#define ARM_SMCCC_TRNG_FEATURES \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ ARM_SMCCC_OWNER_STANDARD, \
+ 0x51)
+
+#define ARM_SMCCC_TRNG_GET_UUID \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ ARM_SMCCC_OWNER_STANDARD, \
+ 0x52)
+
+#define ARM_SMCCC_TRNG_RND32 \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ ARM_SMCCC_OWNER_STANDARD, \
+ 0x53)
+
+#define ARM_SMCCC_TRNG_RND64 \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_64, \
+ ARM_SMCCC_OWNER_STANDARD, \
+ 0x53)
+
+/*
+ * Return codes defined in ARM DEN 0070A
+ * ARM DEN 0070A is now merged/consolidated into ARM DEN 0028 C
+ */
+#define SMCCC_RET_SUCCESS 0
+#define SMCCC_RET_NOT_SUPPORTED -1
+#define SMCCC_RET_NOT_REQUIRED -2
+#define SMCCC_RET_INVALID_PARAMETER -3
+
+#endif /*__LINUX_ARM_SMCCC_H*/
--
2.35.1.473.g83b2b277ed-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 117+ messages in thread
* [PATCH v4 10/13] tools: Import ARM SMCCC definitions
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: Paolo Bonzini, Catalin Marinas, Will Deacon, Peter Shier,
Ricardo Koller, Oliver Upton, Reiji Watanabe, Jing Zhang,
Raghavendra Rao Anata, linux-arm-kernel, kvmarm, linux-kernel,
kvm
Import the standard SMCCC definitions from include/linux/arm-smccc.h.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
tools/include/linux/arm-smccc.h | 188 ++++++++++++++++++++++++++++++++
1 file changed, 188 insertions(+)
create mode 100644 tools/include/linux/arm-smccc.h
diff --git a/tools/include/linux/arm-smccc.h b/tools/include/linux/arm-smccc.h
new file mode 100644
index 000000000000..a11c0bbabd5b
--- /dev/null
+++ b/tools/include/linux/arm-smccc.h
@@ -0,0 +1,188 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2015, Linaro Limited
+ */
+#ifndef __LINUX_ARM_SMCCC_H
+#define __LINUX_ARM_SMCCC_H
+
+#include <linux/const.h>
+
+/*
+ * This file provides common defines for ARM SMC Calling Convention as
+ * specified in
+ * https://developer.arm.com/docs/den0028/latest
+ *
+ * This code is up-to-date with version DEN 0028 C
+ */
+
+#define ARM_SMCCC_STD_CALL _AC(0,U)
+#define ARM_SMCCC_FAST_CALL _AC(1,U)
+#define ARM_SMCCC_TYPE_SHIFT 31
+
+#define ARM_SMCCC_SMC_32 0
+#define ARM_SMCCC_SMC_64 1
+#define ARM_SMCCC_CALL_CONV_SHIFT 30
+
+#define ARM_SMCCC_OWNER_MASK 0x3F
+#define ARM_SMCCC_OWNER_SHIFT 24
+
+#define ARM_SMCCC_FUNC_MASK 0xFFFF
+
+#define ARM_SMCCC_IS_FAST_CALL(smc_val) \
+ ((smc_val) & (ARM_SMCCC_FAST_CALL << ARM_SMCCC_TYPE_SHIFT))
+#define ARM_SMCCC_IS_64(smc_val) \
+ ((smc_val) & (ARM_SMCCC_SMC_64 << ARM_SMCCC_CALL_CONV_SHIFT))
+#define ARM_SMCCC_FUNC_NUM(smc_val) ((smc_val) & ARM_SMCCC_FUNC_MASK)
+#define ARM_SMCCC_OWNER_NUM(smc_val) \
+ (((smc_val) >> ARM_SMCCC_OWNER_SHIFT) & ARM_SMCCC_OWNER_MASK)
+
+#define ARM_SMCCC_CALL_VAL(type, calling_convention, owner, func_num) \
+ (((type) << ARM_SMCCC_TYPE_SHIFT) | \
+ ((calling_convention) << ARM_SMCCC_CALL_CONV_SHIFT) | \
+ (((owner) & ARM_SMCCC_OWNER_MASK) << ARM_SMCCC_OWNER_SHIFT) | \
+ ((func_num) & ARM_SMCCC_FUNC_MASK))
+
+#define ARM_SMCCC_OWNER_ARCH 0
+#define ARM_SMCCC_OWNER_CPU 1
+#define ARM_SMCCC_OWNER_SIP 2
+#define ARM_SMCCC_OWNER_OEM 3
+#define ARM_SMCCC_OWNER_STANDARD 4
+#define ARM_SMCCC_OWNER_STANDARD_HYP 5
+#define ARM_SMCCC_OWNER_VENDOR_HYP 6
+#define ARM_SMCCC_OWNER_TRUSTED_APP 48
+#define ARM_SMCCC_OWNER_TRUSTED_APP_END 49
+#define ARM_SMCCC_OWNER_TRUSTED_OS 50
+#define ARM_SMCCC_OWNER_TRUSTED_OS_END 63
+
+#define ARM_SMCCC_FUNC_QUERY_CALL_UID 0xff01
+
+#define ARM_SMCCC_QUIRK_NONE 0
+#define ARM_SMCCC_QUIRK_QCOM_A6 1 /* Save/restore register a6 */
+
+#define ARM_SMCCC_VERSION_1_0 0x10000
+#define ARM_SMCCC_VERSION_1_1 0x10001
+#define ARM_SMCCC_VERSION_1_2 0x10002
+#define ARM_SMCCC_VERSION_1_3 0x10003
+
+#define ARM_SMCCC_1_3_SVE_HINT 0x10000
+
+#define ARM_SMCCC_VERSION_FUNC_ID \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ 0, 0)
+
+#define ARM_SMCCC_ARCH_FEATURES_FUNC_ID \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ 0, 1)
+
+#define ARM_SMCCC_ARCH_SOC_ID \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ 0, 2)
+
+#define ARM_SMCCC_ARCH_WORKAROUND_1 \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ 0, 0x8000)
+
+#define ARM_SMCCC_ARCH_WORKAROUND_2 \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ 0, 0x7fff)
+
+#define ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ ARM_SMCCC_OWNER_VENDOR_HYP, \
+ ARM_SMCCC_FUNC_QUERY_CALL_UID)
+
+/* KVM UID value: 28b46fb6-2ec5-11e9-a9ca-4b564d003a74 */
+#define ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_0 0xb66fb428U
+#define ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_1 0xe911c52eU
+#define ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_2 0x564bcaa9U
+#define ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_3 0x743a004dU
+
+/* KVM "vendor specific" services */
+#define ARM_SMCCC_KVM_FUNC_FEATURES 0
+#define ARM_SMCCC_KVM_FUNC_PTP 1
+#define ARM_SMCCC_KVM_FUNC_FEATURES_2 127
+#define ARM_SMCCC_KVM_NUM_FUNCS 128
+
+#define ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ ARM_SMCCC_OWNER_VENDOR_HYP, \
+ ARM_SMCCC_KVM_FUNC_FEATURES)
+
+#define SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED 1
+
+/*
+ * ptp_kvm is a feature used for time sync between vm and host.
+ * ptp_kvm module in guest kernel will get service from host using
+ * this hypercall ID.
+ */
+#define ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ ARM_SMCCC_OWNER_VENDOR_HYP, \
+ ARM_SMCCC_KVM_FUNC_PTP)
+
+/* ptp_kvm counter type ID */
+#define KVM_PTP_VIRT_COUNTER 0
+#define KVM_PTP_PHYS_COUNTER 1
+
+/* Paravirtualised time calls (defined by ARM DEN0057A) */
+#define ARM_SMCCC_HV_PV_TIME_FEATURES \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_64, \
+ ARM_SMCCC_OWNER_STANDARD_HYP, \
+ 0x20)
+
+#define ARM_SMCCC_HV_PV_TIME_ST \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_64, \
+ ARM_SMCCC_OWNER_STANDARD_HYP, \
+ 0x21)
+
+/* TRNG entropy source calls (defined by ARM DEN0098) */
+#define ARM_SMCCC_TRNG_VERSION \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ ARM_SMCCC_OWNER_STANDARD, \
+ 0x50)
+
+#define ARM_SMCCC_TRNG_FEATURES \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ ARM_SMCCC_OWNER_STANDARD, \
+ 0x51)
+
+#define ARM_SMCCC_TRNG_GET_UUID \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ ARM_SMCCC_OWNER_STANDARD, \
+ 0x52)
+
+#define ARM_SMCCC_TRNG_RND32 \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ ARM_SMCCC_OWNER_STANDARD, \
+ 0x53)
+
+#define ARM_SMCCC_TRNG_RND64 \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_64, \
+ ARM_SMCCC_OWNER_STANDARD, \
+ 0x53)
+
+/*
+ * Return codes defined in ARM DEN 0070A
+ * ARM DEN 0070A is now merged/consolidated into ARM DEN 0028 C
+ */
+#define SMCCC_RET_SUCCESS 0
+#define SMCCC_RET_NOT_SUPPORTED -1
+#define SMCCC_RET_NOT_REQUIRED -2
+#define SMCCC_RET_INVALID_PARAMETER -3
+
+#endif /*__LINUX_ARM_SMCCC_H*/
--
2.35.1.473.g83b2b277ed-goog
^ permalink raw reply related [flat|nested] 117+ messages in thread
* [PATCH v4 10/13] tools: Import ARM SMCCC definitions
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: Paolo Bonzini, Catalin Marinas, Will Deacon, Peter Shier,
Ricardo Koller, Oliver Upton, Reiji Watanabe, Jing Zhang,
Raghavendra Rao Anata, linux-arm-kernel, kvmarm, linux-kernel,
kvm
Import the standard SMCCC definitions from include/linux/arm-smccc.h.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
tools/include/linux/arm-smccc.h | 188 ++++++++++++++++++++++++++++++++
1 file changed, 188 insertions(+)
create mode 100644 tools/include/linux/arm-smccc.h
diff --git a/tools/include/linux/arm-smccc.h b/tools/include/linux/arm-smccc.h
new file mode 100644
index 000000000000..a11c0bbabd5b
--- /dev/null
+++ b/tools/include/linux/arm-smccc.h
@@ -0,0 +1,188 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2015, Linaro Limited
+ */
+#ifndef __LINUX_ARM_SMCCC_H
+#define __LINUX_ARM_SMCCC_H
+
+#include <linux/const.h>
+
+/*
+ * This file provides common defines for ARM SMC Calling Convention as
+ * specified in
+ * https://developer.arm.com/docs/den0028/latest
+ *
+ * This code is up-to-date with version DEN 0028 C
+ */
+
+#define ARM_SMCCC_STD_CALL _AC(0,U)
+#define ARM_SMCCC_FAST_CALL _AC(1,U)
+#define ARM_SMCCC_TYPE_SHIFT 31
+
+#define ARM_SMCCC_SMC_32 0
+#define ARM_SMCCC_SMC_64 1
+#define ARM_SMCCC_CALL_CONV_SHIFT 30
+
+#define ARM_SMCCC_OWNER_MASK 0x3F
+#define ARM_SMCCC_OWNER_SHIFT 24
+
+#define ARM_SMCCC_FUNC_MASK 0xFFFF
+
+#define ARM_SMCCC_IS_FAST_CALL(smc_val) \
+ ((smc_val) & (ARM_SMCCC_FAST_CALL << ARM_SMCCC_TYPE_SHIFT))
+#define ARM_SMCCC_IS_64(smc_val) \
+ ((smc_val) & (ARM_SMCCC_SMC_64 << ARM_SMCCC_CALL_CONV_SHIFT))
+#define ARM_SMCCC_FUNC_NUM(smc_val) ((smc_val) & ARM_SMCCC_FUNC_MASK)
+#define ARM_SMCCC_OWNER_NUM(smc_val) \
+ (((smc_val) >> ARM_SMCCC_OWNER_SHIFT) & ARM_SMCCC_OWNER_MASK)
+
+#define ARM_SMCCC_CALL_VAL(type, calling_convention, owner, func_num) \
+ (((type) << ARM_SMCCC_TYPE_SHIFT) | \
+ ((calling_convention) << ARM_SMCCC_CALL_CONV_SHIFT) | \
+ (((owner) & ARM_SMCCC_OWNER_MASK) << ARM_SMCCC_OWNER_SHIFT) | \
+ ((func_num) & ARM_SMCCC_FUNC_MASK))
+
+#define ARM_SMCCC_OWNER_ARCH 0
+#define ARM_SMCCC_OWNER_CPU 1
+#define ARM_SMCCC_OWNER_SIP 2
+#define ARM_SMCCC_OWNER_OEM 3
+#define ARM_SMCCC_OWNER_STANDARD 4
+#define ARM_SMCCC_OWNER_STANDARD_HYP 5
+#define ARM_SMCCC_OWNER_VENDOR_HYP 6
+#define ARM_SMCCC_OWNER_TRUSTED_APP 48
+#define ARM_SMCCC_OWNER_TRUSTED_APP_END 49
+#define ARM_SMCCC_OWNER_TRUSTED_OS 50
+#define ARM_SMCCC_OWNER_TRUSTED_OS_END 63
+
+#define ARM_SMCCC_FUNC_QUERY_CALL_UID 0xff01
+
+#define ARM_SMCCC_QUIRK_NONE 0
+#define ARM_SMCCC_QUIRK_QCOM_A6 1 /* Save/restore register a6 */
+
+#define ARM_SMCCC_VERSION_1_0 0x10000
+#define ARM_SMCCC_VERSION_1_1 0x10001
+#define ARM_SMCCC_VERSION_1_2 0x10002
+#define ARM_SMCCC_VERSION_1_3 0x10003
+
+#define ARM_SMCCC_1_3_SVE_HINT 0x10000
+
+#define ARM_SMCCC_VERSION_FUNC_ID \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ 0, 0)
+
+#define ARM_SMCCC_ARCH_FEATURES_FUNC_ID \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ 0, 1)
+
+#define ARM_SMCCC_ARCH_SOC_ID \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ 0, 2)
+
+#define ARM_SMCCC_ARCH_WORKAROUND_1 \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ 0, 0x8000)
+
+#define ARM_SMCCC_ARCH_WORKAROUND_2 \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ 0, 0x7fff)
+
+#define ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ ARM_SMCCC_OWNER_VENDOR_HYP, \
+ ARM_SMCCC_FUNC_QUERY_CALL_UID)
+
+/* KVM UID value: 28b46fb6-2ec5-11e9-a9ca-4b564d003a74 */
+#define ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_0 0xb66fb428U
+#define ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_1 0xe911c52eU
+#define ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_2 0x564bcaa9U
+#define ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_3 0x743a004dU
+
+/* KVM "vendor specific" services */
+#define ARM_SMCCC_KVM_FUNC_FEATURES 0
+#define ARM_SMCCC_KVM_FUNC_PTP 1
+#define ARM_SMCCC_KVM_FUNC_FEATURES_2 127
+#define ARM_SMCCC_KVM_NUM_FUNCS 128
+
+#define ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ ARM_SMCCC_OWNER_VENDOR_HYP, \
+ ARM_SMCCC_KVM_FUNC_FEATURES)
+
+#define SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED 1
+
+/*
+ * ptp_kvm is a feature used for time sync between vm and host.
+ * ptp_kvm module in guest kernel will get service from host using
+ * this hypercall ID.
+ */
+#define ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ ARM_SMCCC_OWNER_VENDOR_HYP, \
+ ARM_SMCCC_KVM_FUNC_PTP)
+
+/* ptp_kvm counter type ID */
+#define KVM_PTP_VIRT_COUNTER 0
+#define KVM_PTP_PHYS_COUNTER 1
+
+/* Paravirtualised time calls (defined by ARM DEN0057A) */
+#define ARM_SMCCC_HV_PV_TIME_FEATURES \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_64, \
+ ARM_SMCCC_OWNER_STANDARD_HYP, \
+ 0x20)
+
+#define ARM_SMCCC_HV_PV_TIME_ST \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_64, \
+ ARM_SMCCC_OWNER_STANDARD_HYP, \
+ 0x21)
+
+/* TRNG entropy source calls (defined by ARM DEN0098) */
+#define ARM_SMCCC_TRNG_VERSION \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ ARM_SMCCC_OWNER_STANDARD, \
+ 0x50)
+
+#define ARM_SMCCC_TRNG_FEATURES \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ ARM_SMCCC_OWNER_STANDARD, \
+ 0x51)
+
+#define ARM_SMCCC_TRNG_GET_UUID \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ ARM_SMCCC_OWNER_STANDARD, \
+ 0x52)
+
+#define ARM_SMCCC_TRNG_RND32 \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ ARM_SMCCC_OWNER_STANDARD, \
+ 0x53)
+
+#define ARM_SMCCC_TRNG_RND64 \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_64, \
+ ARM_SMCCC_OWNER_STANDARD, \
+ 0x53)
+
+/*
+ * Return codes defined in ARM DEN 0070A
+ * ARM DEN 0070A is now merged/consolidated into ARM DEN 0028 C
+ */
+#define SMCCC_RET_SUCCESS 0
+#define SMCCC_RET_NOT_SUPPORTED -1
+#define SMCCC_RET_NOT_REQUIRED -2
+#define SMCCC_RET_INVALID_PARAMETER -3
+
+#endif /*__LINUX_ARM_SMCCC_H*/
--
2.35.1.473.g83b2b277ed-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 117+ messages in thread
* [PATCH v4 11/13] selftests: KVM: aarch64: Introduce hypercall ABI test
2022-02-24 17:25 ` Raghavendra Rao Ananta
(?)
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
-1 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: kvm, Catalin Marinas, Peter Shier, linux-kernel, Paolo Bonzini,
Will Deacon, kvmarm, linux-arm-kernel
Introduce a KVM selftest to check the hypercall interface
for arm64 platforms. The test validates the user-space's
IOCTL interface to read/write the psuedo-firmware registers
as well as its effects on the guest upon certain configurations.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
tools/testing/selftests/kvm/.gitignore | 1 +
tools/testing/selftests/kvm/Makefile | 1 +
.../selftests/kvm/aarch64/hypercalls.c | 376 ++++++++++++++++++
3 files changed, 378 insertions(+)
create mode 100644 tools/testing/selftests/kvm/aarch64/hypercalls.c
diff --git a/tools/testing/selftests/kvm/.gitignore b/tools/testing/selftests/kvm/.gitignore
index ac69108d9ffd..f13c33fcd733 100644
--- a/tools/testing/selftests/kvm/.gitignore
+++ b/tools/testing/selftests/kvm/.gitignore
@@ -2,6 +2,7 @@
/aarch64/arch_timer
/aarch64/debug-exceptions
/aarch64/get-reg-list
+/aarch64/hypercalls
/aarch64/psci_test
/aarch64/vgic_init
/aarch64/vgic_irq
diff --git a/tools/testing/selftests/kvm/Makefile b/tools/testing/selftests/kvm/Makefile
index 2a27c09b22ae..2181bdd5b09c 100644
--- a/tools/testing/selftests/kvm/Makefile
+++ b/tools/testing/selftests/kvm/Makefile
@@ -102,6 +102,7 @@ TEST_GEN_PROGS_x86_64 += system_counter_offset_test
TEST_GEN_PROGS_aarch64 += aarch64/arch_timer
TEST_GEN_PROGS_aarch64 += aarch64/debug-exceptions
TEST_GEN_PROGS_aarch64 += aarch64/get-reg-list
+TEST_GEN_PROGS_aarch64 += aarch64/hypercalls
TEST_GEN_PROGS_aarch64 += aarch64/psci_test
TEST_GEN_PROGS_aarch64 += aarch64/vgic_init
TEST_GEN_PROGS_aarch64 += aarch64/vgic_irq
diff --git a/tools/testing/selftests/kvm/aarch64/hypercalls.c b/tools/testing/selftests/kvm/aarch64/hypercalls.c
new file mode 100644
index 000000000000..e4e3a286ff3e
--- /dev/null
+++ b/tools/testing/selftests/kvm/aarch64/hypercalls.c
@@ -0,0 +1,376 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+/* hypercalls: Check the ARM64's psuedo-firmware bitmap register interface.
+ *
+ * The test validates the basic hypercall functionalities that are exposed
+ * via the psuedo-firmware bitmap register. This includes the registers'
+ * read/write behavior before and after the VM has started, and if the
+ * hypercalls are properly masked or unmasked to the guest when disabled or
+ * enabled from the KVM userspace, respectively.
+ */
+
+#include <errno.h>
+#include <linux/arm-smccc.h>
+#include <asm/kvm.h>
+#include <kvm_util.h>
+
+#include "processor.h"
+
+#define FW_REG_ULIMIT_VAL(max_feat_bit) (GENMASK_ULL(max_feat_bit, 0))
+
+struct kvm_fw_reg_info {
+ uint64_t reg; /* Register definition */
+ uint64_t max_feat_bit; /* Bit that represents the upper limit of the feature-map */
+};
+
+#define FW_REG_INFO(r, bit_max) \
+ { \
+ .reg = r, \
+ .max_feat_bit = bit_max, \
+ }
+
+static const struct kvm_fw_reg_info fw_reg_info[] = {
+ FW_REG_INFO(KVM_REG_ARM_STD_BMAP, KVM_REG_ARM_STD_BMAP_BIT_MAX),
+ FW_REG_INFO(KVM_REG_ARM_STD_HYP_BMAP, KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX),
+ FW_REG_INFO(KVM_REG_ARM_VENDOR_HYP_BMAP, KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX),
+};
+
+enum test_stage {
+ TEST_STAGE_REG_IFACE,
+ TEST_STAGE_HVC_IFACE_FEAT_DISABLED,
+ TEST_STAGE_HVC_IFACE_FEAT_ENABLED,
+ TEST_STAGE_HVC_IFACE_FALSE_INFO,
+ TEST_STAGE_END,
+};
+
+static int stage;
+
+struct test_hvc_info {
+ uint32_t func_id;
+ int64_t arg0;
+
+ void (*test_hvc_disabled)(const struct test_hvc_info *hc_info,
+ struct arm_smccc_res *res);
+ void (*test_hvc_enabled)(const struct test_hvc_info *hc_info,
+ struct arm_smccc_res *res);
+};
+
+#define TEST_HVC_INFO(f, a0, test_disabled, test_enabled) \
+ { \
+ .func_id = f, \
+ .arg0 = a0, \
+ .test_hvc_disabled = test_disabled, \
+ .test_hvc_enabled = test_enabled, \
+ }
+
+static void
+test_ptp_feat_hvc_disabled(const struct test_hvc_info *hc_info, struct arm_smccc_res *res)
+{
+ GUEST_ASSERT_3((res->a0 & BIT(ARM_SMCCC_KVM_FUNC_PTP)) == 0,
+ res->a0, hc_info->func_id, hc_info->arg0);
+}
+
+static void
+test_ptp_feat_hvc_enabled(const struct test_hvc_info *hc_info, struct arm_smccc_res *res)
+{
+ GUEST_ASSERT_3((res->a0 & BIT(ARM_SMCCC_KVM_FUNC_PTP)) != 0,
+ res->a0, hc_info->func_id, hc_info->arg0);
+}
+
+static const struct test_hvc_info hvc_info[] = {
+ /* KVM_REG_ARM_STD_BMAP: KVM_REG_ARM_STD_BIT_TRNG_V1_0 */
+ TEST_HVC_INFO(ARM_SMCCC_TRNG_VERSION, 0, NULL, NULL),
+ TEST_HVC_INFO(ARM_SMCCC_TRNG_FEATURES, ARM_SMCCC_TRNG_RND64, NULL, NULL),
+ TEST_HVC_INFO(ARM_SMCCC_TRNG_GET_UUID, 0, NULL, NULL),
+ TEST_HVC_INFO(ARM_SMCCC_TRNG_RND32, 0, NULL, NULL),
+ TEST_HVC_INFO(ARM_SMCCC_TRNG_RND64, 0, NULL, NULL),
+
+ /* KVM_REG_ARM_STD_HYP_BMAP: KVM_REG_ARM_STD_HYP_BIT_PV_TIME */
+ TEST_HVC_INFO(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
+ ARM_SMCCC_HV_PV_TIME_FEATURES, NULL, NULL),
+ TEST_HVC_INFO(ARM_SMCCC_HV_PV_TIME_FEATURES,
+ ARM_SMCCC_HV_PV_TIME_ST, NULL, NULL),
+ TEST_HVC_INFO(ARM_SMCCC_HV_PV_TIME_ST, 0, NULL, NULL),
+
+ /* KVM_REG_ARM_VENDOR_HYP_BMAP: KVM_REG_ARM_VENDOR_HYP_BIT_PTP */
+ TEST_HVC_INFO(ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID,
+ ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID,
+ test_ptp_feat_hvc_disabled, test_ptp_feat_hvc_enabled),
+ TEST_HVC_INFO(ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID,
+ KVM_PTP_VIRT_COUNTER, NULL, NULL),
+};
+
+/* Feed false hypercall info to test the KVM behavior */
+static const struct test_hvc_info false_hvc_info[] = {
+ /* Feature support check against a different family of hypercalls */
+ TEST_HVC_INFO(ARM_SMCCC_TRNG_FEATURES,
+ ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID, NULL, NULL),
+ TEST_HVC_INFO(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
+ ARM_SMCCC_TRNG_RND64, NULL, NULL),
+ TEST_HVC_INFO(ARM_SMCCC_HV_PV_TIME_FEATURES,
+ ARM_SMCCC_TRNG_RND64, NULL, NULL),
+};
+
+static void guest_test_hvc(const struct test_hvc_info *hc_info)
+{
+ unsigned int i;
+ struct arm_smccc_res res;
+ unsigned int hvc_info_arr_sz;
+
+ hvc_info_arr_sz =
+ hc_info == hvc_info ? ARRAY_SIZE(hvc_info) : ARRAY_SIZE(false_hvc_info);
+
+ for (i = 0; i < hvc_info_arr_sz; i++, hc_info++) {
+
+ memset(&res, 0, sizeof(res));
+ smccc_hvc(hc_info->func_id, hc_info->arg0, 0, 0, 0, 0, 0, 0, &res);
+
+ switch (stage) {
+ case TEST_STAGE_HVC_IFACE_FEAT_DISABLED:
+ if (hc_info->test_hvc_disabled)
+ hc_info->test_hvc_disabled(hc_info, &res);
+ else
+ GUEST_ASSERT_3(res.a0 == SMCCC_RET_NOT_SUPPORTED,
+ res.a0, hc_info->func_id, hc_info->arg0);
+ break;
+ case TEST_STAGE_HVC_IFACE_FEAT_ENABLED:
+ if (hc_info->test_hvc_enabled)
+ hc_info->test_hvc_enabled(hc_info, &res);
+ else
+ GUEST_ASSERT_3(res.a0 != SMCCC_RET_NOT_SUPPORTED,
+ res.a0, hc_info->func_id, hc_info->arg0);
+ break;
+ case TEST_STAGE_HVC_IFACE_FALSE_INFO:
+ GUEST_ASSERT_3(res.a0 == SMCCC_RET_NOT_SUPPORTED,
+ res.a0, hc_info->func_id, hc_info->arg0);
+ break;
+ default:
+ GUEST_ASSERT_1(0, stage);
+ }
+ }
+}
+
+static void guest_code(void)
+{
+ while (stage != TEST_STAGE_END) {
+ switch (stage) {
+ case TEST_STAGE_REG_IFACE:
+ break;
+ case TEST_STAGE_HVC_IFACE_FEAT_DISABLED:
+ case TEST_STAGE_HVC_IFACE_FEAT_ENABLED:
+ guest_test_hvc(hvc_info);
+ break;
+ case TEST_STAGE_HVC_IFACE_FALSE_INFO:
+ guest_test_hvc(false_hvc_info);
+ break;
+ default:
+ GUEST_ASSERT_1(0, stage);
+ }
+
+ GUEST_SYNC(stage);
+ }
+
+ GUEST_DONE();
+}
+
+static int set_fw_reg(struct kvm_vm *vm, uint64_t id, uint64_t val)
+{
+ struct kvm_one_reg reg = {
+ .id = KVM_REG_ARM_FW_REG(id),
+ .addr = (uint64_t)&val,
+ };
+
+ return _vcpu_ioctl(vm, 0, KVM_SET_ONE_REG, ®);
+}
+
+static void get_fw_reg(struct kvm_vm *vm, uint64_t id, uint64_t *addr)
+{
+ struct kvm_one_reg reg = {
+ .id = KVM_REG_ARM_FW_REG(id),
+ .addr = (uint64_t)addr,
+ };
+
+ return vcpu_ioctl(vm, 0, KVM_GET_ONE_REG, ®);
+}
+
+struct st_time {
+ uint32_t rev;
+ uint32_t attr;
+ uint64_t st_time;
+};
+
+#define STEAL_TIME_SIZE ((sizeof(struct st_time) + 63) & ~63)
+#define ST_GPA_BASE (1 << 30)
+
+static void steal_time_init(struct kvm_vm *vm)
+{
+ uint64_t st_ipa = (ulong)ST_GPA_BASE;
+ unsigned int gpages;
+ struct kvm_device_attr dev = {
+ .group = KVM_ARM_VCPU_PVTIME_CTRL,
+ .attr = KVM_ARM_VCPU_PVTIME_IPA,
+ .addr = (uint64_t)&st_ipa,
+ };
+
+ gpages = vm_calc_num_guest_pages(VM_MODE_DEFAULT, STEAL_TIME_SIZE);
+ vm_userspace_mem_region_add(vm, VM_MEM_SRC_ANONYMOUS, ST_GPA_BASE, 1, gpages, 0);
+
+ vcpu_ioctl(vm, 0, KVM_SET_DEVICE_ATTR, &dev);
+}
+
+static void test_fw_regs_before_vm_start(struct kvm_vm *vm)
+{
+ uint64_t val;
+ unsigned int i;
+ int ret;
+
+ for (i = 0; i < ARRAY_SIZE(fw_reg_info); i++) {
+ const struct kvm_fw_reg_info *reg_info = &fw_reg_info[i];
+
+ /* First read should be an upper limit of the features supported */
+ get_fw_reg(vm, reg_info->reg, &val);
+ TEST_ASSERT(val == FW_REG_ULIMIT_VAL(reg_info->max_feat_bit),
+ "Expected all the features to be set for reg: 0x%lx; expected: 0x%llx; read: 0x%lx\n",
+ reg_info->reg, GENMASK_ULL(reg_info->max_feat_bit, 0), val);
+
+ /* Test 'write' by disabling all the features of the register map */
+ ret = set_fw_reg(vm, reg_info->reg, 0);
+ TEST_ASSERT(ret == 0,
+ "Failed to clear all the features of reg: 0x%lx; ret: %d\n",
+ reg_info->reg, errno);
+
+ get_fw_reg(vm, reg_info->reg, &val);
+ TEST_ASSERT(val == 0,
+ "Expected all the features to be cleared for reg: 0x%lx\n", reg_info->reg);
+
+ /*
+ * Test enabling a feature that's not supported.
+ * Avoid this check if all the bits are occupied.
+ */
+ if (reg_info->max_feat_bit < 63) {
+ ret = set_fw_reg(vm, reg_info->reg, BIT(reg_info->max_feat_bit + 1));
+ TEST_ASSERT(ret != 0 && errno == EINVAL,
+ "Unexpected behavior or return value (%d) while setting an unsupported feature for reg: 0x%lx\n",
+ errno, reg_info->reg);
+ }
+ }
+}
+
+static void test_fw_regs_after_vm_start(struct kvm_vm *vm)
+{
+ uint64_t val;
+ unsigned int i;
+ int ret;
+
+ for (i = 0; i < ARRAY_SIZE(fw_reg_info); i++) {
+ const struct kvm_fw_reg_info *reg_info = &fw_reg_info[i];
+
+ /*
+ * Before starting the VM, the test clears all the bits.
+ * Check if that's still the case.
+ */
+ get_fw_reg(vm, reg_info->reg, &val);
+ TEST_ASSERT(val == 0,
+ "Expected all the features to be cleared for reg: 0x%lx\n",
+ reg_info->reg);
+
+ /*
+ * Test setting the last read value. KVM should allow this
+ * even if VM has started running.
+ */
+ ret = set_fw_reg(vm, reg_info->reg, val);
+ TEST_ASSERT(ret == 0,
+ "Failed to set the register with previously read value after Vm start for reg: 0x%lx; ret: %d\n",
+ reg_info->reg, errno);
+
+ /*
+ * Set all the features for this register again. KVM shouldn't
+ * allow this as the VM is running.
+ */
+ ret = set_fw_reg(vm, reg_info->reg, FW_REG_ULIMIT_VAL(reg_info->max_feat_bit));
+ TEST_ASSERT(ret != 0 && errno == EBUSY,
+ "Unexpected behavior or return value (%d) while setting a feature while VM is running for reg: 0x%lx\n",
+ errno, reg_info->reg);
+ }
+}
+
+static struct kvm_vm *test_vm_create(void)
+{
+ struct kvm_vm *vm;
+
+ vm = vm_create_default(0, 0, guest_code);
+
+ ucall_init(vm, NULL);
+ steal_time_init(vm);
+
+ return vm;
+}
+
+static struct kvm_vm *test_guest_stage(struct kvm_vm *vm)
+{
+ struct kvm_vm *ret_vm = vm;
+
+ pr_debug("Stage: %d\n", stage);
+
+ switch (stage) {
+ case TEST_STAGE_REG_IFACE:
+ test_fw_regs_after_vm_start(vm);
+ break;
+ case TEST_STAGE_HVC_IFACE_FEAT_DISABLED:
+ /* Start a new VM so that all the features are now enabled by default */
+ kvm_vm_free(vm);
+ ret_vm = test_vm_create();
+ break;
+ case TEST_STAGE_HVC_IFACE_FEAT_ENABLED:
+ case TEST_STAGE_HVC_IFACE_FALSE_INFO:
+ break;
+ default:
+ TEST_FAIL("Unknown test stage: %d\n", stage);
+ }
+
+ stage++;
+ sync_global_to_guest(vm, stage);
+
+ return ret_vm;
+}
+
+static void test_run(void)
+{
+ struct kvm_vm *vm;
+ struct ucall uc;
+ bool guest_done = false;
+
+ vm = test_vm_create();
+
+ test_fw_regs_before_vm_start(vm);
+
+ while (!guest_done) {
+ vcpu_run(vm, 0);
+
+ switch (get_ucall(vm, 0, &uc)) {
+ case UCALL_SYNC:
+ vm = test_guest_stage(vm);
+ break;
+ case UCALL_DONE:
+ guest_done = true;
+ break;
+ case UCALL_ABORT:
+ TEST_FAIL("%s at %s:%ld\n\tvalues: 0x%lx, 0x%lx; 0x%lx, stage: %u",
+ (const char *)uc.args[0], __FILE__, uc.args[1],
+ uc.args[2], uc.args[3], uc.args[4], stage);
+ break;
+ default:
+ TEST_FAIL("Unexpected guest exit\n");
+ }
+ }
+
+ kvm_vm_free(vm);
+}
+
+int main(void)
+{
+ setbuf(stdout, NULL);
+
+ test_run();
+ return 0;
+}
--
2.35.1.473.g83b2b277ed-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 117+ messages in thread* [PATCH v4 11/13] selftests: KVM: aarch64: Introduce hypercall ABI test
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: Paolo Bonzini, Catalin Marinas, Will Deacon, Peter Shier,
Ricardo Koller, Oliver Upton, Reiji Watanabe, Jing Zhang,
Raghavendra Rao Anata, linux-arm-kernel, kvmarm, linux-kernel,
kvm
Introduce a KVM selftest to check the hypercall interface
for arm64 platforms. The test validates the user-space's
IOCTL interface to read/write the psuedo-firmware registers
as well as its effects on the guest upon certain configurations.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
tools/testing/selftests/kvm/.gitignore | 1 +
tools/testing/selftests/kvm/Makefile | 1 +
.../selftests/kvm/aarch64/hypercalls.c | 376 ++++++++++++++++++
3 files changed, 378 insertions(+)
create mode 100644 tools/testing/selftests/kvm/aarch64/hypercalls.c
diff --git a/tools/testing/selftests/kvm/.gitignore b/tools/testing/selftests/kvm/.gitignore
index ac69108d9ffd..f13c33fcd733 100644
--- a/tools/testing/selftests/kvm/.gitignore
+++ b/tools/testing/selftests/kvm/.gitignore
@@ -2,6 +2,7 @@
/aarch64/arch_timer
/aarch64/debug-exceptions
/aarch64/get-reg-list
+/aarch64/hypercalls
/aarch64/psci_test
/aarch64/vgic_init
/aarch64/vgic_irq
diff --git a/tools/testing/selftests/kvm/Makefile b/tools/testing/selftests/kvm/Makefile
index 2a27c09b22ae..2181bdd5b09c 100644
--- a/tools/testing/selftests/kvm/Makefile
+++ b/tools/testing/selftests/kvm/Makefile
@@ -102,6 +102,7 @@ TEST_GEN_PROGS_x86_64 += system_counter_offset_test
TEST_GEN_PROGS_aarch64 += aarch64/arch_timer
TEST_GEN_PROGS_aarch64 += aarch64/debug-exceptions
TEST_GEN_PROGS_aarch64 += aarch64/get-reg-list
+TEST_GEN_PROGS_aarch64 += aarch64/hypercalls
TEST_GEN_PROGS_aarch64 += aarch64/psci_test
TEST_GEN_PROGS_aarch64 += aarch64/vgic_init
TEST_GEN_PROGS_aarch64 += aarch64/vgic_irq
diff --git a/tools/testing/selftests/kvm/aarch64/hypercalls.c b/tools/testing/selftests/kvm/aarch64/hypercalls.c
new file mode 100644
index 000000000000..e4e3a286ff3e
--- /dev/null
+++ b/tools/testing/selftests/kvm/aarch64/hypercalls.c
@@ -0,0 +1,376 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+/* hypercalls: Check the ARM64's psuedo-firmware bitmap register interface.
+ *
+ * The test validates the basic hypercall functionalities that are exposed
+ * via the psuedo-firmware bitmap register. This includes the registers'
+ * read/write behavior before and after the VM has started, and if the
+ * hypercalls are properly masked or unmasked to the guest when disabled or
+ * enabled from the KVM userspace, respectively.
+ */
+
+#include <errno.h>
+#include <linux/arm-smccc.h>
+#include <asm/kvm.h>
+#include <kvm_util.h>
+
+#include "processor.h"
+
+#define FW_REG_ULIMIT_VAL(max_feat_bit) (GENMASK_ULL(max_feat_bit, 0))
+
+struct kvm_fw_reg_info {
+ uint64_t reg; /* Register definition */
+ uint64_t max_feat_bit; /* Bit that represents the upper limit of the feature-map */
+};
+
+#define FW_REG_INFO(r, bit_max) \
+ { \
+ .reg = r, \
+ .max_feat_bit = bit_max, \
+ }
+
+static const struct kvm_fw_reg_info fw_reg_info[] = {
+ FW_REG_INFO(KVM_REG_ARM_STD_BMAP, KVM_REG_ARM_STD_BMAP_BIT_MAX),
+ FW_REG_INFO(KVM_REG_ARM_STD_HYP_BMAP, KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX),
+ FW_REG_INFO(KVM_REG_ARM_VENDOR_HYP_BMAP, KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX),
+};
+
+enum test_stage {
+ TEST_STAGE_REG_IFACE,
+ TEST_STAGE_HVC_IFACE_FEAT_DISABLED,
+ TEST_STAGE_HVC_IFACE_FEAT_ENABLED,
+ TEST_STAGE_HVC_IFACE_FALSE_INFO,
+ TEST_STAGE_END,
+};
+
+static int stage;
+
+struct test_hvc_info {
+ uint32_t func_id;
+ int64_t arg0;
+
+ void (*test_hvc_disabled)(const struct test_hvc_info *hc_info,
+ struct arm_smccc_res *res);
+ void (*test_hvc_enabled)(const struct test_hvc_info *hc_info,
+ struct arm_smccc_res *res);
+};
+
+#define TEST_HVC_INFO(f, a0, test_disabled, test_enabled) \
+ { \
+ .func_id = f, \
+ .arg0 = a0, \
+ .test_hvc_disabled = test_disabled, \
+ .test_hvc_enabled = test_enabled, \
+ }
+
+static void
+test_ptp_feat_hvc_disabled(const struct test_hvc_info *hc_info, struct arm_smccc_res *res)
+{
+ GUEST_ASSERT_3((res->a0 & BIT(ARM_SMCCC_KVM_FUNC_PTP)) == 0,
+ res->a0, hc_info->func_id, hc_info->arg0);
+}
+
+static void
+test_ptp_feat_hvc_enabled(const struct test_hvc_info *hc_info, struct arm_smccc_res *res)
+{
+ GUEST_ASSERT_3((res->a0 & BIT(ARM_SMCCC_KVM_FUNC_PTP)) != 0,
+ res->a0, hc_info->func_id, hc_info->arg0);
+}
+
+static const struct test_hvc_info hvc_info[] = {
+ /* KVM_REG_ARM_STD_BMAP: KVM_REG_ARM_STD_BIT_TRNG_V1_0 */
+ TEST_HVC_INFO(ARM_SMCCC_TRNG_VERSION, 0, NULL, NULL),
+ TEST_HVC_INFO(ARM_SMCCC_TRNG_FEATURES, ARM_SMCCC_TRNG_RND64, NULL, NULL),
+ TEST_HVC_INFO(ARM_SMCCC_TRNG_GET_UUID, 0, NULL, NULL),
+ TEST_HVC_INFO(ARM_SMCCC_TRNG_RND32, 0, NULL, NULL),
+ TEST_HVC_INFO(ARM_SMCCC_TRNG_RND64, 0, NULL, NULL),
+
+ /* KVM_REG_ARM_STD_HYP_BMAP: KVM_REG_ARM_STD_HYP_BIT_PV_TIME */
+ TEST_HVC_INFO(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
+ ARM_SMCCC_HV_PV_TIME_FEATURES, NULL, NULL),
+ TEST_HVC_INFO(ARM_SMCCC_HV_PV_TIME_FEATURES,
+ ARM_SMCCC_HV_PV_TIME_ST, NULL, NULL),
+ TEST_HVC_INFO(ARM_SMCCC_HV_PV_TIME_ST, 0, NULL, NULL),
+
+ /* KVM_REG_ARM_VENDOR_HYP_BMAP: KVM_REG_ARM_VENDOR_HYP_BIT_PTP */
+ TEST_HVC_INFO(ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID,
+ ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID,
+ test_ptp_feat_hvc_disabled, test_ptp_feat_hvc_enabled),
+ TEST_HVC_INFO(ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID,
+ KVM_PTP_VIRT_COUNTER, NULL, NULL),
+};
+
+/* Feed false hypercall info to test the KVM behavior */
+static const struct test_hvc_info false_hvc_info[] = {
+ /* Feature support check against a different family of hypercalls */
+ TEST_HVC_INFO(ARM_SMCCC_TRNG_FEATURES,
+ ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID, NULL, NULL),
+ TEST_HVC_INFO(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
+ ARM_SMCCC_TRNG_RND64, NULL, NULL),
+ TEST_HVC_INFO(ARM_SMCCC_HV_PV_TIME_FEATURES,
+ ARM_SMCCC_TRNG_RND64, NULL, NULL),
+};
+
+static void guest_test_hvc(const struct test_hvc_info *hc_info)
+{
+ unsigned int i;
+ struct arm_smccc_res res;
+ unsigned int hvc_info_arr_sz;
+
+ hvc_info_arr_sz =
+ hc_info == hvc_info ? ARRAY_SIZE(hvc_info) : ARRAY_SIZE(false_hvc_info);
+
+ for (i = 0; i < hvc_info_arr_sz; i++, hc_info++) {
+
+ memset(&res, 0, sizeof(res));
+ smccc_hvc(hc_info->func_id, hc_info->arg0, 0, 0, 0, 0, 0, 0, &res);
+
+ switch (stage) {
+ case TEST_STAGE_HVC_IFACE_FEAT_DISABLED:
+ if (hc_info->test_hvc_disabled)
+ hc_info->test_hvc_disabled(hc_info, &res);
+ else
+ GUEST_ASSERT_3(res.a0 == SMCCC_RET_NOT_SUPPORTED,
+ res.a0, hc_info->func_id, hc_info->arg0);
+ break;
+ case TEST_STAGE_HVC_IFACE_FEAT_ENABLED:
+ if (hc_info->test_hvc_enabled)
+ hc_info->test_hvc_enabled(hc_info, &res);
+ else
+ GUEST_ASSERT_3(res.a0 != SMCCC_RET_NOT_SUPPORTED,
+ res.a0, hc_info->func_id, hc_info->arg0);
+ break;
+ case TEST_STAGE_HVC_IFACE_FALSE_INFO:
+ GUEST_ASSERT_3(res.a0 == SMCCC_RET_NOT_SUPPORTED,
+ res.a0, hc_info->func_id, hc_info->arg0);
+ break;
+ default:
+ GUEST_ASSERT_1(0, stage);
+ }
+ }
+}
+
+static void guest_code(void)
+{
+ while (stage != TEST_STAGE_END) {
+ switch (stage) {
+ case TEST_STAGE_REG_IFACE:
+ break;
+ case TEST_STAGE_HVC_IFACE_FEAT_DISABLED:
+ case TEST_STAGE_HVC_IFACE_FEAT_ENABLED:
+ guest_test_hvc(hvc_info);
+ break;
+ case TEST_STAGE_HVC_IFACE_FALSE_INFO:
+ guest_test_hvc(false_hvc_info);
+ break;
+ default:
+ GUEST_ASSERT_1(0, stage);
+ }
+
+ GUEST_SYNC(stage);
+ }
+
+ GUEST_DONE();
+}
+
+static int set_fw_reg(struct kvm_vm *vm, uint64_t id, uint64_t val)
+{
+ struct kvm_one_reg reg = {
+ .id = KVM_REG_ARM_FW_REG(id),
+ .addr = (uint64_t)&val,
+ };
+
+ return _vcpu_ioctl(vm, 0, KVM_SET_ONE_REG, ®);
+}
+
+static void get_fw_reg(struct kvm_vm *vm, uint64_t id, uint64_t *addr)
+{
+ struct kvm_one_reg reg = {
+ .id = KVM_REG_ARM_FW_REG(id),
+ .addr = (uint64_t)addr,
+ };
+
+ return vcpu_ioctl(vm, 0, KVM_GET_ONE_REG, ®);
+}
+
+struct st_time {
+ uint32_t rev;
+ uint32_t attr;
+ uint64_t st_time;
+};
+
+#define STEAL_TIME_SIZE ((sizeof(struct st_time) + 63) & ~63)
+#define ST_GPA_BASE (1 << 30)
+
+static void steal_time_init(struct kvm_vm *vm)
+{
+ uint64_t st_ipa = (ulong)ST_GPA_BASE;
+ unsigned int gpages;
+ struct kvm_device_attr dev = {
+ .group = KVM_ARM_VCPU_PVTIME_CTRL,
+ .attr = KVM_ARM_VCPU_PVTIME_IPA,
+ .addr = (uint64_t)&st_ipa,
+ };
+
+ gpages = vm_calc_num_guest_pages(VM_MODE_DEFAULT, STEAL_TIME_SIZE);
+ vm_userspace_mem_region_add(vm, VM_MEM_SRC_ANONYMOUS, ST_GPA_BASE, 1, gpages, 0);
+
+ vcpu_ioctl(vm, 0, KVM_SET_DEVICE_ATTR, &dev);
+}
+
+static void test_fw_regs_before_vm_start(struct kvm_vm *vm)
+{
+ uint64_t val;
+ unsigned int i;
+ int ret;
+
+ for (i = 0; i < ARRAY_SIZE(fw_reg_info); i++) {
+ const struct kvm_fw_reg_info *reg_info = &fw_reg_info[i];
+
+ /* First read should be an upper limit of the features supported */
+ get_fw_reg(vm, reg_info->reg, &val);
+ TEST_ASSERT(val == FW_REG_ULIMIT_VAL(reg_info->max_feat_bit),
+ "Expected all the features to be set for reg: 0x%lx; expected: 0x%llx; read: 0x%lx\n",
+ reg_info->reg, GENMASK_ULL(reg_info->max_feat_bit, 0), val);
+
+ /* Test 'write' by disabling all the features of the register map */
+ ret = set_fw_reg(vm, reg_info->reg, 0);
+ TEST_ASSERT(ret == 0,
+ "Failed to clear all the features of reg: 0x%lx; ret: %d\n",
+ reg_info->reg, errno);
+
+ get_fw_reg(vm, reg_info->reg, &val);
+ TEST_ASSERT(val == 0,
+ "Expected all the features to be cleared for reg: 0x%lx\n", reg_info->reg);
+
+ /*
+ * Test enabling a feature that's not supported.
+ * Avoid this check if all the bits are occupied.
+ */
+ if (reg_info->max_feat_bit < 63) {
+ ret = set_fw_reg(vm, reg_info->reg, BIT(reg_info->max_feat_bit + 1));
+ TEST_ASSERT(ret != 0 && errno == EINVAL,
+ "Unexpected behavior or return value (%d) while setting an unsupported feature for reg: 0x%lx\n",
+ errno, reg_info->reg);
+ }
+ }
+}
+
+static void test_fw_regs_after_vm_start(struct kvm_vm *vm)
+{
+ uint64_t val;
+ unsigned int i;
+ int ret;
+
+ for (i = 0; i < ARRAY_SIZE(fw_reg_info); i++) {
+ const struct kvm_fw_reg_info *reg_info = &fw_reg_info[i];
+
+ /*
+ * Before starting the VM, the test clears all the bits.
+ * Check if that's still the case.
+ */
+ get_fw_reg(vm, reg_info->reg, &val);
+ TEST_ASSERT(val == 0,
+ "Expected all the features to be cleared for reg: 0x%lx\n",
+ reg_info->reg);
+
+ /*
+ * Test setting the last read value. KVM should allow this
+ * even if VM has started running.
+ */
+ ret = set_fw_reg(vm, reg_info->reg, val);
+ TEST_ASSERT(ret == 0,
+ "Failed to set the register with previously read value after Vm start for reg: 0x%lx; ret: %d\n",
+ reg_info->reg, errno);
+
+ /*
+ * Set all the features for this register again. KVM shouldn't
+ * allow this as the VM is running.
+ */
+ ret = set_fw_reg(vm, reg_info->reg, FW_REG_ULIMIT_VAL(reg_info->max_feat_bit));
+ TEST_ASSERT(ret != 0 && errno == EBUSY,
+ "Unexpected behavior or return value (%d) while setting a feature while VM is running for reg: 0x%lx\n",
+ errno, reg_info->reg);
+ }
+}
+
+static struct kvm_vm *test_vm_create(void)
+{
+ struct kvm_vm *vm;
+
+ vm = vm_create_default(0, 0, guest_code);
+
+ ucall_init(vm, NULL);
+ steal_time_init(vm);
+
+ return vm;
+}
+
+static struct kvm_vm *test_guest_stage(struct kvm_vm *vm)
+{
+ struct kvm_vm *ret_vm = vm;
+
+ pr_debug("Stage: %d\n", stage);
+
+ switch (stage) {
+ case TEST_STAGE_REG_IFACE:
+ test_fw_regs_after_vm_start(vm);
+ break;
+ case TEST_STAGE_HVC_IFACE_FEAT_DISABLED:
+ /* Start a new VM so that all the features are now enabled by default */
+ kvm_vm_free(vm);
+ ret_vm = test_vm_create();
+ break;
+ case TEST_STAGE_HVC_IFACE_FEAT_ENABLED:
+ case TEST_STAGE_HVC_IFACE_FALSE_INFO:
+ break;
+ default:
+ TEST_FAIL("Unknown test stage: %d\n", stage);
+ }
+
+ stage++;
+ sync_global_to_guest(vm, stage);
+
+ return ret_vm;
+}
+
+static void test_run(void)
+{
+ struct kvm_vm *vm;
+ struct ucall uc;
+ bool guest_done = false;
+
+ vm = test_vm_create();
+
+ test_fw_regs_before_vm_start(vm);
+
+ while (!guest_done) {
+ vcpu_run(vm, 0);
+
+ switch (get_ucall(vm, 0, &uc)) {
+ case UCALL_SYNC:
+ vm = test_guest_stage(vm);
+ break;
+ case UCALL_DONE:
+ guest_done = true;
+ break;
+ case UCALL_ABORT:
+ TEST_FAIL("%s at %s:%ld\n\tvalues: 0x%lx, 0x%lx; 0x%lx, stage: %u",
+ (const char *)uc.args[0], __FILE__, uc.args[1],
+ uc.args[2], uc.args[3], uc.args[4], stage);
+ break;
+ default:
+ TEST_FAIL("Unexpected guest exit\n");
+ }
+ }
+
+ kvm_vm_free(vm);
+}
+
+int main(void)
+{
+ setbuf(stdout, NULL);
+
+ test_run();
+ return 0;
+}
--
2.35.1.473.g83b2b277ed-goog
^ permalink raw reply related [flat|nested] 117+ messages in thread* [PATCH v4 11/13] selftests: KVM: aarch64: Introduce hypercall ABI test
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: Paolo Bonzini, Catalin Marinas, Will Deacon, Peter Shier,
Ricardo Koller, Oliver Upton, Reiji Watanabe, Jing Zhang,
Raghavendra Rao Anata, linux-arm-kernel, kvmarm, linux-kernel,
kvm
Introduce a KVM selftest to check the hypercall interface
for arm64 platforms. The test validates the user-space's
IOCTL interface to read/write the psuedo-firmware registers
as well as its effects on the guest upon certain configurations.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
tools/testing/selftests/kvm/.gitignore | 1 +
tools/testing/selftests/kvm/Makefile | 1 +
.../selftests/kvm/aarch64/hypercalls.c | 376 ++++++++++++++++++
3 files changed, 378 insertions(+)
create mode 100644 tools/testing/selftests/kvm/aarch64/hypercalls.c
diff --git a/tools/testing/selftests/kvm/.gitignore b/tools/testing/selftests/kvm/.gitignore
index ac69108d9ffd..f13c33fcd733 100644
--- a/tools/testing/selftests/kvm/.gitignore
+++ b/tools/testing/selftests/kvm/.gitignore
@@ -2,6 +2,7 @@
/aarch64/arch_timer
/aarch64/debug-exceptions
/aarch64/get-reg-list
+/aarch64/hypercalls
/aarch64/psci_test
/aarch64/vgic_init
/aarch64/vgic_irq
diff --git a/tools/testing/selftests/kvm/Makefile b/tools/testing/selftests/kvm/Makefile
index 2a27c09b22ae..2181bdd5b09c 100644
--- a/tools/testing/selftests/kvm/Makefile
+++ b/tools/testing/selftests/kvm/Makefile
@@ -102,6 +102,7 @@ TEST_GEN_PROGS_x86_64 += system_counter_offset_test
TEST_GEN_PROGS_aarch64 += aarch64/arch_timer
TEST_GEN_PROGS_aarch64 += aarch64/debug-exceptions
TEST_GEN_PROGS_aarch64 += aarch64/get-reg-list
+TEST_GEN_PROGS_aarch64 += aarch64/hypercalls
TEST_GEN_PROGS_aarch64 += aarch64/psci_test
TEST_GEN_PROGS_aarch64 += aarch64/vgic_init
TEST_GEN_PROGS_aarch64 += aarch64/vgic_irq
diff --git a/tools/testing/selftests/kvm/aarch64/hypercalls.c b/tools/testing/selftests/kvm/aarch64/hypercalls.c
new file mode 100644
index 000000000000..e4e3a286ff3e
--- /dev/null
+++ b/tools/testing/selftests/kvm/aarch64/hypercalls.c
@@ -0,0 +1,376 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+/* hypercalls: Check the ARM64's psuedo-firmware bitmap register interface.
+ *
+ * The test validates the basic hypercall functionalities that are exposed
+ * via the psuedo-firmware bitmap register. This includes the registers'
+ * read/write behavior before and after the VM has started, and if the
+ * hypercalls are properly masked or unmasked to the guest when disabled or
+ * enabled from the KVM userspace, respectively.
+ */
+
+#include <errno.h>
+#include <linux/arm-smccc.h>
+#include <asm/kvm.h>
+#include <kvm_util.h>
+
+#include "processor.h"
+
+#define FW_REG_ULIMIT_VAL(max_feat_bit) (GENMASK_ULL(max_feat_bit, 0))
+
+struct kvm_fw_reg_info {
+ uint64_t reg; /* Register definition */
+ uint64_t max_feat_bit; /* Bit that represents the upper limit of the feature-map */
+};
+
+#define FW_REG_INFO(r, bit_max) \
+ { \
+ .reg = r, \
+ .max_feat_bit = bit_max, \
+ }
+
+static const struct kvm_fw_reg_info fw_reg_info[] = {
+ FW_REG_INFO(KVM_REG_ARM_STD_BMAP, KVM_REG_ARM_STD_BMAP_BIT_MAX),
+ FW_REG_INFO(KVM_REG_ARM_STD_HYP_BMAP, KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX),
+ FW_REG_INFO(KVM_REG_ARM_VENDOR_HYP_BMAP, KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX),
+};
+
+enum test_stage {
+ TEST_STAGE_REG_IFACE,
+ TEST_STAGE_HVC_IFACE_FEAT_DISABLED,
+ TEST_STAGE_HVC_IFACE_FEAT_ENABLED,
+ TEST_STAGE_HVC_IFACE_FALSE_INFO,
+ TEST_STAGE_END,
+};
+
+static int stage;
+
+struct test_hvc_info {
+ uint32_t func_id;
+ int64_t arg0;
+
+ void (*test_hvc_disabled)(const struct test_hvc_info *hc_info,
+ struct arm_smccc_res *res);
+ void (*test_hvc_enabled)(const struct test_hvc_info *hc_info,
+ struct arm_smccc_res *res);
+};
+
+#define TEST_HVC_INFO(f, a0, test_disabled, test_enabled) \
+ { \
+ .func_id = f, \
+ .arg0 = a0, \
+ .test_hvc_disabled = test_disabled, \
+ .test_hvc_enabled = test_enabled, \
+ }
+
+static void
+test_ptp_feat_hvc_disabled(const struct test_hvc_info *hc_info, struct arm_smccc_res *res)
+{
+ GUEST_ASSERT_3((res->a0 & BIT(ARM_SMCCC_KVM_FUNC_PTP)) == 0,
+ res->a0, hc_info->func_id, hc_info->arg0);
+}
+
+static void
+test_ptp_feat_hvc_enabled(const struct test_hvc_info *hc_info, struct arm_smccc_res *res)
+{
+ GUEST_ASSERT_3((res->a0 & BIT(ARM_SMCCC_KVM_FUNC_PTP)) != 0,
+ res->a0, hc_info->func_id, hc_info->arg0);
+}
+
+static const struct test_hvc_info hvc_info[] = {
+ /* KVM_REG_ARM_STD_BMAP: KVM_REG_ARM_STD_BIT_TRNG_V1_0 */
+ TEST_HVC_INFO(ARM_SMCCC_TRNG_VERSION, 0, NULL, NULL),
+ TEST_HVC_INFO(ARM_SMCCC_TRNG_FEATURES, ARM_SMCCC_TRNG_RND64, NULL, NULL),
+ TEST_HVC_INFO(ARM_SMCCC_TRNG_GET_UUID, 0, NULL, NULL),
+ TEST_HVC_INFO(ARM_SMCCC_TRNG_RND32, 0, NULL, NULL),
+ TEST_HVC_INFO(ARM_SMCCC_TRNG_RND64, 0, NULL, NULL),
+
+ /* KVM_REG_ARM_STD_HYP_BMAP: KVM_REG_ARM_STD_HYP_BIT_PV_TIME */
+ TEST_HVC_INFO(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
+ ARM_SMCCC_HV_PV_TIME_FEATURES, NULL, NULL),
+ TEST_HVC_INFO(ARM_SMCCC_HV_PV_TIME_FEATURES,
+ ARM_SMCCC_HV_PV_TIME_ST, NULL, NULL),
+ TEST_HVC_INFO(ARM_SMCCC_HV_PV_TIME_ST, 0, NULL, NULL),
+
+ /* KVM_REG_ARM_VENDOR_HYP_BMAP: KVM_REG_ARM_VENDOR_HYP_BIT_PTP */
+ TEST_HVC_INFO(ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID,
+ ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID,
+ test_ptp_feat_hvc_disabled, test_ptp_feat_hvc_enabled),
+ TEST_HVC_INFO(ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID,
+ KVM_PTP_VIRT_COUNTER, NULL, NULL),
+};
+
+/* Feed false hypercall info to test the KVM behavior */
+static const struct test_hvc_info false_hvc_info[] = {
+ /* Feature support check against a different family of hypercalls */
+ TEST_HVC_INFO(ARM_SMCCC_TRNG_FEATURES,
+ ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID, NULL, NULL),
+ TEST_HVC_INFO(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
+ ARM_SMCCC_TRNG_RND64, NULL, NULL),
+ TEST_HVC_INFO(ARM_SMCCC_HV_PV_TIME_FEATURES,
+ ARM_SMCCC_TRNG_RND64, NULL, NULL),
+};
+
+static void guest_test_hvc(const struct test_hvc_info *hc_info)
+{
+ unsigned int i;
+ struct arm_smccc_res res;
+ unsigned int hvc_info_arr_sz;
+
+ hvc_info_arr_sz =
+ hc_info == hvc_info ? ARRAY_SIZE(hvc_info) : ARRAY_SIZE(false_hvc_info);
+
+ for (i = 0; i < hvc_info_arr_sz; i++, hc_info++) {
+
+ memset(&res, 0, sizeof(res));
+ smccc_hvc(hc_info->func_id, hc_info->arg0, 0, 0, 0, 0, 0, 0, &res);
+
+ switch (stage) {
+ case TEST_STAGE_HVC_IFACE_FEAT_DISABLED:
+ if (hc_info->test_hvc_disabled)
+ hc_info->test_hvc_disabled(hc_info, &res);
+ else
+ GUEST_ASSERT_3(res.a0 == SMCCC_RET_NOT_SUPPORTED,
+ res.a0, hc_info->func_id, hc_info->arg0);
+ break;
+ case TEST_STAGE_HVC_IFACE_FEAT_ENABLED:
+ if (hc_info->test_hvc_enabled)
+ hc_info->test_hvc_enabled(hc_info, &res);
+ else
+ GUEST_ASSERT_3(res.a0 != SMCCC_RET_NOT_SUPPORTED,
+ res.a0, hc_info->func_id, hc_info->arg0);
+ break;
+ case TEST_STAGE_HVC_IFACE_FALSE_INFO:
+ GUEST_ASSERT_3(res.a0 == SMCCC_RET_NOT_SUPPORTED,
+ res.a0, hc_info->func_id, hc_info->arg0);
+ break;
+ default:
+ GUEST_ASSERT_1(0, stage);
+ }
+ }
+}
+
+static void guest_code(void)
+{
+ while (stage != TEST_STAGE_END) {
+ switch (stage) {
+ case TEST_STAGE_REG_IFACE:
+ break;
+ case TEST_STAGE_HVC_IFACE_FEAT_DISABLED:
+ case TEST_STAGE_HVC_IFACE_FEAT_ENABLED:
+ guest_test_hvc(hvc_info);
+ break;
+ case TEST_STAGE_HVC_IFACE_FALSE_INFO:
+ guest_test_hvc(false_hvc_info);
+ break;
+ default:
+ GUEST_ASSERT_1(0, stage);
+ }
+
+ GUEST_SYNC(stage);
+ }
+
+ GUEST_DONE();
+}
+
+static int set_fw_reg(struct kvm_vm *vm, uint64_t id, uint64_t val)
+{
+ struct kvm_one_reg reg = {
+ .id = KVM_REG_ARM_FW_REG(id),
+ .addr = (uint64_t)&val,
+ };
+
+ return _vcpu_ioctl(vm, 0, KVM_SET_ONE_REG, ®);
+}
+
+static void get_fw_reg(struct kvm_vm *vm, uint64_t id, uint64_t *addr)
+{
+ struct kvm_one_reg reg = {
+ .id = KVM_REG_ARM_FW_REG(id),
+ .addr = (uint64_t)addr,
+ };
+
+ return vcpu_ioctl(vm, 0, KVM_GET_ONE_REG, ®);
+}
+
+struct st_time {
+ uint32_t rev;
+ uint32_t attr;
+ uint64_t st_time;
+};
+
+#define STEAL_TIME_SIZE ((sizeof(struct st_time) + 63) & ~63)
+#define ST_GPA_BASE (1 << 30)
+
+static void steal_time_init(struct kvm_vm *vm)
+{
+ uint64_t st_ipa = (ulong)ST_GPA_BASE;
+ unsigned int gpages;
+ struct kvm_device_attr dev = {
+ .group = KVM_ARM_VCPU_PVTIME_CTRL,
+ .attr = KVM_ARM_VCPU_PVTIME_IPA,
+ .addr = (uint64_t)&st_ipa,
+ };
+
+ gpages = vm_calc_num_guest_pages(VM_MODE_DEFAULT, STEAL_TIME_SIZE);
+ vm_userspace_mem_region_add(vm, VM_MEM_SRC_ANONYMOUS, ST_GPA_BASE, 1, gpages, 0);
+
+ vcpu_ioctl(vm, 0, KVM_SET_DEVICE_ATTR, &dev);
+}
+
+static void test_fw_regs_before_vm_start(struct kvm_vm *vm)
+{
+ uint64_t val;
+ unsigned int i;
+ int ret;
+
+ for (i = 0; i < ARRAY_SIZE(fw_reg_info); i++) {
+ const struct kvm_fw_reg_info *reg_info = &fw_reg_info[i];
+
+ /* First read should be an upper limit of the features supported */
+ get_fw_reg(vm, reg_info->reg, &val);
+ TEST_ASSERT(val == FW_REG_ULIMIT_VAL(reg_info->max_feat_bit),
+ "Expected all the features to be set for reg: 0x%lx; expected: 0x%llx; read: 0x%lx\n",
+ reg_info->reg, GENMASK_ULL(reg_info->max_feat_bit, 0), val);
+
+ /* Test 'write' by disabling all the features of the register map */
+ ret = set_fw_reg(vm, reg_info->reg, 0);
+ TEST_ASSERT(ret == 0,
+ "Failed to clear all the features of reg: 0x%lx; ret: %d\n",
+ reg_info->reg, errno);
+
+ get_fw_reg(vm, reg_info->reg, &val);
+ TEST_ASSERT(val == 0,
+ "Expected all the features to be cleared for reg: 0x%lx\n", reg_info->reg);
+
+ /*
+ * Test enabling a feature that's not supported.
+ * Avoid this check if all the bits are occupied.
+ */
+ if (reg_info->max_feat_bit < 63) {
+ ret = set_fw_reg(vm, reg_info->reg, BIT(reg_info->max_feat_bit + 1));
+ TEST_ASSERT(ret != 0 && errno == EINVAL,
+ "Unexpected behavior or return value (%d) while setting an unsupported feature for reg: 0x%lx\n",
+ errno, reg_info->reg);
+ }
+ }
+}
+
+static void test_fw_regs_after_vm_start(struct kvm_vm *vm)
+{
+ uint64_t val;
+ unsigned int i;
+ int ret;
+
+ for (i = 0; i < ARRAY_SIZE(fw_reg_info); i++) {
+ const struct kvm_fw_reg_info *reg_info = &fw_reg_info[i];
+
+ /*
+ * Before starting the VM, the test clears all the bits.
+ * Check if that's still the case.
+ */
+ get_fw_reg(vm, reg_info->reg, &val);
+ TEST_ASSERT(val == 0,
+ "Expected all the features to be cleared for reg: 0x%lx\n",
+ reg_info->reg);
+
+ /*
+ * Test setting the last read value. KVM should allow this
+ * even if VM has started running.
+ */
+ ret = set_fw_reg(vm, reg_info->reg, val);
+ TEST_ASSERT(ret == 0,
+ "Failed to set the register with previously read value after Vm start for reg: 0x%lx; ret: %d\n",
+ reg_info->reg, errno);
+
+ /*
+ * Set all the features for this register again. KVM shouldn't
+ * allow this as the VM is running.
+ */
+ ret = set_fw_reg(vm, reg_info->reg, FW_REG_ULIMIT_VAL(reg_info->max_feat_bit));
+ TEST_ASSERT(ret != 0 && errno == EBUSY,
+ "Unexpected behavior or return value (%d) while setting a feature while VM is running for reg: 0x%lx\n",
+ errno, reg_info->reg);
+ }
+}
+
+static struct kvm_vm *test_vm_create(void)
+{
+ struct kvm_vm *vm;
+
+ vm = vm_create_default(0, 0, guest_code);
+
+ ucall_init(vm, NULL);
+ steal_time_init(vm);
+
+ return vm;
+}
+
+static struct kvm_vm *test_guest_stage(struct kvm_vm *vm)
+{
+ struct kvm_vm *ret_vm = vm;
+
+ pr_debug("Stage: %d\n", stage);
+
+ switch (stage) {
+ case TEST_STAGE_REG_IFACE:
+ test_fw_regs_after_vm_start(vm);
+ break;
+ case TEST_STAGE_HVC_IFACE_FEAT_DISABLED:
+ /* Start a new VM so that all the features are now enabled by default */
+ kvm_vm_free(vm);
+ ret_vm = test_vm_create();
+ break;
+ case TEST_STAGE_HVC_IFACE_FEAT_ENABLED:
+ case TEST_STAGE_HVC_IFACE_FALSE_INFO:
+ break;
+ default:
+ TEST_FAIL("Unknown test stage: %d\n", stage);
+ }
+
+ stage++;
+ sync_global_to_guest(vm, stage);
+
+ return ret_vm;
+}
+
+static void test_run(void)
+{
+ struct kvm_vm *vm;
+ struct ucall uc;
+ bool guest_done = false;
+
+ vm = test_vm_create();
+
+ test_fw_regs_before_vm_start(vm);
+
+ while (!guest_done) {
+ vcpu_run(vm, 0);
+
+ switch (get_ucall(vm, 0, &uc)) {
+ case UCALL_SYNC:
+ vm = test_guest_stage(vm);
+ break;
+ case UCALL_DONE:
+ guest_done = true;
+ break;
+ case UCALL_ABORT:
+ TEST_FAIL("%s at %s:%ld\n\tvalues: 0x%lx, 0x%lx; 0x%lx, stage: %u",
+ (const char *)uc.args[0], __FILE__, uc.args[1],
+ uc.args[2], uc.args[3], uc.args[4], stage);
+ break;
+ default:
+ TEST_FAIL("Unexpected guest exit\n");
+ }
+ }
+
+ kvm_vm_free(vm);
+}
+
+int main(void)
+{
+ setbuf(stdout, NULL);
+
+ test_run();
+ return 0;
+}
--
2.35.1.473.g83b2b277ed-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 117+ messages in thread
* [PATCH v4 12/13] selftests: KVM: aarch64: hypercalls: Test with KVM_CAP_ARM_REG_SCOPE
2022-02-24 17:25 ` Raghavendra Rao Ananta
(?)
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
-1 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: kvm, Catalin Marinas, Peter Shier, linux-kernel, Paolo Bonzini,
Will Deacon, kvmarm, linux-arm-kernel
Upgrade the aarch64/hypercalls test to also consider the
firmware register's scope information. Thus, run the test
with the capability KVM_CAP_ARM_REG_SCOPE disabled and enabled.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
.../selftests/kvm/aarch64/hypercalls.c | 83 +++++++++++++++++--
1 file changed, 75 insertions(+), 8 deletions(-)
diff --git a/tools/testing/selftests/kvm/aarch64/hypercalls.c b/tools/testing/selftests/kvm/aarch64/hypercalls.c
index e4e3a286ff3e..85818b91b4fb 100644
--- a/tools/testing/selftests/kvm/aarch64/hypercalls.c
+++ b/tools/testing/selftests/kvm/aarch64/hypercalls.c
@@ -29,7 +29,7 @@ struct kvm_fw_reg_info {
.max_feat_bit = bit_max, \
}
-static const struct kvm_fw_reg_info fw_reg_info[] = {
+static struct kvm_fw_reg_info fw_reg_info[] = {
FW_REG_INFO(KVM_REG_ARM_STD_BMAP, KVM_REG_ARM_STD_BMAP_BIT_MAX),
FW_REG_INFO(KVM_REG_ARM_STD_HYP_BMAP, KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX),
FW_REG_INFO(KVM_REG_ARM_VENDOR_HYP_BMAP, KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX),
@@ -294,19 +294,78 @@ static void test_fw_regs_after_vm_start(struct kvm_vm *vm)
}
}
-static struct kvm_vm *test_vm_create(void)
+static bool test_reg_is_bmap_fw_reg(uint64_t reg)
+{
+ if ((reg & KVM_REG_ARM_COPROC_MASK) == KVM_REG_ARM_FW &&
+ (reg & 0xffff) >= 0xff00) /* Bitmap firmware register space */
+ return true;
+
+ return false;
+}
+
+static void test_fw_regs_encode_vm_scope(void)
+{
+ int i;
+
+ /*
+ * Encode the scope as KVM_REG_ARM_SCOPE_VM for further use
+ * in KVM_SET_ONE_REG and KVM_GET_ONE_REG operations.
+ */
+ for (i = 0; i < ARRAY_SIZE(fw_reg_info); i++)
+ fw_reg_info[i].reg |= (KVM_REG_ARM_SCOPE_VM << KVM_REG_ARM_SCOPE_SHIFT);
+}
+
+static void test_validate_fw_regs(struct kvm_vm *vm, int scope)
+{
+ uint64_t i, reg;
+ int obtained_scope;
+ struct kvm_reg_list *reg_list;
+
+ reg_list = vcpu_get_reg_list(vm, 0);
+
+ for (i = 0; i < reg_list->n; i++) {
+ reg = reg_list->reg[i];
+ if (!test_reg_is_bmap_fw_reg(reg))
+ continue;
+
+ /*
+ * Depending on KVM_CAP_ARM_REG_SCOPE, currently all the firmware
+ * bitmap registers are either completely VM-scoped or vCPU scoped.
+ */
+ obtained_scope = (reg & KVM_REG_ARM_SCOPE_MASK) >> KVM_REG_ARM_SCOPE_SHIFT;
+ TEST_ASSERT(obtained_scope == scope,
+ "Incorrect scope detected for reg: %lx. Expected: %d; Obtained: %d\n",
+ reg, scope, obtained_scope);
+ }
+}
+
+static struct kvm_vm *test_vm_create(int scope)
{
struct kvm_vm *vm;
+ struct kvm_enable_cap reg_scope_cap = {
+ .cap = KVM_CAP_ARM_REG_SCOPE,
+ };
+
+ if (scope == KVM_REG_ARM_SCOPE_VM && !kvm_check_cap(KVM_CAP_ARM_REG_SCOPE)) {
+ print_skip("Capability KVM_CAP_ARM_REG_SCOPE unavailable\n");
+ return NULL;
+ }
vm = vm_create_default(0, 0, guest_code);
ucall_init(vm, NULL);
steal_time_init(vm);
+ if (scope == KVM_REG_ARM_SCOPE_VM) {
+ vm_enable_cap(vm, ®_scope_cap);
+ test_fw_regs_encode_vm_scope();
+ }
+
return vm;
}
-static struct kvm_vm *test_guest_stage(struct kvm_vm *vm)
+static struct kvm_vm *
+test_guest_stage(struct kvm_vm *vm, int scope)
{
struct kvm_vm *ret_vm = vm;
@@ -319,7 +378,7 @@ static struct kvm_vm *test_guest_stage(struct kvm_vm *vm)
case TEST_STAGE_HVC_IFACE_FEAT_DISABLED:
/* Start a new VM so that all the features are now enabled by default */
kvm_vm_free(vm);
- ret_vm = test_vm_create();
+ ret_vm = test_vm_create(scope);
break;
case TEST_STAGE_HVC_IFACE_FEAT_ENABLED:
case TEST_STAGE_HVC_IFACE_FALSE_INFO:
@@ -334,14 +393,20 @@ static struct kvm_vm *test_guest_stage(struct kvm_vm *vm)
return ret_vm;
}
-static void test_run(void)
+static void test_run(int scope)
{
struct kvm_vm *vm;
struct ucall uc;
bool guest_done = false;
- vm = test_vm_create();
+ vm = test_vm_create(scope);
+ if (!vm)
+ return;
+ stage = TEST_STAGE_REG_IFACE;
+ sync_global_to_guest(vm, stage);
+
+ test_validate_fw_regs(vm, scope);
test_fw_regs_before_vm_start(vm);
while (!guest_done) {
@@ -349,7 +414,7 @@ static void test_run(void)
switch (get_ucall(vm, 0, &uc)) {
case UCALL_SYNC:
- vm = test_guest_stage(vm);
+ vm = test_guest_stage(vm, scope);
break;
case UCALL_DONE:
guest_done = true;
@@ -371,6 +436,8 @@ int main(void)
{
setbuf(stdout, NULL);
- test_run();
+ test_run(KVM_REG_ARM_SCOPE_VCPU);
+ test_run(KVM_REG_ARM_SCOPE_VM);
+
return 0;
}
--
2.35.1.473.g83b2b277ed-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 117+ messages in thread* [PATCH v4 12/13] selftests: KVM: aarch64: hypercalls: Test with KVM_CAP_ARM_REG_SCOPE
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: Paolo Bonzini, Catalin Marinas, Will Deacon, Peter Shier,
Ricardo Koller, Oliver Upton, Reiji Watanabe, Jing Zhang,
Raghavendra Rao Anata, linux-arm-kernel, kvmarm, linux-kernel,
kvm
Upgrade the aarch64/hypercalls test to also consider the
firmware register's scope information. Thus, run the test
with the capability KVM_CAP_ARM_REG_SCOPE disabled and enabled.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
.../selftests/kvm/aarch64/hypercalls.c | 83 +++++++++++++++++--
1 file changed, 75 insertions(+), 8 deletions(-)
diff --git a/tools/testing/selftests/kvm/aarch64/hypercalls.c b/tools/testing/selftests/kvm/aarch64/hypercalls.c
index e4e3a286ff3e..85818b91b4fb 100644
--- a/tools/testing/selftests/kvm/aarch64/hypercalls.c
+++ b/tools/testing/selftests/kvm/aarch64/hypercalls.c
@@ -29,7 +29,7 @@ struct kvm_fw_reg_info {
.max_feat_bit = bit_max, \
}
-static const struct kvm_fw_reg_info fw_reg_info[] = {
+static struct kvm_fw_reg_info fw_reg_info[] = {
FW_REG_INFO(KVM_REG_ARM_STD_BMAP, KVM_REG_ARM_STD_BMAP_BIT_MAX),
FW_REG_INFO(KVM_REG_ARM_STD_HYP_BMAP, KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX),
FW_REG_INFO(KVM_REG_ARM_VENDOR_HYP_BMAP, KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX),
@@ -294,19 +294,78 @@ static void test_fw_regs_after_vm_start(struct kvm_vm *vm)
}
}
-static struct kvm_vm *test_vm_create(void)
+static bool test_reg_is_bmap_fw_reg(uint64_t reg)
+{
+ if ((reg & KVM_REG_ARM_COPROC_MASK) == KVM_REG_ARM_FW &&
+ (reg & 0xffff) >= 0xff00) /* Bitmap firmware register space */
+ return true;
+
+ return false;
+}
+
+static void test_fw_regs_encode_vm_scope(void)
+{
+ int i;
+
+ /*
+ * Encode the scope as KVM_REG_ARM_SCOPE_VM for further use
+ * in KVM_SET_ONE_REG and KVM_GET_ONE_REG operations.
+ */
+ for (i = 0; i < ARRAY_SIZE(fw_reg_info); i++)
+ fw_reg_info[i].reg |= (KVM_REG_ARM_SCOPE_VM << KVM_REG_ARM_SCOPE_SHIFT);
+}
+
+static void test_validate_fw_regs(struct kvm_vm *vm, int scope)
+{
+ uint64_t i, reg;
+ int obtained_scope;
+ struct kvm_reg_list *reg_list;
+
+ reg_list = vcpu_get_reg_list(vm, 0);
+
+ for (i = 0; i < reg_list->n; i++) {
+ reg = reg_list->reg[i];
+ if (!test_reg_is_bmap_fw_reg(reg))
+ continue;
+
+ /*
+ * Depending on KVM_CAP_ARM_REG_SCOPE, currently all the firmware
+ * bitmap registers are either completely VM-scoped or vCPU scoped.
+ */
+ obtained_scope = (reg & KVM_REG_ARM_SCOPE_MASK) >> KVM_REG_ARM_SCOPE_SHIFT;
+ TEST_ASSERT(obtained_scope == scope,
+ "Incorrect scope detected for reg: %lx. Expected: %d; Obtained: %d\n",
+ reg, scope, obtained_scope);
+ }
+}
+
+static struct kvm_vm *test_vm_create(int scope)
{
struct kvm_vm *vm;
+ struct kvm_enable_cap reg_scope_cap = {
+ .cap = KVM_CAP_ARM_REG_SCOPE,
+ };
+
+ if (scope == KVM_REG_ARM_SCOPE_VM && !kvm_check_cap(KVM_CAP_ARM_REG_SCOPE)) {
+ print_skip("Capability KVM_CAP_ARM_REG_SCOPE unavailable\n");
+ return NULL;
+ }
vm = vm_create_default(0, 0, guest_code);
ucall_init(vm, NULL);
steal_time_init(vm);
+ if (scope == KVM_REG_ARM_SCOPE_VM) {
+ vm_enable_cap(vm, ®_scope_cap);
+ test_fw_regs_encode_vm_scope();
+ }
+
return vm;
}
-static struct kvm_vm *test_guest_stage(struct kvm_vm *vm)
+static struct kvm_vm *
+test_guest_stage(struct kvm_vm *vm, int scope)
{
struct kvm_vm *ret_vm = vm;
@@ -319,7 +378,7 @@ static struct kvm_vm *test_guest_stage(struct kvm_vm *vm)
case TEST_STAGE_HVC_IFACE_FEAT_DISABLED:
/* Start a new VM so that all the features are now enabled by default */
kvm_vm_free(vm);
- ret_vm = test_vm_create();
+ ret_vm = test_vm_create(scope);
break;
case TEST_STAGE_HVC_IFACE_FEAT_ENABLED:
case TEST_STAGE_HVC_IFACE_FALSE_INFO:
@@ -334,14 +393,20 @@ static struct kvm_vm *test_guest_stage(struct kvm_vm *vm)
return ret_vm;
}
-static void test_run(void)
+static void test_run(int scope)
{
struct kvm_vm *vm;
struct ucall uc;
bool guest_done = false;
- vm = test_vm_create();
+ vm = test_vm_create(scope);
+ if (!vm)
+ return;
+ stage = TEST_STAGE_REG_IFACE;
+ sync_global_to_guest(vm, stage);
+
+ test_validate_fw_regs(vm, scope);
test_fw_regs_before_vm_start(vm);
while (!guest_done) {
@@ -349,7 +414,7 @@ static void test_run(void)
switch (get_ucall(vm, 0, &uc)) {
case UCALL_SYNC:
- vm = test_guest_stage(vm);
+ vm = test_guest_stage(vm, scope);
break;
case UCALL_DONE:
guest_done = true;
@@ -371,6 +436,8 @@ int main(void)
{
setbuf(stdout, NULL);
- test_run();
+ test_run(KVM_REG_ARM_SCOPE_VCPU);
+ test_run(KVM_REG_ARM_SCOPE_VM);
+
return 0;
}
--
2.35.1.473.g83b2b277ed-goog
^ permalink raw reply related [flat|nested] 117+ messages in thread* [PATCH v4 12/13] selftests: KVM: aarch64: hypercalls: Test with KVM_CAP_ARM_REG_SCOPE
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: Paolo Bonzini, Catalin Marinas, Will Deacon, Peter Shier,
Ricardo Koller, Oliver Upton, Reiji Watanabe, Jing Zhang,
Raghavendra Rao Anata, linux-arm-kernel, kvmarm, linux-kernel,
kvm
Upgrade the aarch64/hypercalls test to also consider the
firmware register's scope information. Thus, run the test
with the capability KVM_CAP_ARM_REG_SCOPE disabled and enabled.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
.../selftests/kvm/aarch64/hypercalls.c | 83 +++++++++++++++++--
1 file changed, 75 insertions(+), 8 deletions(-)
diff --git a/tools/testing/selftests/kvm/aarch64/hypercalls.c b/tools/testing/selftests/kvm/aarch64/hypercalls.c
index e4e3a286ff3e..85818b91b4fb 100644
--- a/tools/testing/selftests/kvm/aarch64/hypercalls.c
+++ b/tools/testing/selftests/kvm/aarch64/hypercalls.c
@@ -29,7 +29,7 @@ struct kvm_fw_reg_info {
.max_feat_bit = bit_max, \
}
-static const struct kvm_fw_reg_info fw_reg_info[] = {
+static struct kvm_fw_reg_info fw_reg_info[] = {
FW_REG_INFO(KVM_REG_ARM_STD_BMAP, KVM_REG_ARM_STD_BMAP_BIT_MAX),
FW_REG_INFO(KVM_REG_ARM_STD_HYP_BMAP, KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX),
FW_REG_INFO(KVM_REG_ARM_VENDOR_HYP_BMAP, KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX),
@@ -294,19 +294,78 @@ static void test_fw_regs_after_vm_start(struct kvm_vm *vm)
}
}
-static struct kvm_vm *test_vm_create(void)
+static bool test_reg_is_bmap_fw_reg(uint64_t reg)
+{
+ if ((reg & KVM_REG_ARM_COPROC_MASK) == KVM_REG_ARM_FW &&
+ (reg & 0xffff) >= 0xff00) /* Bitmap firmware register space */
+ return true;
+
+ return false;
+}
+
+static void test_fw_regs_encode_vm_scope(void)
+{
+ int i;
+
+ /*
+ * Encode the scope as KVM_REG_ARM_SCOPE_VM for further use
+ * in KVM_SET_ONE_REG and KVM_GET_ONE_REG operations.
+ */
+ for (i = 0; i < ARRAY_SIZE(fw_reg_info); i++)
+ fw_reg_info[i].reg |= (KVM_REG_ARM_SCOPE_VM << KVM_REG_ARM_SCOPE_SHIFT);
+}
+
+static void test_validate_fw_regs(struct kvm_vm *vm, int scope)
+{
+ uint64_t i, reg;
+ int obtained_scope;
+ struct kvm_reg_list *reg_list;
+
+ reg_list = vcpu_get_reg_list(vm, 0);
+
+ for (i = 0; i < reg_list->n; i++) {
+ reg = reg_list->reg[i];
+ if (!test_reg_is_bmap_fw_reg(reg))
+ continue;
+
+ /*
+ * Depending on KVM_CAP_ARM_REG_SCOPE, currently all the firmware
+ * bitmap registers are either completely VM-scoped or vCPU scoped.
+ */
+ obtained_scope = (reg & KVM_REG_ARM_SCOPE_MASK) >> KVM_REG_ARM_SCOPE_SHIFT;
+ TEST_ASSERT(obtained_scope == scope,
+ "Incorrect scope detected for reg: %lx. Expected: %d; Obtained: %d\n",
+ reg, scope, obtained_scope);
+ }
+}
+
+static struct kvm_vm *test_vm_create(int scope)
{
struct kvm_vm *vm;
+ struct kvm_enable_cap reg_scope_cap = {
+ .cap = KVM_CAP_ARM_REG_SCOPE,
+ };
+
+ if (scope == KVM_REG_ARM_SCOPE_VM && !kvm_check_cap(KVM_CAP_ARM_REG_SCOPE)) {
+ print_skip("Capability KVM_CAP_ARM_REG_SCOPE unavailable\n");
+ return NULL;
+ }
vm = vm_create_default(0, 0, guest_code);
ucall_init(vm, NULL);
steal_time_init(vm);
+ if (scope == KVM_REG_ARM_SCOPE_VM) {
+ vm_enable_cap(vm, ®_scope_cap);
+ test_fw_regs_encode_vm_scope();
+ }
+
return vm;
}
-static struct kvm_vm *test_guest_stage(struct kvm_vm *vm)
+static struct kvm_vm *
+test_guest_stage(struct kvm_vm *vm, int scope)
{
struct kvm_vm *ret_vm = vm;
@@ -319,7 +378,7 @@ static struct kvm_vm *test_guest_stage(struct kvm_vm *vm)
case TEST_STAGE_HVC_IFACE_FEAT_DISABLED:
/* Start a new VM so that all the features are now enabled by default */
kvm_vm_free(vm);
- ret_vm = test_vm_create();
+ ret_vm = test_vm_create(scope);
break;
case TEST_STAGE_HVC_IFACE_FEAT_ENABLED:
case TEST_STAGE_HVC_IFACE_FALSE_INFO:
@@ -334,14 +393,20 @@ static struct kvm_vm *test_guest_stage(struct kvm_vm *vm)
return ret_vm;
}
-static void test_run(void)
+static void test_run(int scope)
{
struct kvm_vm *vm;
struct ucall uc;
bool guest_done = false;
- vm = test_vm_create();
+ vm = test_vm_create(scope);
+ if (!vm)
+ return;
+ stage = TEST_STAGE_REG_IFACE;
+ sync_global_to_guest(vm, stage);
+
+ test_validate_fw_regs(vm, scope);
test_fw_regs_before_vm_start(vm);
while (!guest_done) {
@@ -349,7 +414,7 @@ static void test_run(void)
switch (get_ucall(vm, 0, &uc)) {
case UCALL_SYNC:
- vm = test_guest_stage(vm);
+ vm = test_guest_stage(vm, scope);
break;
case UCALL_DONE:
guest_done = true;
@@ -371,6 +436,8 @@ int main(void)
{
setbuf(stdout, NULL);
- test_run();
+ test_run(KVM_REG_ARM_SCOPE_VCPU);
+ test_run(KVM_REG_ARM_SCOPE_VM);
+
return 0;
}
--
2.35.1.473.g83b2b277ed-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 117+ messages in thread
* [PATCH v4 13/13] selftests: KVM: aarch64: Add the bitmap firmware registers to get-reg-list
2022-02-24 17:25 ` Raghavendra Rao Ananta
(?)
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
-1 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: kvm, Catalin Marinas, Peter Shier, linux-kernel, Paolo Bonzini,
Will Deacon, kvmarm, linux-arm-kernel
Add the psuedo-firmware registers KVM_REG_ARM_STD_BMAP,
KVM_REG_ARM_STD_HYP_BMAP, and KVM_REG_ARM_VENDOR_HYP_BMAP to
the base_regs[] list.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
tools/testing/selftests/kvm/aarch64/get-reg-list.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/testing/selftests/kvm/aarch64/get-reg-list.c b/tools/testing/selftests/kvm/aarch64/get-reg-list.c
index f769fc6cd927..42e613a7bb6a 100644
--- a/tools/testing/selftests/kvm/aarch64/get-reg-list.c
+++ b/tools/testing/selftests/kvm/aarch64/get-reg-list.c
@@ -686,6 +686,9 @@ static __u64 base_regs[] = {
KVM_REG_ARM_FW_REG(0),
KVM_REG_ARM_FW_REG(1),
KVM_REG_ARM_FW_REG(2),
+ KVM_REG_ARM_FW_BMAP_REG(0), /* KVM_REG_ARM_STD_BMAP */
+ KVM_REG_ARM_FW_BMAP_REG(1), /* KVM_REG_ARM_STD_HYP_BMAP */
+ KVM_REG_ARM_FW_BMAP_REG(2), /* KVM_REG_ARM_VENDOR_HYP_BMAP */
ARM64_SYS_REG(3, 3, 14, 3, 1), /* CNTV_CTL_EL0 */
ARM64_SYS_REG(3, 3, 14, 3, 2), /* CNTV_CVAL_EL0 */
ARM64_SYS_REG(3, 3, 14, 0, 2),
--
2.35.1.473.g83b2b277ed-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 117+ messages in thread* [PATCH v4 13/13] selftests: KVM: aarch64: Add the bitmap firmware registers to get-reg-list
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: Paolo Bonzini, Catalin Marinas, Will Deacon, Peter Shier,
Ricardo Koller, Oliver Upton, Reiji Watanabe, Jing Zhang,
Raghavendra Rao Anata, linux-arm-kernel, kvmarm, linux-kernel,
kvm
Add the psuedo-firmware registers KVM_REG_ARM_STD_BMAP,
KVM_REG_ARM_STD_HYP_BMAP, and KVM_REG_ARM_VENDOR_HYP_BMAP to
the base_regs[] list.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
tools/testing/selftests/kvm/aarch64/get-reg-list.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/testing/selftests/kvm/aarch64/get-reg-list.c b/tools/testing/selftests/kvm/aarch64/get-reg-list.c
index f769fc6cd927..42e613a7bb6a 100644
--- a/tools/testing/selftests/kvm/aarch64/get-reg-list.c
+++ b/tools/testing/selftests/kvm/aarch64/get-reg-list.c
@@ -686,6 +686,9 @@ static __u64 base_regs[] = {
KVM_REG_ARM_FW_REG(0),
KVM_REG_ARM_FW_REG(1),
KVM_REG_ARM_FW_REG(2),
+ KVM_REG_ARM_FW_BMAP_REG(0), /* KVM_REG_ARM_STD_BMAP */
+ KVM_REG_ARM_FW_BMAP_REG(1), /* KVM_REG_ARM_STD_HYP_BMAP */
+ KVM_REG_ARM_FW_BMAP_REG(2), /* KVM_REG_ARM_VENDOR_HYP_BMAP */
ARM64_SYS_REG(3, 3, 14, 3, 1), /* CNTV_CTL_EL0 */
ARM64_SYS_REG(3, 3, 14, 3, 2), /* CNTV_CVAL_EL0 */
ARM64_SYS_REG(3, 3, 14, 0, 2),
--
2.35.1.473.g83b2b277ed-goog
^ permalink raw reply related [flat|nested] 117+ messages in thread* [PATCH v4 13/13] selftests: KVM: aarch64: Add the bitmap firmware registers to get-reg-list
@ 2022-02-24 17:25 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-24 17:25 UTC (permalink / raw)
To: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose
Cc: Paolo Bonzini, Catalin Marinas, Will Deacon, Peter Shier,
Ricardo Koller, Oliver Upton, Reiji Watanabe, Jing Zhang,
Raghavendra Rao Anata, linux-arm-kernel, kvmarm, linux-kernel,
kvm
Add the psuedo-firmware registers KVM_REG_ARM_STD_BMAP,
KVM_REG_ARM_STD_HYP_BMAP, and KVM_REG_ARM_VENDOR_HYP_BMAP to
the base_regs[] list.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
---
tools/testing/selftests/kvm/aarch64/get-reg-list.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/testing/selftests/kvm/aarch64/get-reg-list.c b/tools/testing/selftests/kvm/aarch64/get-reg-list.c
index f769fc6cd927..42e613a7bb6a 100644
--- a/tools/testing/selftests/kvm/aarch64/get-reg-list.c
+++ b/tools/testing/selftests/kvm/aarch64/get-reg-list.c
@@ -686,6 +686,9 @@ static __u64 base_regs[] = {
KVM_REG_ARM_FW_REG(0),
KVM_REG_ARM_FW_REG(1),
KVM_REG_ARM_FW_REG(2),
+ KVM_REG_ARM_FW_BMAP_REG(0), /* KVM_REG_ARM_STD_BMAP */
+ KVM_REG_ARM_FW_BMAP_REG(1), /* KVM_REG_ARM_STD_HYP_BMAP */
+ KVM_REG_ARM_FW_BMAP_REG(2), /* KVM_REG_ARM_VENDOR_HYP_BMAP */
ARM64_SYS_REG(3, 3, 14, 3, 1), /* CNTV_CTL_EL0 */
ARM64_SYS_REG(3, 3, 14, 3, 2), /* CNTV_CVAL_EL0 */
ARM64_SYS_REG(3, 3, 14, 0, 2),
--
2.35.1.473.g83b2b277ed-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 117+ messages in thread* Re: [PATCH v4 13/13] selftests: KVM: aarch64: Add the bitmap firmware registers to get-reg-list
2022-02-24 17:25 ` Raghavendra Rao Ananta
(?)
@ 2022-03-14 20:02 ` Oliver Upton
-1 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-14 20:02 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: kvm, Will Deacon, Marc Zyngier, Peter Shier, linux-kernel,
Catalin Marinas, Paolo Bonzini, kvmarm, linux-arm-kernel
On Thu, Feb 24, 2022 at 05:25:59PM +0000, Raghavendra Rao Ananta wrote:
> Add the psuedo-firmware registers KVM_REG_ARM_STD_BMAP,
> KVM_REG_ARM_STD_HYP_BMAP, and KVM_REG_ARM_VENDOR_HYP_BMAP to
> the base_regs[] list.
>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
Reviewed-by: Oliver Upton <oupton@google.com>
> ---
> tools/testing/selftests/kvm/aarch64/get-reg-list.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/tools/testing/selftests/kvm/aarch64/get-reg-list.c b/tools/testing/selftests/kvm/aarch64/get-reg-list.c
> index f769fc6cd927..42e613a7bb6a 100644
> --- a/tools/testing/selftests/kvm/aarch64/get-reg-list.c
> +++ b/tools/testing/selftests/kvm/aarch64/get-reg-list.c
> @@ -686,6 +686,9 @@ static __u64 base_regs[] = {
> KVM_REG_ARM_FW_REG(0),
> KVM_REG_ARM_FW_REG(1),
> KVM_REG_ARM_FW_REG(2),
> + KVM_REG_ARM_FW_BMAP_REG(0), /* KVM_REG_ARM_STD_BMAP */
> + KVM_REG_ARM_FW_BMAP_REG(1), /* KVM_REG_ARM_STD_HYP_BMAP */
> + KVM_REG_ARM_FW_BMAP_REG(2), /* KVM_REG_ARM_VENDOR_HYP_BMAP */
> ARM64_SYS_REG(3, 3, 14, 3, 1), /* CNTV_CTL_EL0 */
> ARM64_SYS_REG(3, 3, 14, 3, 2), /* CNTV_CVAL_EL0 */
> ARM64_SYS_REG(3, 3, 14, 0, 2),
> --
> 2.35.1.473.g83b2b277ed-goog
>
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 13/13] selftests: KVM: aarch64: Add the bitmap firmware registers to get-reg-list
@ 2022-03-14 20:02 ` Oliver Upton
0 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-14 20:02 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Thu, Feb 24, 2022 at 05:25:59PM +0000, Raghavendra Rao Ananta wrote:
> Add the psuedo-firmware registers KVM_REG_ARM_STD_BMAP,
> KVM_REG_ARM_STD_HYP_BMAP, and KVM_REG_ARM_VENDOR_HYP_BMAP to
> the base_regs[] list.
>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
Reviewed-by: Oliver Upton <oupton@google.com>
> ---
> tools/testing/selftests/kvm/aarch64/get-reg-list.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/tools/testing/selftests/kvm/aarch64/get-reg-list.c b/tools/testing/selftests/kvm/aarch64/get-reg-list.c
> index f769fc6cd927..42e613a7bb6a 100644
> --- a/tools/testing/selftests/kvm/aarch64/get-reg-list.c
> +++ b/tools/testing/selftests/kvm/aarch64/get-reg-list.c
> @@ -686,6 +686,9 @@ static __u64 base_regs[] = {
> KVM_REG_ARM_FW_REG(0),
> KVM_REG_ARM_FW_REG(1),
> KVM_REG_ARM_FW_REG(2),
> + KVM_REG_ARM_FW_BMAP_REG(0), /* KVM_REG_ARM_STD_BMAP */
> + KVM_REG_ARM_FW_BMAP_REG(1), /* KVM_REG_ARM_STD_HYP_BMAP */
> + KVM_REG_ARM_FW_BMAP_REG(2), /* KVM_REG_ARM_VENDOR_HYP_BMAP */
> ARM64_SYS_REG(3, 3, 14, 3, 1), /* CNTV_CTL_EL0 */
> ARM64_SYS_REG(3, 3, 14, 3, 2), /* CNTV_CVAL_EL0 */
> ARM64_SYS_REG(3, 3, 14, 0, 2),
> --
> 2.35.1.473.g83b2b277ed-goog
>
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 13/13] selftests: KVM: aarch64: Add the bitmap firmware registers to get-reg-list
@ 2022-03-14 20:02 ` Oliver Upton
0 siblings, 0 replies; 117+ messages in thread
From: Oliver Upton @ 2022-03-14 20:02 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm
On Thu, Feb 24, 2022 at 05:25:59PM +0000, Raghavendra Rao Ananta wrote:
> Add the psuedo-firmware registers KVM_REG_ARM_STD_BMAP,
> KVM_REG_ARM_STD_HYP_BMAP, and KVM_REG_ARM_VENDOR_HYP_BMAP to
> the base_regs[] list.
>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
Reviewed-by: Oliver Upton <oupton@google.com>
> ---
> tools/testing/selftests/kvm/aarch64/get-reg-list.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/tools/testing/selftests/kvm/aarch64/get-reg-list.c b/tools/testing/selftests/kvm/aarch64/get-reg-list.c
> index f769fc6cd927..42e613a7bb6a 100644
> --- a/tools/testing/selftests/kvm/aarch64/get-reg-list.c
> +++ b/tools/testing/selftests/kvm/aarch64/get-reg-list.c
> @@ -686,6 +686,9 @@ static __u64 base_regs[] = {
> KVM_REG_ARM_FW_REG(0),
> KVM_REG_ARM_FW_REG(1),
> KVM_REG_ARM_FW_REG(2),
> + KVM_REG_ARM_FW_BMAP_REG(0), /* KVM_REG_ARM_STD_BMAP */
> + KVM_REG_ARM_FW_BMAP_REG(1), /* KVM_REG_ARM_STD_HYP_BMAP */
> + KVM_REG_ARM_FW_BMAP_REG(2), /* KVM_REG_ARM_VENDOR_HYP_BMAP */
> ARM64_SYS_REG(3, 3, 14, 3, 1), /* CNTV_CTL_EL0 */
> ARM64_SYS_REG(3, 3, 14, 3, 2), /* CNTV_CVAL_EL0 */
> ARM64_SYS_REG(3, 3, 14, 0, 2),
> --
> 2.35.1.473.g83b2b277ed-goog
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: [PATCH v4 02/13] KVM: arm64: Introduce KVM_CAP_ARM_REG_SCOPE
@ 2022-02-28 19:46 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-28 19:46 UTC (permalink / raw)
To: Oliver Upton
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm, kvm-riscv, kvm-ia64,
kvm-ppc
On Fri, Feb 25, 2022 at 10:26 AM Oliver Upton <oupton@google.com> wrote:
>
> On Fri, Feb 25, 2022 at 09:34:35AM -0800, Raghavendra Rao Ananta wrote:
> > Hey Oliver,
> >
> > On Thu, Feb 24, 2022 at 10:43 PM Oliver Upton <oupton@google.com> wrote:
> > >
> > > On Thu, Feb 24, 2022 at 05:25:48PM +0000, Raghavendra Rao Ananta wrote:
> > > > KVM_[GET|SET]_ONE_REG act on per-vCPU basis. Currently certain
> > > > ARM64 registers, such as KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_[1|2],
> > > > are accessed via this interface even though the effect that
> > > > they have are really per-VM. As a result, userspace could just
> > > > waste cycles to read/write the same information for every vCPU
> > > > that it spawns, only to realize that there's absolutely no change
> > > > in the VM's state. The problem gets worse in proportion to the
> > > > number of vCPUs created.
> > > >
> > > > As a result, to avoid this redundancy, introduce the capability
> > > > KVM_CAP_ARM_REG_SCOPE. If enabled, KVM_GET_REG_LIST will advertise
> > > > the registers that are VM-scoped by dynamically modifying the
> > > > register encoding. KVM_REG_ARM_SCOPE_* helper macros are introduced
> > > > to decode the same. By learning this, userspace can access such
> > > > registers only once.
> > > >
> > > > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > > > ---
> > > > Documentation/virt/kvm/api.rst | 16 ++++++++++++++++
> > > > arch/arm64/include/asm/kvm_host.h | 3 +++
> > > > arch/arm64/include/uapi/asm/kvm.h | 6 ++++++
> > > > arch/arm64/kvm/arm.c | 13 +++++++------
> > > > include/uapi/linux/kvm.h | 1 +
> > > > 5 files changed, 33 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> > > > index a4267104db50..7e7b3439f540 100644
> > > > --- a/Documentation/virt/kvm/api.rst
> > > > +++ b/Documentation/virt/kvm/api.rst
> > > > @@ -7561,3 +7561,19 @@ The argument to KVM_ENABLE_CAP is also a bitmask, and must be a subset
> > > > of the result of KVM_CHECK_EXTENSION. KVM will forward to userspace
> > > > the hypercalls whose corresponding bit is in the argument, and return
> > > > ENOSYS for the others.
> > > > +
> > > > +8.34 KVM_CAP_ARM_REG_SCOPE
> > > > +--------------------------
> > > > +
> > > > +:Architectures: arm64
> > > > +
> > > > +The capability, if enabled, amends the existing register encoding
> > > > +with additional information to the userspace if a particular register
> > > > +is scoped per-vCPU or per-VM via KVM_GET_REG_LIST. KVM provides
> > > > +KVM_REG_ARM_SCOPE_* helper macros to decode the same. Userspace can
> > > > +use this information from the register encoding to access a VM-scopped
> > > > +regiser only once, as opposed to accessing it for every vCPU for the
> > > > +same effect.
> > > > +
> > >
> > > Could you describe the encoding changes in 4.68 'KVM_SET_ONE_REG', along
> > > with the other ARM encoding details?
> > >
> > > > +On the other hand, if the capability is disabled, all the registers
> > > > +remain vCPU-scopped by default, retaining backward compatibility.
> > >
> > > typo: vCPU-scoped
> > >
> > > That said, I don't believe we need to document behavior if the CAP is
> > > disabled, as the implicated ioctls should continue to work the same.
> > >
> > Sure, I'll address the above two Doc comments.
> > > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > > > index 5bc01e62c08a..8132de6bd718 100644
> > > > --- a/arch/arm64/include/asm/kvm_host.h
> > > > +++ b/arch/arm64/include/asm/kvm_host.h
> > > > @@ -136,6 +136,9 @@ struct kvm_arch {
> > > >
> > > > /* Memory Tagging Extension enabled for the guest */
> > > > bool mte_enabled;
> > > > +
> > > > + /* Register scoping enabled for KVM registers */
> > > > + bool reg_scope_enabled;
> > > > };
> > > >
> > > > struct kvm_vcpu_fault_info {
> > > > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > > > index b3edde68bc3e..c35447cc0e0c 100644
> > > > --- a/arch/arm64/include/uapi/asm/kvm.h
> > > > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > > > @@ -199,6 +199,12 @@ struct kvm_arm_copy_mte_tags {
> > > > #define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000
> > > > #define KVM_REG_ARM_COPROC_SHIFT 16
> > > >
> > > > +/* Defines if a KVM register is one per-vCPU or one per-VM */
> > > > +#define KVM_REG_ARM_SCOPE_MASK 0x0000000010000000
> > > > +#define KVM_REG_ARM_SCOPE_SHIFT 28
> > >
> > > Thinking about the advertisement of VM- and vCPU-scoped registers, this
> > > could be generally useful. Might it make sense to add such an encoding
> > > to the arch-generic register definitions?
> > >
> > > If that is the case, we may want to snap up a few more bits (a nybble)
> > > for future expansion.
> > >
> > That's a great idea! But I wonder if we'll get a push-back since there
> > are no users of it in other arch(s) yet. Not sure if there was any
> > need/discussion regarding the same, but I'm happy to share a patch for
> > the same if you sense that there's a strong potential for the patch.
> >
>
> I'm unsure if this is actually of interest to other architectures, it
> just doesn't seem ARM-specific so we should probably raise the question
> so we only grab these bits once.
>
I've CC'ed a few more arch-specific kvm lists for
comments/concerns/suggestions on the idea (feel free to add any other
relevant groups/persons). Based on the response, I can start an
independent RFC series for the same.
> > > > +#define KVM_REG_ARM_SCOPE_VCPU 0
> > > > +#define KVM_REG_ARM_SCOPE_VM 1
> > > > +
> > > > /* Normal registers are mapped as coprocessor 16. */
> > > > #define KVM_REG_ARM_CORE (0x0010 << KVM_REG_ARM_COPROC_SHIFT)
> > > > #define KVM_REG_ARM_CORE_REG(name) (offsetof(struct kvm_regs, name) / sizeof(__u32))
> > > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > > > index ecc5958e27fe..107977c82c6c 100644
> > > > --- a/arch/arm64/kvm/arm.c
> > > > +++ b/arch/arm64/kvm/arm.c
> > > > @@ -81,26 +81,26 @@ int kvm_arch_check_processor_compat(void *opaque)
> > > > int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
> > > > struct kvm_enable_cap *cap)
> > > > {
> > > > - int r;
> > > > + int r = 0;
> > > >
> > > > if (cap->flags)
> > > > return -EINVAL;
> > > >
> > > > switch (cap->cap) {
> > > > case KVM_CAP_ARM_NISV_TO_USER:
> > > > - r = 0;
> > > > kvm->arch.return_nisv_io_abort_to_user = true;
> > > > break;
> > > > case KVM_CAP_ARM_MTE:
> > > > mutex_lock(&kvm->lock);
> > > > - if (!system_supports_mte() || kvm->created_vcpus) {
> > > > + if (!system_supports_mte() || kvm->created_vcpus)
> > > > r = -EINVAL;
> > > > - } else {
> > > > - r = 0;
> > > > + else
> > > > kvm->arch.mte_enabled = true;
> > > > - }
> > > > mutex_unlock(&kvm->lock);
> > > > break;
> > >
> > > Hmm.. these all look like cleanups. If you want to propose these, could
> > > you do it in a separate patch?
> > >
> > Ahh, I thought I could squeeze it in. But sure, I can separate it out.
> > > > + case KVM_CAP_ARM_REG_SCOPE:
> > > > + WRITE_ONCE(kvm->arch.reg_scope_enabled, true);
> > > > + break;
> > > > default:
> > > > r = -EINVAL;
> > > > break;
> > > > @@ -209,6 +209,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> > > > case KVM_CAP_SET_GUEST_DEBUG:
> > > > case KVM_CAP_VCPU_ATTRIBUTES:
> > > > case KVM_CAP_PTP_KVM:
> > > > + case KVM_CAP_ARM_REG_SCOPE:
> > >
> > > It is a bit odd to advertise a capability (and allow userspace to enable
> > > it), despite the fact that the feature itself hasn't yet been
> > > implemented.
> > >
> > > Is it possible to fold the feature in to the patch that exposes it to
> > > userspace? Otherwise, you could punt advertisement of the CAP until it
> > > is actually implemented in kernel.
> > >
> > Well, I didn't want to complicate the patch, but technically the
> > feature is available with this patch, including all the CAP and macro
> > definitions. Userspace can still decode the scope information, only
> > that no registers are added yet, which is done in the next patch. So,
> > the userspace can still remain the same between this and the next
> > patch.
>
> But the series isn't cleanly bisectable. There will exist commits in
> history that report KVM_CAP_ARM_REG_SCOPE as implemented even though
> that is not actually the case. You should really only advertise support
> to userspace when the feature is implemented.
>
> Defining kvm->arch.reg_scope_enabled can be done earlier so you have a
> bit to test and guard all of the new code, and only expose the CAP in
> the last patch of the series.
>
Got it. I'll arrange that in the next spin.
> Also, as an FYI Marc has a patch that I'll be picking up in my own
> series which uses bits instead of bools to keep track of certain
> VM-wide features:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=kvm-arm64/mmu/guest-MMIO-guard&id=7dd0a13a4217b870f2e83cdc6045e5ce482a5340
>
Thanks. This is great. I can steal a couple of bits and implement the
flags introduced in the series here.
> Marc, if neither of our series land in 5.18 could you at least submit
> this patch in preparation? Should keep conflicts minimal that way.
>
> Thanks!
>
> --
> Oliver
Thank you.
Raghavendra
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 02/13] KVM: arm64: Introduce KVM_CAP_ARM_REG_SCOPE
@ 2022-02-28 19:46 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-28 19:46 UTC (permalink / raw)
To: Oliver Upton
Cc: Marc Zyngier, Andrew Jones, James Morse, Alexandru Elisei,
Suzuki K Poulose, Paolo Bonzini, Catalin Marinas, Will Deacon,
Peter Shier, Ricardo Koller, Reiji Watanabe, Jing Zhang,
linux-arm-kernel, kvmarm, linux-kernel, kvm, kvm-riscv, kvm-ia64,
kvm-ppc
On Fri, Feb 25, 2022 at 10:26 AM Oliver Upton <oupton@google.com> wrote:
>
> On Fri, Feb 25, 2022 at 09:34:35AM -0800, Raghavendra Rao Ananta wrote:
> > Hey Oliver,
> >
> > On Thu, Feb 24, 2022 at 10:43 PM Oliver Upton <oupton@google.com> wrote:
> > >
> > > On Thu, Feb 24, 2022 at 05:25:48PM +0000, Raghavendra Rao Ananta wrote:
> > > > KVM_[GET|SET]_ONE_REG act on per-vCPU basis. Currently certain
> > > > ARM64 registers, such as KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_[1|2],
> > > > are accessed via this interface even though the effect that
> > > > they have are really per-VM. As a result, userspace could just
> > > > waste cycles to read/write the same information for every vCPU
> > > > that it spawns, only to realize that there's absolutely no change
> > > > in the VM's state. The problem gets worse in proportion to the
> > > > number of vCPUs created.
> > > >
> > > > As a result, to avoid this redundancy, introduce the capability
> > > > KVM_CAP_ARM_REG_SCOPE. If enabled, KVM_GET_REG_LIST will advertise
> > > > the registers that are VM-scoped by dynamically modifying the
> > > > register encoding. KVM_REG_ARM_SCOPE_* helper macros are introduced
> > > > to decode the same. By learning this, userspace can access such
> > > > registers only once.
> > > >
> > > > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > > > ---
> > > > Documentation/virt/kvm/api.rst | 16 ++++++++++++++++
> > > > arch/arm64/include/asm/kvm_host.h | 3 +++
> > > > arch/arm64/include/uapi/asm/kvm.h | 6 ++++++
> > > > arch/arm64/kvm/arm.c | 13 +++++++------
> > > > include/uapi/linux/kvm.h | 1 +
> > > > 5 files changed, 33 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> > > > index a4267104db50..7e7b3439f540 100644
> > > > --- a/Documentation/virt/kvm/api.rst
> > > > +++ b/Documentation/virt/kvm/api.rst
> > > > @@ -7561,3 +7561,19 @@ The argument to KVM_ENABLE_CAP is also a bitmask, and must be a subset
> > > > of the result of KVM_CHECK_EXTENSION. KVM will forward to userspace
> > > > the hypercalls whose corresponding bit is in the argument, and return
> > > > ENOSYS for the others.
> > > > +
> > > > +8.34 KVM_CAP_ARM_REG_SCOPE
> > > > +--------------------------
> > > > +
> > > > +:Architectures: arm64
> > > > +
> > > > +The capability, if enabled, amends the existing register encoding
> > > > +with additional information to the userspace if a particular register
> > > > +is scoped per-vCPU or per-VM via KVM_GET_REG_LIST. KVM provides
> > > > +KVM_REG_ARM_SCOPE_* helper macros to decode the same. Userspace can
> > > > +use this information from the register encoding to access a VM-scopped
> > > > +regiser only once, as opposed to accessing it for every vCPU for the
> > > > +same effect.
> > > > +
> > >
> > > Could you describe the encoding changes in 4.68 'KVM_SET_ONE_REG', along
> > > with the other ARM encoding details?
> > >
> > > > +On the other hand, if the capability is disabled, all the registers
> > > > +remain vCPU-scopped by default, retaining backward compatibility.
> > >
> > > typo: vCPU-scoped
> > >
> > > That said, I don't believe we need to document behavior if the CAP is
> > > disabled, as the implicated ioctls should continue to work the same.
> > >
> > Sure, I'll address the above two Doc comments.
> > > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > > > index 5bc01e62c08a..8132de6bd718 100644
> > > > --- a/arch/arm64/include/asm/kvm_host.h
> > > > +++ b/arch/arm64/include/asm/kvm_host.h
> > > > @@ -136,6 +136,9 @@ struct kvm_arch {
> > > >
> > > > /* Memory Tagging Extension enabled for the guest */
> > > > bool mte_enabled;
> > > > +
> > > > + /* Register scoping enabled for KVM registers */
> > > > + bool reg_scope_enabled;
> > > > };
> > > >
> > > > struct kvm_vcpu_fault_info {
> > > > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > > > index b3edde68bc3e..c35447cc0e0c 100644
> > > > --- a/arch/arm64/include/uapi/asm/kvm.h
> > > > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > > > @@ -199,6 +199,12 @@ struct kvm_arm_copy_mte_tags {
> > > > #define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000
> > > > #define KVM_REG_ARM_COPROC_SHIFT 16
> > > >
> > > > +/* Defines if a KVM register is one per-vCPU or one per-VM */
> > > > +#define KVM_REG_ARM_SCOPE_MASK 0x0000000010000000
> > > > +#define KVM_REG_ARM_SCOPE_SHIFT 28
> > >
> > > Thinking about the advertisement of VM- and vCPU-scoped registers, this
> > > could be generally useful. Might it make sense to add such an encoding
> > > to the arch-generic register definitions?
> > >
> > > If that is the case, we may want to snap up a few more bits (a nybble)
> > > for future expansion.
> > >
> > That's a great idea! But I wonder if we'll get a push-back since there
> > are no users of it in other arch(s) yet. Not sure if there was any
> > need/discussion regarding the same, but I'm happy to share a patch for
> > the same if you sense that there's a strong potential for the patch.
> >
>
> I'm unsure if this is actually of interest to other architectures, it
> just doesn't seem ARM-specific so we should probably raise the question
> so we only grab these bits once.
>
I've CC'ed a few more arch-specific kvm lists for
comments/concerns/suggestions on the idea (feel free to add any other
relevant groups/persons). Based on the response, I can start an
independent RFC series for the same.
> > > > +#define KVM_REG_ARM_SCOPE_VCPU 0
> > > > +#define KVM_REG_ARM_SCOPE_VM 1
> > > > +
> > > > /* Normal registers are mapped as coprocessor 16. */
> > > > #define KVM_REG_ARM_CORE (0x0010 << KVM_REG_ARM_COPROC_SHIFT)
> > > > #define KVM_REG_ARM_CORE_REG(name) (offsetof(struct kvm_regs, name) / sizeof(__u32))
> > > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > > > index ecc5958e27fe..107977c82c6c 100644
> > > > --- a/arch/arm64/kvm/arm.c
> > > > +++ b/arch/arm64/kvm/arm.c
> > > > @@ -81,26 +81,26 @@ int kvm_arch_check_processor_compat(void *opaque)
> > > > int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
> > > > struct kvm_enable_cap *cap)
> > > > {
> > > > - int r;
> > > > + int r = 0;
> > > >
> > > > if (cap->flags)
> > > > return -EINVAL;
> > > >
> > > > switch (cap->cap) {
> > > > case KVM_CAP_ARM_NISV_TO_USER:
> > > > - r = 0;
> > > > kvm->arch.return_nisv_io_abort_to_user = true;
> > > > break;
> > > > case KVM_CAP_ARM_MTE:
> > > > mutex_lock(&kvm->lock);
> > > > - if (!system_supports_mte() || kvm->created_vcpus) {
> > > > + if (!system_supports_mte() || kvm->created_vcpus)
> > > > r = -EINVAL;
> > > > - } else {
> > > > - r = 0;
> > > > + else
> > > > kvm->arch.mte_enabled = true;
> > > > - }
> > > > mutex_unlock(&kvm->lock);
> > > > break;
> > >
> > > Hmm.. these all look like cleanups. If you want to propose these, could
> > > you do it in a separate patch?
> > >
> > Ahh, I thought I could squeeze it in. But sure, I can separate it out.
> > > > + case KVM_CAP_ARM_REG_SCOPE:
> > > > + WRITE_ONCE(kvm->arch.reg_scope_enabled, true);
> > > > + break;
> > > > default:
> > > > r = -EINVAL;
> > > > break;
> > > > @@ -209,6 +209,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> > > > case KVM_CAP_SET_GUEST_DEBUG:
> > > > case KVM_CAP_VCPU_ATTRIBUTES:
> > > > case KVM_CAP_PTP_KVM:
> > > > + case KVM_CAP_ARM_REG_SCOPE:
> > >
> > > It is a bit odd to advertise a capability (and allow userspace to enable
> > > it), despite the fact that the feature itself hasn't yet been
> > > implemented.
> > >
> > > Is it possible to fold the feature in to the patch that exposes it to
> > > userspace? Otherwise, you could punt advertisement of the CAP until it
> > > is actually implemented in kernel.
> > >
> > Well, I didn't want to complicate the patch, but technically the
> > feature is available with this patch, including all the CAP and macro
> > definitions. Userspace can still decode the scope information, only
> > that no registers are added yet, which is done in the next patch. So,
> > the userspace can still remain the same between this and the next
> > patch.
>
> But the series isn't cleanly bisectable. There will exist commits in
> history that report KVM_CAP_ARM_REG_SCOPE as implemented even though
> that is not actually the case. You should really only advertise support
> to userspace when the feature is implemented.
>
> Defining kvm->arch.reg_scope_enabled can be done earlier so you have a
> bit to test and guard all of the new code, and only expose the CAP in
> the last patch of the series.
>
Got it. I'll arrange that in the next spin.
> Also, as an FYI Marc has a patch that I'll be picking up in my own
> series which uses bits instead of bools to keep track of certain
> VM-wide features:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=kvm-arm64/mmu/guest-MMIO-guard&id=7dd0a13a4217b870f2e83cdc6045e5ce482a5340
>
Thanks. This is great. I can steal a couple of bits and implement the
flags introduced in the series here.
> Marc, if neither of our series land in 5.18 could you at least submit
> this patch in preparation? Should keep conflicts minimal that way.
>
> Thanks!
>
> --
> Oliver
Thank you.
Raghavendra
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 02/13] KVM: arm64: Introduce KVM_CAP_ARM_REG_SCOPE
@ 2022-02-28 19:46 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-28 19:46 UTC (permalink / raw)
To: Oliver Upton
Cc: kvm, Will Deacon, kvm-ia64, Marc Zyngier, Peter Shier,
linux-kernel, kvm-ppc, kvm-riscv, Catalin Marinas, Paolo Bonzini,
kvmarm, linux-arm-kernel
On Fri, Feb 25, 2022 at 10:26 AM Oliver Upton <oupton@google.com> wrote:
>
> On Fri, Feb 25, 2022 at 09:34:35AM -0800, Raghavendra Rao Ananta wrote:
> > Hey Oliver,
> >
> > On Thu, Feb 24, 2022 at 10:43 PM Oliver Upton <oupton@google.com> wrote:
> > >
> > > On Thu, Feb 24, 2022 at 05:25:48PM +0000, Raghavendra Rao Ananta wrote:
> > > > KVM_[GET|SET]_ONE_REG act on per-vCPU basis. Currently certain
> > > > ARM64 registers, such as KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_[1|2],
> > > > are accessed via this interface even though the effect that
> > > > they have are really per-VM. As a result, userspace could just
> > > > waste cycles to read/write the same information for every vCPU
> > > > that it spawns, only to realize that there's absolutely no change
> > > > in the VM's state. The problem gets worse in proportion to the
> > > > number of vCPUs created.
> > > >
> > > > As a result, to avoid this redundancy, introduce the capability
> > > > KVM_CAP_ARM_REG_SCOPE. If enabled, KVM_GET_REG_LIST will advertise
> > > > the registers that are VM-scoped by dynamically modifying the
> > > > register encoding. KVM_REG_ARM_SCOPE_* helper macros are introduced
> > > > to decode the same. By learning this, userspace can access such
> > > > registers only once.
> > > >
> > > > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > > > ---
> > > > Documentation/virt/kvm/api.rst | 16 ++++++++++++++++
> > > > arch/arm64/include/asm/kvm_host.h | 3 +++
> > > > arch/arm64/include/uapi/asm/kvm.h | 6 ++++++
> > > > arch/arm64/kvm/arm.c | 13 +++++++------
> > > > include/uapi/linux/kvm.h | 1 +
> > > > 5 files changed, 33 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> > > > index a4267104db50..7e7b3439f540 100644
> > > > --- a/Documentation/virt/kvm/api.rst
> > > > +++ b/Documentation/virt/kvm/api.rst
> > > > @@ -7561,3 +7561,19 @@ The argument to KVM_ENABLE_CAP is also a bitmask, and must be a subset
> > > > of the result of KVM_CHECK_EXTENSION. KVM will forward to userspace
> > > > the hypercalls whose corresponding bit is in the argument, and return
> > > > ENOSYS for the others.
> > > > +
> > > > +8.34 KVM_CAP_ARM_REG_SCOPE
> > > > +--------------------------
> > > > +
> > > > +:Architectures: arm64
> > > > +
> > > > +The capability, if enabled, amends the existing register encoding
> > > > +with additional information to the userspace if a particular register
> > > > +is scoped per-vCPU or per-VM via KVM_GET_REG_LIST. KVM provides
> > > > +KVM_REG_ARM_SCOPE_* helper macros to decode the same. Userspace can
> > > > +use this information from the register encoding to access a VM-scopped
> > > > +regiser only once, as opposed to accessing it for every vCPU for the
> > > > +same effect.
> > > > +
> > >
> > > Could you describe the encoding changes in 4.68 'KVM_SET_ONE_REG', along
> > > with the other ARM encoding details?
> > >
> > > > +On the other hand, if the capability is disabled, all the registers
> > > > +remain vCPU-scopped by default, retaining backward compatibility.
> > >
> > > typo: vCPU-scoped
> > >
> > > That said, I don't believe we need to document behavior if the CAP is
> > > disabled, as the implicated ioctls should continue to work the same.
> > >
> > Sure, I'll address the above two Doc comments.
> > > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > > > index 5bc01e62c08a..8132de6bd718 100644
> > > > --- a/arch/arm64/include/asm/kvm_host.h
> > > > +++ b/arch/arm64/include/asm/kvm_host.h
> > > > @@ -136,6 +136,9 @@ struct kvm_arch {
> > > >
> > > > /* Memory Tagging Extension enabled for the guest */
> > > > bool mte_enabled;
> > > > +
> > > > + /* Register scoping enabled for KVM registers */
> > > > + bool reg_scope_enabled;
> > > > };
> > > >
> > > > struct kvm_vcpu_fault_info {
> > > > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > > > index b3edde68bc3e..c35447cc0e0c 100644
> > > > --- a/arch/arm64/include/uapi/asm/kvm.h
> > > > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > > > @@ -199,6 +199,12 @@ struct kvm_arm_copy_mte_tags {
> > > > #define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000
> > > > #define KVM_REG_ARM_COPROC_SHIFT 16
> > > >
> > > > +/* Defines if a KVM register is one per-vCPU or one per-VM */
> > > > +#define KVM_REG_ARM_SCOPE_MASK 0x0000000010000000
> > > > +#define KVM_REG_ARM_SCOPE_SHIFT 28
> > >
> > > Thinking about the advertisement of VM- and vCPU-scoped registers, this
> > > could be generally useful. Might it make sense to add such an encoding
> > > to the arch-generic register definitions?
> > >
> > > If that is the case, we may want to snap up a few more bits (a nybble)
> > > for future expansion.
> > >
> > That's a great idea! But I wonder if we'll get a push-back since there
> > are no users of it in other arch(s) yet. Not sure if there was any
> > need/discussion regarding the same, but I'm happy to share a patch for
> > the same if you sense that there's a strong potential for the patch.
> >
>
> I'm unsure if this is actually of interest to other architectures, it
> just doesn't seem ARM-specific so we should probably raise the question
> so we only grab these bits once.
>
I've CC'ed a few more arch-specific kvm lists for
comments/concerns/suggestions on the idea (feel free to add any other
relevant groups/persons). Based on the response, I can start an
independent RFC series for the same.
> > > > +#define KVM_REG_ARM_SCOPE_VCPU 0
> > > > +#define KVM_REG_ARM_SCOPE_VM 1
> > > > +
> > > > /* Normal registers are mapped as coprocessor 16. */
> > > > #define KVM_REG_ARM_CORE (0x0010 << KVM_REG_ARM_COPROC_SHIFT)
> > > > #define KVM_REG_ARM_CORE_REG(name) (offsetof(struct kvm_regs, name) / sizeof(__u32))
> > > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > > > index ecc5958e27fe..107977c82c6c 100644
> > > > --- a/arch/arm64/kvm/arm.c
> > > > +++ b/arch/arm64/kvm/arm.c
> > > > @@ -81,26 +81,26 @@ int kvm_arch_check_processor_compat(void *opaque)
> > > > int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
> > > > struct kvm_enable_cap *cap)
> > > > {
> > > > - int r;
> > > > + int r = 0;
> > > >
> > > > if (cap->flags)
> > > > return -EINVAL;
> > > >
> > > > switch (cap->cap) {
> > > > case KVM_CAP_ARM_NISV_TO_USER:
> > > > - r = 0;
> > > > kvm->arch.return_nisv_io_abort_to_user = true;
> > > > break;
> > > > case KVM_CAP_ARM_MTE:
> > > > mutex_lock(&kvm->lock);
> > > > - if (!system_supports_mte() || kvm->created_vcpus) {
> > > > + if (!system_supports_mte() || kvm->created_vcpus)
> > > > r = -EINVAL;
> > > > - } else {
> > > > - r = 0;
> > > > + else
> > > > kvm->arch.mte_enabled = true;
> > > > - }
> > > > mutex_unlock(&kvm->lock);
> > > > break;
> > >
> > > Hmm.. these all look like cleanups. If you want to propose these, could
> > > you do it in a separate patch?
> > >
> > Ahh, I thought I could squeeze it in. But sure, I can separate it out.
> > > > + case KVM_CAP_ARM_REG_SCOPE:
> > > > + WRITE_ONCE(kvm->arch.reg_scope_enabled, true);
> > > > + break;
> > > > default:
> > > > r = -EINVAL;
> > > > break;
> > > > @@ -209,6 +209,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> > > > case KVM_CAP_SET_GUEST_DEBUG:
> > > > case KVM_CAP_VCPU_ATTRIBUTES:
> > > > case KVM_CAP_PTP_KVM:
> > > > + case KVM_CAP_ARM_REG_SCOPE:
> > >
> > > It is a bit odd to advertise a capability (and allow userspace to enable
> > > it), despite the fact that the feature itself hasn't yet been
> > > implemented.
> > >
> > > Is it possible to fold the feature in to the patch that exposes it to
> > > userspace? Otherwise, you could punt advertisement of the CAP until it
> > > is actually implemented in kernel.
> > >
> > Well, I didn't want to complicate the patch, but technically the
> > feature is available with this patch, including all the CAP and macro
> > definitions. Userspace can still decode the scope information, only
> > that no registers are added yet, which is done in the next patch. So,
> > the userspace can still remain the same between this and the next
> > patch.
>
> But the series isn't cleanly bisectable. There will exist commits in
> history that report KVM_CAP_ARM_REG_SCOPE as implemented even though
> that is not actually the case. You should really only advertise support
> to userspace when the feature is implemented.
>
> Defining kvm->arch.reg_scope_enabled can be done earlier so you have a
> bit to test and guard all of the new code, and only expose the CAP in
> the last patch of the series.
>
Got it. I'll arrange that in the next spin.
> Also, as an FYI Marc has a patch that I'll be picking up in my own
> series which uses bits instead of bools to keep track of certain
> VM-wide features:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=kvm-arm64/mmu/guest-MMIO-guard&id=7dd0a13a4217b870f2e83cdc6045e5ce482a5340
>
Thanks. This is great. I can steal a couple of bits and implement the
flags introduced in the series here.
> Marc, if neither of our series land in 5.18 could you at least submit
> this patch in preparation? Should keep conflicts minimal that way.
>
> Thanks!
>
> --
> Oliver
Thank you.
Raghavendra
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 117+ messages in thread* Re: [PATCH v4 02/13] KVM: arm64: Introduce KVM_CAP_ARM_REG_SCOPE
@ 2022-02-28 19:46 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-28 19:46 UTC (permalink / raw)
To: Oliver Upton
Cc: kvm, Will Deacon, kvm-ia64, Marc Zyngier, Peter Shier,
linux-kernel, kvm-ppc, kvm-riscv, Catalin Marinas, Paolo Bonzini,
kvmarm, linux-arm-kernel
On Fri, Feb 25, 2022 at 10:26 AM Oliver Upton <oupton@google.com> wrote:
>
> On Fri, Feb 25, 2022 at 09:34:35AM -0800, Raghavendra Rao Ananta wrote:
> > Hey Oliver,
> >
> > On Thu, Feb 24, 2022 at 10:43 PM Oliver Upton <oupton@google.com> wrote:
> > >
> > > On Thu, Feb 24, 2022 at 05:25:48PM +0000, Raghavendra Rao Ananta wrote:
> > > > KVM_[GET|SET]_ONE_REG act on per-vCPU basis. Currently certain
> > > > ARM64 registers, such as KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_[1|2],
> > > > are accessed via this interface even though the effect that
> > > > they have are really per-VM. As a result, userspace could just
> > > > waste cycles to read/write the same information for every vCPU
> > > > that it spawns, only to realize that there's absolutely no change
> > > > in the VM's state. The problem gets worse in proportion to the
> > > > number of vCPUs created.
> > > >
> > > > As a result, to avoid this redundancy, introduce the capability
> > > > KVM_CAP_ARM_REG_SCOPE. If enabled, KVM_GET_REG_LIST will advertise
> > > > the registers that are VM-scoped by dynamically modifying the
> > > > register encoding. KVM_REG_ARM_SCOPE_* helper macros are introduced
> > > > to decode the same. By learning this, userspace can access such
> > > > registers only once.
> > > >
> > > > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > > > ---
> > > > Documentation/virt/kvm/api.rst | 16 ++++++++++++++++
> > > > arch/arm64/include/asm/kvm_host.h | 3 +++
> > > > arch/arm64/include/uapi/asm/kvm.h | 6 ++++++
> > > > arch/arm64/kvm/arm.c | 13 +++++++------
> > > > include/uapi/linux/kvm.h | 1 +
> > > > 5 files changed, 33 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> > > > index a4267104db50..7e7b3439f540 100644
> > > > --- a/Documentation/virt/kvm/api.rst
> > > > +++ b/Documentation/virt/kvm/api.rst
> > > > @@ -7561,3 +7561,19 @@ The argument to KVM_ENABLE_CAP is also a bitmask, and must be a subset
> > > > of the result of KVM_CHECK_EXTENSION. KVM will forward to userspace
> > > > the hypercalls whose corresponding bit is in the argument, and return
> > > > ENOSYS for the others.
> > > > +
> > > > +8.34 KVM_CAP_ARM_REG_SCOPE
> > > > +--------------------------
> > > > +
> > > > +:Architectures: arm64
> > > > +
> > > > +The capability, if enabled, amends the existing register encoding
> > > > +with additional information to the userspace if a particular register
> > > > +is scoped per-vCPU or per-VM via KVM_GET_REG_LIST. KVM provides
> > > > +KVM_REG_ARM_SCOPE_* helper macros to decode the same. Userspace can
> > > > +use this information from the register encoding to access a VM-scopped
> > > > +regiser only once, as opposed to accessing it for every vCPU for the
> > > > +same effect.
> > > > +
> > >
> > > Could you describe the encoding changes in 4.68 'KVM_SET_ONE_REG', along
> > > with the other ARM encoding details?
> > >
> > > > +On the other hand, if the capability is disabled, all the registers
> > > > +remain vCPU-scopped by default, retaining backward compatibility.
> > >
> > > typo: vCPU-scoped
> > >
> > > That said, I don't believe we need to document behavior if the CAP is
> > > disabled, as the implicated ioctls should continue to work the same.
> > >
> > Sure, I'll address the above two Doc comments.
> > > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > > > index 5bc01e62c08a..8132de6bd718 100644
> > > > --- a/arch/arm64/include/asm/kvm_host.h
> > > > +++ b/arch/arm64/include/asm/kvm_host.h
> > > > @@ -136,6 +136,9 @@ struct kvm_arch {
> > > >
> > > > /* Memory Tagging Extension enabled for the guest */
> > > > bool mte_enabled;
> > > > +
> > > > + /* Register scoping enabled for KVM registers */
> > > > + bool reg_scope_enabled;
> > > > };
> > > >
> > > > struct kvm_vcpu_fault_info {
> > > > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > > > index b3edde68bc3e..c35447cc0e0c 100644
> > > > --- a/arch/arm64/include/uapi/asm/kvm.h
> > > > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > > > @@ -199,6 +199,12 @@ struct kvm_arm_copy_mte_tags {
> > > > #define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000
> > > > #define KVM_REG_ARM_COPROC_SHIFT 16
> > > >
> > > > +/* Defines if a KVM register is one per-vCPU or one per-VM */
> > > > +#define KVM_REG_ARM_SCOPE_MASK 0x0000000010000000
> > > > +#define KVM_REG_ARM_SCOPE_SHIFT 28
> > >
> > > Thinking about the advertisement of VM- and vCPU-scoped registers, this
> > > could be generally useful. Might it make sense to add such an encoding
> > > to the arch-generic register definitions?
> > >
> > > If that is the case, we may want to snap up a few more bits (a nybble)
> > > for future expansion.
> > >
> > That's a great idea! But I wonder if we'll get a push-back since there
> > are no users of it in other arch(s) yet. Not sure if there was any
> > need/discussion regarding the same, but I'm happy to share a patch for
> > the same if you sense that there's a strong potential for the patch.
> >
>
> I'm unsure if this is actually of interest to other architectures, it
> just doesn't seem ARM-specific so we should probably raise the question
> so we only grab these bits once.
>
I've CC'ed a few more arch-specific kvm lists for
comments/concerns/suggestions on the idea (feel free to add any other
relevant groups/persons). Based on the response, I can start an
independent RFC series for the same.
> > > > +#define KVM_REG_ARM_SCOPE_VCPU 0
> > > > +#define KVM_REG_ARM_SCOPE_VM 1
> > > > +
> > > > /* Normal registers are mapped as coprocessor 16. */
> > > > #define KVM_REG_ARM_CORE (0x0010 << KVM_REG_ARM_COPROC_SHIFT)
> > > > #define KVM_REG_ARM_CORE_REG(name) (offsetof(struct kvm_regs, name) / sizeof(__u32))
> > > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > > > index ecc5958e27fe..107977c82c6c 100644
> > > > --- a/arch/arm64/kvm/arm.c
> > > > +++ b/arch/arm64/kvm/arm.c
> > > > @@ -81,26 +81,26 @@ int kvm_arch_check_processor_compat(void *opaque)
> > > > int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
> > > > struct kvm_enable_cap *cap)
> > > > {
> > > > - int r;
> > > > + int r = 0;
> > > >
> > > > if (cap->flags)
> > > > return -EINVAL;
> > > >
> > > > switch (cap->cap) {
> > > > case KVM_CAP_ARM_NISV_TO_USER:
> > > > - r = 0;
> > > > kvm->arch.return_nisv_io_abort_to_user = true;
> > > > break;
> > > > case KVM_CAP_ARM_MTE:
> > > > mutex_lock(&kvm->lock);
> > > > - if (!system_supports_mte() || kvm->created_vcpus) {
> > > > + if (!system_supports_mte() || kvm->created_vcpus)
> > > > r = -EINVAL;
> > > > - } else {
> > > > - r = 0;
> > > > + else
> > > > kvm->arch.mte_enabled = true;
> > > > - }
> > > > mutex_unlock(&kvm->lock);
> > > > break;
> > >
> > > Hmm.. these all look like cleanups. If you want to propose these, could
> > > you do it in a separate patch?
> > >
> > Ahh, I thought I could squeeze it in. But sure, I can separate it out.
> > > > + case KVM_CAP_ARM_REG_SCOPE:
> > > > + WRITE_ONCE(kvm->arch.reg_scope_enabled, true);
> > > > + break;
> > > > default:
> > > > r = -EINVAL;
> > > > break;
> > > > @@ -209,6 +209,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> > > > case KVM_CAP_SET_GUEST_DEBUG:
> > > > case KVM_CAP_VCPU_ATTRIBUTES:
> > > > case KVM_CAP_PTP_KVM:
> > > > + case KVM_CAP_ARM_REG_SCOPE:
> > >
> > > It is a bit odd to advertise a capability (and allow userspace to enable
> > > it), despite the fact that the feature itself hasn't yet been
> > > implemented.
> > >
> > > Is it possible to fold the feature in to the patch that exposes it to
> > > userspace? Otherwise, you could punt advertisement of the CAP until it
> > > is actually implemented in kernel.
> > >
> > Well, I didn't want to complicate the patch, but technically the
> > feature is available with this patch, including all the CAP and macro
> > definitions. Userspace can still decode the scope information, only
> > that no registers are added yet, which is done in the next patch. So,
> > the userspace can still remain the same between this and the next
> > patch.
>
> But the series isn't cleanly bisectable. There will exist commits in
> history that report KVM_CAP_ARM_REG_SCOPE as implemented even though
> that is not actually the case. You should really only advertise support
> to userspace when the feature is implemented.
>
> Defining kvm->arch.reg_scope_enabled can be done earlier so you have a
> bit to test and guard all of the new code, and only expose the CAP in
> the last patch of the series.
>
Got it. I'll arrange that in the next spin.
> Also, as an FYI Marc has a patch that I'll be picking up in my own
> series which uses bits instead of bools to keep track of certain
> VM-wide features:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=kvm-arm64/mmu/guest-MMIO-guard&id}d0a13a4217b870f2e83cdc6045e5ce482a5340
>
Thanks. This is great. I can steal a couple of bits and implement the
flags introduced in the series here.
> Marc, if neither of our series land in 5.18 could you at least submit
> this patch in preparation? Should keep conflicts minimal that way.
>
> Thanks!
>
> --
> Oliver
Thank you.
Raghavendra
^ permalink raw reply [flat|nested] 117+ messages in thread* [PATCH v4 02/13] KVM: arm64: Introduce KVM_CAP_ARM_REG_SCOPE
@ 2022-02-28 19:46 ` Raghavendra Rao Ananta
0 siblings, 0 replies; 117+ messages in thread
From: Raghavendra Rao Ananta @ 2022-02-28 19:46 UTC (permalink / raw)
To: kvm-riscv
On Fri, Feb 25, 2022 at 10:26 AM Oliver Upton <oupton@google.com> wrote:
>
> On Fri, Feb 25, 2022 at 09:34:35AM -0800, Raghavendra Rao Ananta wrote:
> > Hey Oliver,
> >
> > On Thu, Feb 24, 2022 at 10:43 PM Oliver Upton <oupton@google.com> wrote:
> > >
> > > On Thu, Feb 24, 2022 at 05:25:48PM +0000, Raghavendra Rao Ananta wrote:
> > > > KVM_[GET|SET]_ONE_REG act on per-vCPU basis. Currently certain
> > > > ARM64 registers, such as KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_[1|2],
> > > > are accessed via this interface even though the effect that
> > > > they have are really per-VM. As a result, userspace could just
> > > > waste cycles to read/write the same information for every vCPU
> > > > that it spawns, only to realize that there's absolutely no change
> > > > in the VM's state. The problem gets worse in proportion to the
> > > > number of vCPUs created.
> > > >
> > > > As a result, to avoid this redundancy, introduce the capability
> > > > KVM_CAP_ARM_REG_SCOPE. If enabled, KVM_GET_REG_LIST will advertise
> > > > the registers that are VM-scoped by dynamically modifying the
> > > > register encoding. KVM_REG_ARM_SCOPE_* helper macros are introduced
> > > > to decode the same. By learning this, userspace can access such
> > > > registers only once.
> > > >
> > > > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> > > > ---
> > > > Documentation/virt/kvm/api.rst | 16 ++++++++++++++++
> > > > arch/arm64/include/asm/kvm_host.h | 3 +++
> > > > arch/arm64/include/uapi/asm/kvm.h | 6 ++++++
> > > > arch/arm64/kvm/arm.c | 13 +++++++------
> > > > include/uapi/linux/kvm.h | 1 +
> > > > 5 files changed, 33 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> > > > index a4267104db50..7e7b3439f540 100644
> > > > --- a/Documentation/virt/kvm/api.rst
> > > > +++ b/Documentation/virt/kvm/api.rst
> > > > @@ -7561,3 +7561,19 @@ The argument to KVM_ENABLE_CAP is also a bitmask, and must be a subset
> > > > of the result of KVM_CHECK_EXTENSION. KVM will forward to userspace
> > > > the hypercalls whose corresponding bit is in the argument, and return
> > > > ENOSYS for the others.
> > > > +
> > > > +8.34 KVM_CAP_ARM_REG_SCOPE
> > > > +--------------------------
> > > > +
> > > > +:Architectures: arm64
> > > > +
> > > > +The capability, if enabled, amends the existing register encoding
> > > > +with additional information to the userspace if a particular register
> > > > +is scoped per-vCPU or per-VM via KVM_GET_REG_LIST. KVM provides
> > > > +KVM_REG_ARM_SCOPE_* helper macros to decode the same. Userspace can
> > > > +use this information from the register encoding to access a VM-scopped
> > > > +regiser only once, as opposed to accessing it for every vCPU for the
> > > > +same effect.
> > > > +
> > >
> > > Could you describe the encoding changes in 4.68 'KVM_SET_ONE_REG', along
> > > with the other ARM encoding details?
> > >
> > > > +On the other hand, if the capability is disabled, all the registers
> > > > +remain vCPU-scopped by default, retaining backward compatibility.
> > >
> > > typo: vCPU-scoped
> > >
> > > That said, I don't believe we need to document behavior if the CAP is
> > > disabled, as the implicated ioctls should continue to work the same.
> > >
> > Sure, I'll address the above two Doc comments.
> > > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > > > index 5bc01e62c08a..8132de6bd718 100644
> > > > --- a/arch/arm64/include/asm/kvm_host.h
> > > > +++ b/arch/arm64/include/asm/kvm_host.h
> > > > @@ -136,6 +136,9 @@ struct kvm_arch {
> > > >
> > > > /* Memory Tagging Extension enabled for the guest */
> > > > bool mte_enabled;
> > > > +
> > > > + /* Register scoping enabled for KVM registers */
> > > > + bool reg_scope_enabled;
> > > > };
> > > >
> > > > struct kvm_vcpu_fault_info {
> > > > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > > > index b3edde68bc3e..c35447cc0e0c 100644
> > > > --- a/arch/arm64/include/uapi/asm/kvm.h
> > > > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > > > @@ -199,6 +199,12 @@ struct kvm_arm_copy_mte_tags {
> > > > #define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000
> > > > #define KVM_REG_ARM_COPROC_SHIFT 16
> > > >
> > > > +/* Defines if a KVM register is one per-vCPU or one per-VM */
> > > > +#define KVM_REG_ARM_SCOPE_MASK 0x0000000010000000
> > > > +#define KVM_REG_ARM_SCOPE_SHIFT 28
> > >
> > > Thinking about the advertisement of VM- and vCPU-scoped registers, this
> > > could be generally useful. Might it make sense to add such an encoding
> > > to the arch-generic register definitions?
> > >
> > > If that is the case, we may want to snap up a few more bits (a nybble)
> > > for future expansion.
> > >
> > That's a great idea! But I wonder if we'll get a push-back since there
> > are no users of it in other arch(s) yet. Not sure if there was any
> > need/discussion regarding the same, but I'm happy to share a patch for
> > the same if you sense that there's a strong potential for the patch.
> >
>
> I'm unsure if this is actually of interest to other architectures, it
> just doesn't seem ARM-specific so we should probably raise the question
> so we only grab these bits once.
>
I've CC'ed a few more arch-specific kvm lists for
comments/concerns/suggestions on the idea (feel free to add any other
relevant groups/persons). Based on the response, I can start an
independent RFC series for the same.
> > > > +#define KVM_REG_ARM_SCOPE_VCPU 0
> > > > +#define KVM_REG_ARM_SCOPE_VM 1
> > > > +
> > > > /* Normal registers are mapped as coprocessor 16. */
> > > > #define KVM_REG_ARM_CORE (0x0010 << KVM_REG_ARM_COPROC_SHIFT)
> > > > #define KVM_REG_ARM_CORE_REG(name) (offsetof(struct kvm_regs, name) / sizeof(__u32))
> > > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > > > index ecc5958e27fe..107977c82c6c 100644
> > > > --- a/arch/arm64/kvm/arm.c
> > > > +++ b/arch/arm64/kvm/arm.c
> > > > @@ -81,26 +81,26 @@ int kvm_arch_check_processor_compat(void *opaque)
> > > > int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
> > > > struct kvm_enable_cap *cap)
> > > > {
> > > > - int r;
> > > > + int r = 0;
> > > >
> > > > if (cap->flags)
> > > > return -EINVAL;
> > > >
> > > > switch (cap->cap) {
> > > > case KVM_CAP_ARM_NISV_TO_USER:
> > > > - r = 0;
> > > > kvm->arch.return_nisv_io_abort_to_user = true;
> > > > break;
> > > > case KVM_CAP_ARM_MTE:
> > > > mutex_lock(&kvm->lock);
> > > > - if (!system_supports_mte() || kvm->created_vcpus) {
> > > > + if (!system_supports_mte() || kvm->created_vcpus)
> > > > r = -EINVAL;
> > > > - } else {
> > > > - r = 0;
> > > > + else
> > > > kvm->arch.mte_enabled = true;
> > > > - }
> > > > mutex_unlock(&kvm->lock);
> > > > break;
> > >
> > > Hmm.. these all look like cleanups. If you want to propose these, could
> > > you do it in a separate patch?
> > >
> > Ahh, I thought I could squeeze it in. But sure, I can separate it out.
> > > > + case KVM_CAP_ARM_REG_SCOPE:
> > > > + WRITE_ONCE(kvm->arch.reg_scope_enabled, true);
> > > > + break;
> > > > default:
> > > > r = -EINVAL;
> > > > break;
> > > > @@ -209,6 +209,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> > > > case KVM_CAP_SET_GUEST_DEBUG:
> > > > case KVM_CAP_VCPU_ATTRIBUTES:
> > > > case KVM_CAP_PTP_KVM:
> > > > + case KVM_CAP_ARM_REG_SCOPE:
> > >
> > > It is a bit odd to advertise a capability (and allow userspace to enable
> > > it), despite the fact that the feature itself hasn't yet been
> > > implemented.
> > >
> > > Is it possible to fold the feature in to the patch that exposes it to
> > > userspace? Otherwise, you could punt advertisement of the CAP until it
> > > is actually implemented in kernel.
> > >
> > Well, I didn't want to complicate the patch, but technically the
> > feature is available with this patch, including all the CAP and macro
> > definitions. Userspace can still decode the scope information, only
> > that no registers are added yet, which is done in the next patch. So,
> > the userspace can still remain the same between this and the next
> > patch.
>
> But the series isn't cleanly bisectable. There will exist commits in
> history that report KVM_CAP_ARM_REG_SCOPE as implemented even though
> that is not actually the case. You should really only advertise support
> to userspace when the feature is implemented.
>
> Defining kvm->arch.reg_scope_enabled can be done earlier so you have a
> bit to test and guard all of the new code, and only expose the CAP in
> the last patch of the series.
>
Got it. I'll arrange that in the next spin.
> Also, as an FYI Marc has a patch that I'll be picking up in my own
> series which uses bits instead of bools to keep track of certain
> VM-wide features:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=kvm-arm64/mmu/guest-MMIO-guard&id=7dd0a13a4217b870f2e83cdc6045e5ce482a5340
>
Thanks. This is great. I can steal a couple of bits and implement the
flags introduced in the series here.
> Marc, if neither of our series land in 5.18 could you at least submit
> this patch in preparation? Should keep conflicts minimal that way.
>
> Thanks!
>
> --
> Oliver
Thank you.
Raghavendra
^ permalink raw reply [flat|nested] 117+ messages in thread