On 19/12/2019 11:45, yezengruan wrote: > 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. I don't have strong feelings on whether this should be KVM-specific or generic. I'm not familiar with whether there are competing solutions to this problem - it's obviously ideal if all hypervisors can make use of the same interface if possible, but maybe that ship has sailed already? However if this going to be KVM-specific then you'll need to add the probing logic for checking whether the hypervisor is KVM or not. Will has a couple of patches on a branch which do this [1] and [2]. Then you can use kvm_arm_hyp_services_available() as the first step to probe whether the hypervisor is KVM. [1] https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/commit/?h=kvm/hvc&id=464f5a1741e5959c3e4d2be1966ae0093b4dce06 [2] https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/commit/?h=kvm/hvc&id=6597490e005d0eeca8ed8c1c1d7b4318ee014681 Steve >> >>> + >>> +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 > > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
