Re: [v2 3/6] KVM: arm64: Support pvlock preempted via shared structure

From: Usama Arif
Date: Mon Nov 07 2022 - 13:11:44 EST




On 07/11/2022 18:02, Punit Agrawal wrote:
Usama Arif <usama.arif@xxxxxxxxxxxxx> writes:

Implement the service call for configuring a shared structure between a
VCPU and the hypervisor in which the hypervisor can tell whether the
VCPU is running or not.

The preempted field is zero if the VCPU is not preempted.
Any other value means the VCPU has been preempted.

Signed-off-by: Zengruan Ye <yezengruan@xxxxxxxxxx>
Signed-off-by: Usama Arif <usama.arif@xxxxxxxxxxxxx>
---
Documentation/virt/kvm/arm/hypercalls.rst | 3 ++
arch/arm64/include/asm/kvm_host.h | 18 ++++++++++
arch/arm64/include/uapi/asm/kvm.h | 1 +
arch/arm64/kvm/Makefile | 2 +-
arch/arm64/kvm/arm.c | 8 +++++
arch/arm64/kvm/hypercalls.c | 8 +++++
arch/arm64/kvm/pvlock.c | 43 +++++++++++++++++++++++
tools/arch/arm64/include/uapi/asm/kvm.h | 1 +
8 files changed, 83 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/kvm/pvlock.c

diff --git a/Documentation/virt/kvm/arm/hypercalls.rst b/Documentation/virt/kvm/arm/hypercalls.rst
index 3e23084644ba..872a16226ace 100644
--- a/Documentation/virt/kvm/arm/hypercalls.rst
+++ b/Documentation/virt/kvm/arm/hypercalls.rst
@@ -127,6 +127,9 @@ The pseudo-firmware bitmap register are as follows:
Bit-1: KVM_REG_ARM_VENDOR_HYP_BIT_PTP:
The bit represents the Precision Time Protocol KVM service.
+ Bit-2: KVM_REG_ARM_VENDOR_HYP_BIT_PV_LOCK:
+ The bit represents the Paravirtualized lock service.
+
Errors:
======= =============================================================
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 45e2136322ba..18303b30b7e9 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -417,6 +417,11 @@ struct kvm_vcpu_arch {
u64 last_steal;
gpa_t base;
} steal;
+
+ /* Guest PV lock state */
+ struct {
+ gpa_t base;
+ } pv;

Using "pv" for the structure isn't quite describing the usage well. It'd
be better to call it "pv_lock" or "pvlock" at the least.

Yes makes sense, will change in next patchset, Thanks.

[...]