Re: [v2 1/6] KVM: arm64: Document PV-lock interface
Hi Usama, Usama Arif writes: > Introduce a paravirtualization interface for KVM/arm64 to obtain whether > the VCPU is currently running or not. > > The PV lock structure of the guest is allocated by user space. > > A hypercall interface is provided for the guest to interrogate the > location of the shared memory structures. > > Signed-off-by: Zengruan Ye > Signed-off-by: Usama Arif > --- > Documentation/virt/kvm/arm/index.rst| 1 + > Documentation/virt/kvm/arm/pvlock.rst | 52 + > Documentation/virt/kvm/devices/vcpu.rst | 25 > 3 files changed, 78 insertions(+) > create mode 100644 Documentation/virt/kvm/arm/pvlock.rst > > diff --git a/Documentation/virt/kvm/arm/index.rst > b/Documentation/virt/kvm/arm/index.rst > index e84848432158..b8499dc00a6a 100644 > --- a/Documentation/virt/kvm/arm/index.rst > +++ b/Documentation/virt/kvm/arm/index.rst > @@ -10,4 +10,5 @@ ARM > hyp-abi > hypercalls > pvtime > + pvlock > ptp_kvm > diff --git a/Documentation/virt/kvm/arm/pvlock.rst > b/Documentation/virt/kvm/arm/pvlock.rst > new file mode 100644 > index ..d3c391b16d36 > --- /dev/null > +++ b/Documentation/virt/kvm/arm/pvlock.rst > @@ -0,0 +1,52 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > +Paravirtualized lock support for arm64 > +== > + > +KVM/arm64 provides a hypervisor service call for paravirtualized guests to > +determine whether a VCPU is currently running or not. > + > +A new SMCCC compatible hypercall is defined: > + > +* ARM_SMCCC_VENDOR_HYP_KVM_PV_LOCK_FUNC_ID: 0xC602 > + > +ARM_SMCCC_VENDOR_HYP_KVM_PV_LOCK_FUNC_ID > + > += == > +Function ID: (uint32)0xC602 > +Return value: (int64) IPA of the pv lock data structure for this > + VCPU. On failure: > + NOT_SUPPORTED (-1) > += == > + > +The IPA returned by PV_LOCK_PREEMPTED should be mapped by the guest as normal > +memory with inner and outer write back caching attributes, in the inner > +shareable domain. > + > +PV_LOCK_PREEMPTED returns the structure for the calling VCPU. > + > +PV lock state > +- > + > +The structure pointed to by the PV_LOCK_PREEMPTED hypercall is as follows: > + > ++---+-+-+-+ > +| Field | Byte Length | Byte Offset | Description | > ++===+=+=+=+ > +| preempted | 8 | 0 | Indicate if the VCPU that owns | > +| | | | this struct is running or not. | > +| | | | Non-zero values mean the VCPU | > +| | | | has been preempted. Zero means | > +| | | | the VCPU is not preempted. | > ++---+-+-+-+ > + > +The preempted field will be updated to 1 by the hypervisor prior to > scheduling > +a VCPU. When the VCPU is scheduled out, the preempted field will be updated > +to 0 by the hypervisor. The text above doesn't match the description in the table. Please update the texts to align them with the code. [...] ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [v2 1/6] KVM: arm64: Document PV-lock interface
On 07/11/2022 17:56, Punit Agrawal wrote: Hi Usama, Usama Arif writes: Introduce a paravirtualization interface for KVM/arm64 to obtain whether the VCPU is currently running or not. The PV lock structure of the guest is allocated by user space. A hypercall interface is provided for the guest to interrogate the location of the shared memory structures. Signed-off-by: Zengruan Ye Signed-off-by: Usama Arif --- Documentation/virt/kvm/arm/index.rst| 1 + Documentation/virt/kvm/arm/pvlock.rst | 52 + Documentation/virt/kvm/devices/vcpu.rst | 25 3 files changed, 78 insertions(+) create mode 100644 Documentation/virt/kvm/arm/pvlock.rst diff --git a/Documentation/virt/kvm/arm/index.rst b/Documentation/virt/kvm/arm/index.rst index e84848432158..b8499dc00a6a 100644 --- a/Documentation/virt/kvm/arm/index.rst +++ b/Documentation/virt/kvm/arm/index.rst @@ -10,4 +10,5 @@ ARM hyp-abi hypercalls pvtime + pvlock ptp_kvm diff --git a/Documentation/virt/kvm/arm/pvlock.rst b/Documentation/virt/kvm/arm/pvlock.rst new file mode 100644 index ..d3c391b16d36 --- /dev/null +++ b/Documentation/virt/kvm/arm/pvlock.rst @@ -0,0 +1,52 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Paravirtualized lock support for arm64 +== + +KVM/arm64 provides a hypervisor service call for paravirtualized guests to +determine whether a VCPU is currently running or not. + +A new SMCCC compatible hypercall is defined: + +* ARM_SMCCC_VENDOR_HYP_KVM_PV_LOCK_FUNC_ID: 0xC602 + +ARM_SMCCC_VENDOR_HYP_KVM_PV_LOCK_FUNC_ID + += == +Function ID: (uint32)0xC602 +Return value: (int64) IPA of the pv lock data structure for this + VCPU. On failure: + NOT_SUPPORTED (-1) += == + +The IPA returned by PV_LOCK_PREEMPTED should be mapped by the guest as normal +memory with inner and outer write back caching attributes, in the inner +shareable domain. + +PV_LOCK_PREEMPTED returns the structure for the calling VCPU. + +PV lock state +- + +The structure pointed to by the PV_LOCK_PREEMPTED hypercall is as follows: + ++---+-+-+-+ +| Field | Byte Length | Byte Offset | Description | ++===+=+=+=+ +| preempted | 8 | 0 | Indicate if the VCPU that owns | +| | | | this struct is running or not. | +| | | | Non-zero values mean the VCPU | +| | | | has been preempted. Zero means | +| | | | the VCPU is not preempted. | ++---+-+-+-+ + +The preempted field will be updated to 1 by the hypervisor prior to scheduling +a VCPU. When the VCPU is scheduled out, the preempted field will be updated +to 0 by the hypervisor. The text above doesn't match the description in the table. Please update the texts to align them with the code. Will make it clearer in the next revision. Thanks. [...] ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
[v2 1/6] KVM: arm64: Document PV-lock interface
Introduce a paravirtualization interface for KVM/arm64 to obtain whether the VCPU is currently running or not. The PV lock structure of the guest is allocated by user space. A hypercall interface is provided for the guest to interrogate the location of the shared memory structures. Signed-off-by: Zengruan Ye Signed-off-by: Usama Arif --- Documentation/virt/kvm/arm/index.rst| 1 + Documentation/virt/kvm/arm/pvlock.rst | 52 + Documentation/virt/kvm/devices/vcpu.rst | 25 3 files changed, 78 insertions(+) create mode 100644 Documentation/virt/kvm/arm/pvlock.rst diff --git a/Documentation/virt/kvm/arm/index.rst b/Documentation/virt/kvm/arm/index.rst index e84848432158..b8499dc00a6a 100644 --- a/Documentation/virt/kvm/arm/index.rst +++ b/Documentation/virt/kvm/arm/index.rst @@ -10,4 +10,5 @@ ARM hyp-abi hypercalls pvtime + pvlock ptp_kvm diff --git a/Documentation/virt/kvm/arm/pvlock.rst b/Documentation/virt/kvm/arm/pvlock.rst new file mode 100644 index ..d3c391b16d36 --- /dev/null +++ b/Documentation/virt/kvm/arm/pvlock.rst @@ -0,0 +1,52 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Paravirtualized lock support for arm64 +== + +KVM/arm64 provides a hypervisor service call for paravirtualized guests to +determine whether a VCPU is currently running or not. + +A new SMCCC compatible hypercall is defined: + +* ARM_SMCCC_VENDOR_HYP_KVM_PV_LOCK_FUNC_ID: 0xC602 + +ARM_SMCCC_VENDOR_HYP_KVM_PV_LOCK_FUNC_ID + += == +Function ID: (uint32)0xC602 +Return value: (int64) IPA of the pv lock data structure for this + VCPU. On failure: + NOT_SUPPORTED (-1) += == + +The IPA returned by PV_LOCK_PREEMPTED should be mapped by the guest as normal +memory with inner and outer write back caching attributes, in the inner +shareable domain. + +PV_LOCK_PREEMPTED returns the structure for the calling VCPU. + +PV lock state +- + +The structure pointed to by the PV_LOCK_PREEMPTED hypercall is as follows: + ++---+-+-+-+ +| Field | Byte Length | Byte Offset | Description | ++===+=+=+=+ +| preempted | 8 | 0 | Indicate if the VCPU that owns | +| | | | this struct is running or not. | +| | | | Non-zero values mean the VCPU | +| | | | has been preempted. Zero means | +| | | | the VCPU is not preempted. | ++---+-+-+-+ + +The preempted field will be updated to 1 by the hypervisor prior to scheduling +a VCPU. When the VCPU is scheduled out, the preempted field will be updated +to 0 by the hypervisor. + +The structure will be present within a reserved region of the normal memory +given to the guest. The guest should not attempt to write into this memory. +There is a structure per VCPU of the guest. + +For the user space interface see +:ref:`Documentation/virt/kvm/devices/vcpu.rst `. \ No newline at end of file diff --git a/Documentation/virt/kvm/devices/vcpu.rst b/Documentation/virt/kvm/devices/vcpu.rst index 716aa3edae14..ea81b98f0e19 100644 --- a/Documentation/virt/kvm/devices/vcpu.rst +++ b/Documentation/virt/kvm/devices/vcpu.rst @@ -263,3 +263,28 @@ From the destination VMM process: 7. Write the KVM_VCPU_TSC_OFFSET attribute for every vCPU with the respective value derived in the previous step. + +.. _kvm_arm_vcpu_pvlock_ctrl: + +5. GROUP: KVM_ARM_VCPU_PVLOCK_CTRL +== + +:Architectures: ARM64 + +5.1 ATTRIBUTE: KVM_ARM_VCPU_PVLOCK_IPA +-- + +:Parameters: 64-bit base address + +Returns: + +=== == +-ENXIO PV lock not implemented +-EEXIST Base address already set for this VCPU +-EINVAL Base address not 64 byte aligned +=== == + +Specifies the base address of the pv lock structure for this VCPU. The +base address must be 64 byte aligned and exist within a valid guest memory +region. See Documentation/virt/kvm/arm/pvlock.rst for more information +including the layout of the pv lock structure. -- 2.25.1 ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v2 1/6] KVM: arm64: Document PV-lock interface
Hi Steve, On 2020/1/9 22:53, Steven Price wrote: > On 26/12/2019 13:58, Zengruan Ye wrote: >> Introduce a paravirtualization interface for KVM/arm64 to obtain the VCPU >> is currently running or not. >> >> The PV lock structure of the guest is allocated by user space. >> >> 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 >> --- >> Documentation/virt/kvm/arm/pvlock.rst | 63 + >> Documentation/virt/kvm/devices/vcpu.txt | 14 ++ >> 2 files changed, 77 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 ..58b3b8ee7537 >> --- /dev/null >> +++ b/Documentation/virt/kvm/arm/pvlock.rst >> @@ -0,0 +1,63 @@ >> +.. SPDX-License-Identifier: GPL-2.0 >> + >> +Paravirtualized lock support for arm64 >> +== >> + >> +KVM/arm64 provides some hypervisor service calls to support a >> paravirtualized >> +guest obtaining the VCPU is currently running or not. > NIT: ^ whether Thanks for posting this. > >> + >> +Two new SMCCC compatible hypercalls are defined: >> + >> +* PV_LOCK_FEATURES: 0xC620 >> +* PV_LOCK_PREEMPTED: 0xC621 >> + >> +The existence of the PV_LOCK hypercall should be probed using the SMCCC 1.1 >> +ARCH_FEATURES mechanism before calling it. > > Since these are within the "vendor specific" SMCCC region ideally you should > also check that you are talking to KVM. (Other hypervisors could allocate > SMCCC IDs differently within this block). Will has a patch on a branch which > gives an example of how this could work [1] > > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/commit/?h=kvm/hvc&id=464f5a1741e5959c3e4d2be1966ae0093b4dce06 OK, I will add "vendor specific" check next version. > >> + >> +PV_LOCK_FEATURES >> + = == >> + Function ID: (uint32) 0xC620 >> + 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) 0xC621 >> + Return value: (int64) NOT_SUPPORTED (-1) or SUCCESS (0) if the IPA >> of >> + this VCPU's pv data structure is configured by >> + the hypervisor. >> + = == > > PV_LOCK_PREEMPTED also needs to return the address of this data structure. > Either by returning this in another register, or by e.g. treating a positive > return as an address and a negative value as an error. This is somewhat embarrassing. The code does what you say, but the doc doesn't. Thanks for pointing it out to me! I'll update the doc to match. > >> + >> +The IPA returned by PV_LOCK_PREEMPTED should be mapped by the guest as >> normal >> +memory with inner and outer write back caching attributes, in the inner >> +shareable domain. >> + >> +PV_LOCK_PREEMPTED returns the structure for the calling VCPU. >> + >> +PV lock state >> +- >> + >> +The structure pointed to by the PV_LOCK_PREEMPTED hypercall is as follows: >> + >> ++---+-+-+-+ >> +| Field | Byte Length | Byte Offset | Description | >> ++===+=+=+=+ >> +| preempted | 8 | 0 | Indicate the VCPU who owns this | > > NIT: s/Indicate/Indicates that/. Also more common English would be "the VCPU > *that* owns" Will update. > >> +| | | | struct is running or not. | >> +| | | | Non-zero values mean the VCPU | >> +| | | | has been preempted. Zero means | >> +| | | | the VCPU is not preempted. | >> ++---+-+-+-+ >> + >> +The preempted field will be updated to 1 by the hypervisor prior to >> scheduling >> +a VCPU. When the VCPU is scheduled out, the preempted field will be updated >> +to 0 by the hypervisor. >> + >> +The structure will be present within a reserved region of the normal memory >> +given to the guest. The guest should not attempt to write into this memory. >> +There is a structure per VCPU of the guest. > > I think it would be worth mentioning in this document that the structure is > guaranteed to be 64-byte aligned. Good point, I'll update the doc. > > St
Re: [PATCH v2 1/6] KVM: arm64: Document PV-lock interface
On 26/12/2019 13:58, Zengruan Ye wrote: Introduce a paravirtualization interface for KVM/arm64 to obtain the VCPU is currently running or not. The PV lock structure of the guest is allocated by user space. 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 --- Documentation/virt/kvm/arm/pvlock.rst | 63 + Documentation/virt/kvm/devices/vcpu.txt | 14 ++ 2 files changed, 77 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 ..58b3b8ee7537 --- /dev/null +++ b/Documentation/virt/kvm/arm/pvlock.rst @@ -0,0 +1,63 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Paravirtualized lock support for arm64 +== + +KVM/arm64 provides some hypervisor service calls to support a paravirtualized +guest obtaining the VCPU is currently running or not. NIT: ^ whether + +Two new SMCCC compatible hypercalls are defined: + +* PV_LOCK_FEATURES: 0xC620 +* PV_LOCK_PREEMPTED: 0xC621 + +The existence of the PV_LOCK hypercall should be probed using the SMCCC 1.1 +ARCH_FEATURES mechanism before calling it. Since these are within the "vendor specific" SMCCC region ideally you should also check that you are talking to KVM. (Other hypervisors could allocate SMCCC IDs differently within this block). Will has a patch on a branch which gives an example of how this could work [1] [1] https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/commit/?h=kvm/hvc&id=464f5a1741e5959c3e4d2be1966ae0093b4dce06 + +PV_LOCK_FEATURES += == +Function ID: (uint32)0xC620 +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)0xC621 +Return value: (int64) NOT_SUPPORTED (-1) or SUCCESS (0) if the IPA of + this VCPU's pv data structure is configured by + the hypervisor. += == PV_LOCK_PREEMPTED also needs to return the address of this data structure. Either by returning this in another register, or by e.g. treating a positive return as an address and a negative value as an error. + +The IPA returned by PV_LOCK_PREEMPTED should be mapped by the guest as normal +memory with inner and outer write back caching attributes, in the inner +shareable domain. + +PV_LOCK_PREEMPTED returns the structure for the calling VCPU. + +PV lock state +- + +The structure pointed to by the PV_LOCK_PREEMPTED hypercall is as follows: + ++---+-+-+-+ +| Field | Byte Length | Byte Offset | Description | ++===+=+=+=+ +| preempted | 8 | 0 | Indicate the VCPU who owns this | NIT: s/Indicate/Indicates that/. Also more common English would be "the VCPU *that* owns" +| | | | struct is running or not. | +| | | | Non-zero values mean the VCPU | +| | | | has been preempted. Zero means | +| | | | the VCPU is not preempted. | ++---+-+-+-+ + +The preempted field will be updated to 1 by the hypervisor prior to scheduling +a VCPU. When the VCPU is scheduled out, the preempted field will be updated +to 0 by the hypervisor. + +The structure will be present within a reserved region of the normal memory +given to the guest. The guest should not attempt to write into this memory. +There is a structure per VCPU of the guest. I think it would be worth mentioning in this document that the structure is guaranteed to be 64-byte aligned. Steve + +For the user space interface see Documentation/virt/kvm/devices/vcpu.txt +section "4. GROUP: KVM_ARM_VCPU_PVLOCK_CTRL". diff --git a/Documentation/virt/kvm/devices/vcpu.txt b/Documentation/virt/kvm/devices/vcpu.txt index 6f3bd64a05b0..c10a5945075b 100644 --- a/Documentation/virt/kvm/devices/vcpu.txt +++ b/Documentation/virt/kvm/devices/vcpu.txt @@ -74,3 +74,17 @@ Specifies the base address of the stolen time structure for this VCPU. The base address must be 64 byte aligned and exist within a valid guest memory region. See Documentation/virt/kvm/arm/pvtime.txt for more information including the layout of the stolen
[PATCH v2 1/6] KVM: arm64: Document PV-lock interface
Introduce a paravirtualization interface for KVM/arm64 to obtain the VCPU is currently running or not. The PV lock structure of the guest is allocated by user space. 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 --- Documentation/virt/kvm/arm/pvlock.rst | 63 + Documentation/virt/kvm/devices/vcpu.txt | 14 ++ 2 files changed, 77 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 ..58b3b8ee7537 --- /dev/null +++ b/Documentation/virt/kvm/arm/pvlock.rst @@ -0,0 +1,63 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Paravirtualized lock support for arm64 +== + +KVM/arm64 provides 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: 0xC620 +* PV_LOCK_PREEMPTED: 0xC621 + +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)0xC620 +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)0xC621 +Return value: (int64) NOT_SUPPORTED (-1) or SUCCESS (0) if the IPA of + this VCPU's pv data structure is configured by + the hypervisor. += == + +The IPA returned by PV_LOCK_PREEMPTED should be mapped by the guest as normal +memory with inner and outer write back caching attributes, in the inner +shareable domain. + +PV_LOCK_PREEMPTED returns the structure for the calling VCPU. + +PV lock state +- + +The structure pointed to by the PV_LOCK_PREEMPTED hypercall is as follows: + ++---+-+-+-+ +| Field | Byte Length | Byte Offset | Description | ++===+=+=+=+ +| preempted | 8 | 0 | Indicate the VCPU who owns this | +| | | | struct is running or not. | +| | | | Non-zero values mean the VCPU | +| | | | has been preempted. Zero means | +| | | | the VCPU is not preempted. | ++---+-+-+-+ + +The preempted field will be updated to 1 by the hypervisor prior to scheduling +a VCPU. When the VCPU is scheduled out, the preempted field will be updated +to 0 by the hypervisor. + +The structure will be present within a reserved region of the normal memory +given to the guest. The guest should not attempt to write into this memory. +There is a structure per VCPU of the guest. + +For the user space interface see Documentation/virt/kvm/devices/vcpu.txt +section "4. GROUP: KVM_ARM_VCPU_PVLOCK_CTRL". diff --git a/Documentation/virt/kvm/devices/vcpu.txt b/Documentation/virt/kvm/devices/vcpu.txt index 6f3bd64a05b0..c10a5945075b 100644 --- a/Documentation/virt/kvm/devices/vcpu.txt +++ b/Documentation/virt/kvm/devices/vcpu.txt @@ -74,3 +74,17 @@ Specifies the base address of the stolen time structure for this VCPU. The base address must be 64 byte aligned and exist within a valid guest memory region. See Documentation/virt/kvm/arm/pvtime.txt for more information including the layout of the stolen time structure. + +4. GROUP: KVM_ARM_VCPU_PVLOCK_CTRL +Architectures: ARM64 + +4.1 ATTRIBUTE: KVM_ARM_VCPU_PVLOCK_IPA +Parameters: 64-bit base address +Returns: -ENXIO: PV lock not implemented + -EEXIST: Base address already set for this VCPU + -EINVAL: Base address not 64 byte aligned + +Specifies the base address of the PV lock structure for this VCPU. The +base address must be 64 byte aligned and exist within a valid guest memory +region. See Documentation/virt/kvm/arm/pvlock.rst for more information +including the layout of the pv lock structure. -- 2.19.1 ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
