kvm/arm: Fix pvtime documentation

  This includes table format and using reST labels for
cross-referencing to vcpu.rst.

Suggested-by:  Bagas Sanjaya <bagasdotme@gmail.com>
Signed-off-by: Usama Arif <usama.arif@bytedance.com>
---
 Documentation/virt/kvm/arm/pvtime.rst   | 14 ++++++++------
 Documentation/virt/kvm/devices/vcpu.rst |  2 ++
 2 files changed, 10 insertions(+), 6 deletions(-)
  

On 03/11/2022 13:12, Usama Arif wrote:
> This includes table format and using reST labels for
> cross-referencing to vcpu.rst.
> 
> Suggested-by:  Bagas Sanjaya <bagasdotme@gmail.com>
> Signed-off-by: Usama Arif <usama.arif@bytedance.com>

Reviewed-by: Steven Price <steven.price@arm.com>

> ---
>  Documentation/virt/kvm/arm/pvtime.rst   | 14 ++++++++------
>  Documentation/virt/kvm/devices/vcpu.rst |  2 ++
>  2 files changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/virt/kvm/arm/pvtime.rst b/Documentation/virt/kvm/arm/pvtime.rst
> index 392521af7c90..e88b34e586be 100644
> --- a/Documentation/virt/kvm/arm/pvtime.rst
> +++ b/Documentation/virt/kvm/arm/pvtime.rst
> @@ -23,21 +23,23 @@ the PV_TIME_FEATURES hypercall should be probed using the SMCCC 1.1
>  ARCH_FEATURES mechanism before calling it.
>  
>  PV_TIME_FEATURES
> -    ============= ========    ==========
> +
> +    ============= ========    =================================================
>      Function ID:  (uint32)    0xC5000020
>      PV_call_id:   (uint32)    The function to query for support.
>                                Currently only PV_TIME_ST is supported.
>      Return value: (int64)     NOT_SUPPORTED (-1) or SUCCESS (0) if the relevant
>                                PV-time feature is supported by the hypervisor.
> -    ============= ========    ==========
> +    ============= ========    =================================================
>  
>  PV_TIME_ST
> -    ============= ========    ==========
> +
> +    ============= ========    ==============================================
>      Function ID:  (uint32)    0xC5000021
>      Return value: (int64)     IPA of the stolen time data structure for this
>                                VCPU. On failure:
>                                NOT_SUPPORTED (-1)
> -    ============= ========    ==========
> +    ============= ========    ==============================================
>  
>  The IPA returned by PV_TIME_ST should be mapped by the guest as normal memory
>  with inner and outer write back caching attributes, in the inner shareable
> @@ -76,5 +78,5 @@ It is advisable that one or more 64k pages are set aside for the purpose of
>  these structures and not used for other purposes, this enables the guest to map
>  the region using 64k pages and avoids conflicting attributes with other memory.
>  
> -For the user space interface see Documentation/virt/kvm/devices/vcpu.rst
> -section "3. GROUP: KVM_ARM_VCPU_PVTIME_CTRL".
> +For the user space interface see
> +:ref:`Documentation/virt/kvm/devices/vcpu.rst <kvm_arm_vcpu_pvtime_ctrl>`.
> \ No newline at end of file
> diff --git a/Documentation/virt/kvm/devices/vcpu.rst b/Documentation/virt/kvm/devices/vcpu.rst
> index 716aa3edae14..31f14ec4a65b 100644
> --- a/Documentation/virt/kvm/devices/vcpu.rst
> +++ b/Documentation/virt/kvm/devices/vcpu.rst
> @@ -171,6 +171,8 @@ configured values on other VCPUs.  Userspace should configure the interrupt
>  numbers on at least one VCPU after creating all VCPUs and before running any
>  VCPUs.
>  
> +.. _kvm_arm_vcpu_pvtime_ctrl:
> +
>  3. GROUP: KVM_ARM_VCPU_PVTIME_CTRL
>  ==================================
>
  

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 <bagasdotme@gmail.com>
> Signed-off-by: Usama Arif <usama.arif@bytedance.com>

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/Y2M6eU6xW7jjVQNx@debian.me/
[2]: https://lore.kernel.org/linux-doc/20221102161340.2982090-1-usama.arif@bytedance.com/
  

On Thu, 03 Nov 2022 13:55:29 +0000,
Bagas Sanjaya <bagasdotme@gmail.com> wrote:
> 
> 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 <bagasdotme@gmail.com>
> > Signed-off-by: Usama Arif <usama.arif@bytedance.com>
> 
> 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).

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.

	M.
  

On Thu, 3 Nov 2022 13:12:10 +0000, Usama Arif wrote:
> This includes table format and using reST labels for
> cross-referencing to vcpu.rst.

Applied to kvm-arm64/misc-6.2, thanks!

[1/1] kvm/arm: Fix pvtime documentation
      commit: e7442ac1da07910f4731cb812c05484e4be2d4de

Cheers,

	M.
  

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?
  

On Fri, 04 Nov 2022 01:48:21 +0000,
Bagas Sanjaya <bagasdotme@gmail.com> 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.
  

On 11/4/22 18:06, Marc Zyngier wrote:
> On Fri, 04 Nov 2022 01:48:21 +0000,
> Bagas Sanjaya <bagasdotme@gmail.com> 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!