Re: [PATCH] kvm/arm: Fix pvtime documentation

2022-11-04 Thread Bagas Sanjaya
On 11/4/22 18:06, Marc Zyngier wrote:
> On Fri, 04 Nov 2022 01:48:21 +,
> Bagas Sanjaya  wrote:
>>
>> On 11/3/22 22:42, Marc Zyngier wrote:
>>> No, this is the correct course of action. There isn't any point in
>>> having an *unrelated* change in a separate series. This is a
>>> standalone change, posted as a standalone patch.
>>>
>>>> Please reroll your series [2] with suggestion applied.
>>>
>>> Or not.
>>>
>>
>> You mean the series before this patch have already been applied,
>> right?
> 
> This change is 100% independent from the series you quoted. Why should
> there be a dependency between the two?
> 
> As for respinning the series at this stage for a documentation
> formatting issue, this is pretty pointless, and only clutters people's
> Inbox with redundant versions...
> 
>   M.
> 

OK, thanks!

-- 
An old man doll... just what I always wanted! - Clara

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm


Re: [PATCH] kvm/arm: Fix pvtime documentation

2022-11-03 Thread Bagas Sanjaya
On 11/3/22 22:42, Marc Zyngier wrote:
> No, this is the correct course of action. There isn't any point in
> having an *unrelated* change in a separate series. This is a
> standalone change, posted as a standalone patch.
> 
>> Please reroll your series [2] with suggestion applied.
> 
> Or not.
> 

You mean the series before this patch have already been applied,
right?

-- 
An old man doll... just what I always wanted! - Clara

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm


Re: [External] Re: [RFC 1/6] KVM: arm64: Document PV-lock interface

2022-11-03 Thread Bagas Sanjaya
On 11/3/22 20:15, Usama Arif wrote:
> Hi,
> 
> Thanks for the review. I will include the changes in the next version I send 
> for pvlock. I have sent a patch to fix pvtime here 
> https://lore.kernel.org/all/20221103131210.3603385-1-usama.a...@bytedance.com/.
> 

Please please please *DON'T* top-post; reply inline instead.

-- 
An old man doll... just what I always wanted! - Clara

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm


Re: [PATCH] kvm/arm: Fix pvtime documentation

2022-11-03 Thread Bagas Sanjaya
On 11/3/22 20:12, Usama Arif wrote:
> This includes table format and using reST labels for
> cross-referencing to vcpu.rst.
> 
> Suggested-by:  Bagas Sanjaya 
> Signed-off-by: Usama Arif 

This is not what people normally do when given suggestion diff like
what I sent before [1]. Instead, they just apply and squash the
suggestion (while also applying requested changes from reviewers).

Please reroll your series [2] with suggestion applied.

Thanks.

[1]: https://lore.kernel.org/linux-doc/y2m6eu6xw7jjv...@debian.me/
[2]: 
https://lore.kernel.org/linux-doc/20221102161340.2982090-1-usama.a...@bytedance.com/

-- 
An old man doll... just what I always wanted! - Clara

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm


Re: [RFC 1/6] KVM: arm64: Document PV-lock interface

2022-11-03 Thread Bagas Sanjaya
On Wed, Nov 02, 2022 at 04:13:35PM +, Usama Arif wrote:
> += ==
> +Function ID:  (uint32)0xC620
> +PV_call_id:   (uint32)The function to query for support.
> +  Currently only PV_LOCK_PREEMPTED is supported.
> +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) IPA of the pv lock data structure for this
> +  VCPU. On failure:
> +  NOT_SUPPORTED (-1)
> += ==
> +

You need to fix up these tables above:

 >8 

diff --git a/Documentation/virt/kvm/arm/pvlock.rst 
b/Documentation/virt/kvm/arm/pvlock.rst
index 766aeef50b2d31..940a1cb221bc90 100644
--- a/Documentation/virt/kvm/arm/pvlock.rst
+++ b/Documentation/virt/kvm/arm/pvlock.rst
@@ -15,21 +15,23 @@ 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.
   Currently only PV_LOCK_PREEMPTED is supported.
 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) 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

The similar fixup should also be made to the tables in
Documentation/virt/kvm/arm/pvtime.rst, though.

> +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 Documentation/virt/kvm/devices/vcpu.rst
> +section "4. GROUP: KVM_ARM_VCPU_PVLOCK_CTRL".

Use reST labels for cross-referencing to the documentation section:

 >8 

diff --git a/Documentation/virt/kvm/arm/pvlock.rst 
b/Documentation/virt/kvm/arm/pvlock.rst
index 940a1cb221bc90..4e9d09b76ef033 100644
--- a/Documentation/virt/kvm/arm/pvlock.rst
+++ b/Documentation/virt/kvm/arm/pvlock.rst
@@ -62,5 +62,5 @@ 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.rst
-section "4. GROUP: KVM_ARM_VCPU_PVLOCK_CTRL".
+For the user space interface see :ref:`KVM_VCPU_TSC_CTRL in Generic vcpu
+interface documentation `.
diff --git