| Message ID | 20191217135549.3240-2-yezengruan@huawei.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | KVM: arm64: vcpu preempted check support | expand |
On Tue, Dec 17, 2019 at 01:55:45PM +0000, yezengruan@huawei.com wrote: > From: Zengruan Ye <yezengruan@huawei.com> > > 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@huawei.com> > --- > 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
Hi Steve, On 2019/12/17 22:21, Steven Price wrote: > On Tue, Dec 17, 2019 at 01:55:45PM +0000, yezengruan@huawei.com wrote: >> From: Zengruan Ye <yezengruan@huawei.com> >> >> 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@huawei.com> >> --- >> 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
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@huawei.com wrote: >>> From: Zengruan Ye <yezengruan@huawei.com> >>> >>> 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@huawei.com> >>> --- >>> 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@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >
… > +++ b/Documentation/virt/kvm/arm/pvlock.rst … > +Paravirtualized lock support for arm64 > +====================================== > + > +KVM/arm64 provids some … … I suggest to avoid a typo here. Regards, Markus
Hi Markus, On 2019/12/20 22:32, Markus Elfring wrote: > … >> +++ b/Documentation/virt/kvm/arm/pvlock.rst > … >> +Paravirtualized lock support for arm64 >> +====================================== >> + >> +KVM/arm64 provids some … > … > > I suggest to avoid a typo here. Thanks for posting this. > > Regards, > Markus > Thanks, Zengruan
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 + +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. + ============= ======== ==========