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. > + > +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. Steve _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
