Hi Steve, On 2019/12/17 22:21, Steven Price wrote: > On Tue, Dec 17, 2019 at 01:55:45PM +0000, yezengruan@xxxxxxxxxx wrote: >> From: Zengruan Ye <yezengruan@xxxxxxxxxx> >> >> Introduce a paravirtualization interface for KVM/arm64 to obtain the vcpu >> is currently running or not. >> >> A hypercall interface is provided for the guest to interrogate the >> hypervisor's support for this interface and the location of the shared >> memory structures. >> >> Signed-off-by: Zengruan Ye <yezengruan@xxxxxxxxxx> >> --- >> Documentation/virt/kvm/arm/pvlock.rst | 31 +++++++++++++++++++++++++++ >> 1 file changed, 31 insertions(+) >> create mode 100644 Documentation/virt/kvm/arm/pvlock.rst >> >> diff --git a/Documentation/virt/kvm/arm/pvlock.rst b/Documentation/virt/kvm/arm/pvlock.rst >> new file mode 100644 >> index 000000000000..eec0c36edf17 >> --- /dev/null >> +++ b/Documentation/virt/kvm/arm/pvlock.rst >> @@ -0,0 +1,31 @@ >> +.. SPDX-License-Identifier: GPL-2.0 >> + >> +Paravirtualized lock support for arm64 >> +====================================== >> + >> +KVM/arm64 provids some hypervisor service calls to support a paravirtualized >> +guest obtaining the vcpu is currently running or not. >> + >> +Two new SMCCC compatible hypercalls are defined: >> + >> +* PV_LOCK_FEATURES: 0xC5000040 >> +* PV_LOCK_PREEMPTED: 0xC5000041 > > These values are in the "Standard Hypervisor Service Calls" section of > SMCCC - so is there a document that describes this features such that > other OSes or hypervisors can implement it? I'm also not entirely sure > of the process of ensuring that the IDs picked are non-conflicting. > > Otherwise if this is a KVM specific interface this should probably > belong within the "Vendor Specific Hypervisor Service Calls" section > along with some probing that the hypervisor is actually KVM. Although I > don't see anything KVM specific. Thanks for pointing it out to me! Actually, I also don't see any documents or KVM specific that describes this features. The values in the "Vendor Specific Hypervisor Service Calls" section may be more appropriate, such as the following * PV_LOCK_FEATURES: 0xC6000020 * PV_LOCK_PREEMPTED: 0xC6000021 Please let me know if you have any suggestions. > >> + >> +The existence of the PV_LOCK hypercall should be probed using the SMCCC 1.1 >> +ARCH_FEATURES mechanism before calling it. >> + >> +PV_LOCK_FEATURES >> + ============= ======== ========== >> + Function ID: (uint32) 0xC5000040 >> + PV_call_id: (uint32) The function to query for support. >> + Return value: (int64) NOT_SUPPORTED (-1) or SUCCESS (0) if the relevant >> + PV-lock feature is supported by the hypervisor. >> + ============= ======== ========== >> + >> +PV_LOCK_PREEMPTED >> + ============= ======== ========== >> + Function ID: (uint32) 0xC5000041 >> + Return value: (int64) NOT_SUPPORTED (-1) or SUCCESS (0) if the IPA of >> + this vcpu's pv data structure is configured by >> + the hypervisor. >> + ============= ======== ========== > >>From the code it looks like there's another argument for this SMC - the > physical address (or IPA) of a struct pvlock_vcpu_state. This structure > also needs to be described as it is part of the ABI. Will update. > > Steve > > . > Thanks, Zengruan _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
