All of lore.kernel.org
 help / color / mirror / Atom feed
From: "wangyanan (Y)" <wangyanan55@huawei.com>
To: Marc Zyngier <maz@kernel.org>
Cc: James Morse <james.morse@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<kvmarm@lists.cs.columbia.edu>, <linux-kernel@vger.kernel.org>,
	<yuzenghui@huawei.com>, <wanghaibin.wang@huawei.com>
Subject: Re: [PATCH] KVM: arm64: Fix inconsistency from function comment of __unmap_stage2_range
Date: Tue, 15 Jun 2021 18:08:42 +0800	[thread overview]
Message-ID: <d10107ec-6448-e69c-ecad-6d24c3dd42ae@huawei.com> (raw)
In-Reply-To: <87mtrrihgl.wl-maz@kernel.org>



On 2021/6/15 17:51, Marc Zyngier wrote:
> On Tue, 15 Jun 2021 10:04:36 +0100,
> Yanan Wang <wangyanan55@huawei.com> wrote:
>> Commit 'b5331379bc626'
>> (KVM: arm64: Only reschedule if MMU_NOTIFIER_RANGE_BLOCKABLE is not set)
>> has converted the original function name 'unmap_stage2_range' to
>> '__unmap_stage2_range', but leaving the corresponding function comment
>> unadjusted. So fix it for code readability.
>>
>> Incidentally, we also tewak some comment identation by using tabs instead
>> of spaces to be consistent with the other functions.
>>
>> Signed-off-by: Yanan Wang <wangyanan55@huawei.com>
> Same as the previous patch. The first hunk is OK, as it fixes an
> actual defect (wrong documentation), and adjusting the alignment is OK
> as your changing the context.
>
> However, the last 3 are just noise. Please drop them.
Ok, will drop them.

Thanks,
Yanan
> Thanks,
>
> 	M.
>
>> ---
>>   arch/arm64/kvm/mmu.c | 18 +++++++++---------
>>   1 file changed, 9 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>> index 5742ba765ff9..80040af147a2 100644
>> --- a/arch/arm64/kvm/mmu.c
>> +++ b/arch/arm64/kvm/mmu.c
>> @@ -151,11 +151,11 @@ static void *kvm_host_va(phys_addr_t phys)
>>    * does.
>>    */
>>   /**
>> - * unmap_stage2_range -- Clear stage2 page table entries to unmap a range
>> - * @mmu:   The KVM stage-2 MMU pointer
>> - * @start: The intermediate physical base address of the range to unmap
>> - * @size:  The size of the area to unmap
>> - * @may_block: Whether or not we are permitted to block
>> + * __unmap_stage2_range -- Clear stage2 page table entries to unmap a range
>> + * @mmu:	The KVM stage-2 MMU pointer
>> + * @start:	The intermediate physical base address of the range to unmap
>> + * @size:	The size of the area to unmap
>> + * @may_block:	Whether or not we are permitted to block
>>    *
>>    * Clear a range of stage-2 mappings, lowering the various ref-counts.  Must
>>    * be called while holding mmu_lock (unless for freeing the stage2 pgd before
>> @@ -190,7 +190,7 @@ static void stage2_flush_memslot(struct kvm *kvm,
>>   
>>   /**
>>    * stage2_flush_vm - Invalidate cache for pages mapped in stage 2
>> - * @kvm: The struct kvm pointer
>> + * @kvm:	The struct kvm pointer
>>    *
>>    * Go through the stage 2 page tables and invalidate any cache lines
>>    * backing memory already mapped to the VM.
>> @@ -527,7 +527,7 @@ static void stage2_unmap_memslot(struct kvm *kvm,
>>   
>>   /**
>>    * stage2_unmap_vm - Unmap Stage-2 RAM mappings
>> - * @kvm: The struct kvm pointer
>> + * @kvm:	The struct kvm pointer
>>    *
>>    * Go through the memregions and unmap any regular RAM
>>    * backing memory already mapped to the VM.
>> @@ -578,7 +578,7 @@ void kvm_free_stage2_pgd(struct kvm_s2_mmu *mmu)
>>    * @guest_ipa:	The IPA at which to insert the mapping
>>    * @pa:		The physical address of the device
>>    * @size:	The size of the mapping
>> - * @writable:   Whether or not to create a writable mapping
>> + * @writable:	Whether or not to create a writable mapping
>>    */
>>   int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa,
>>   			  phys_addr_t pa, unsigned long size, bool writable)
>> @@ -616,7 +616,7 @@ int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa,
>>   
>>   /**
>>    * stage2_wp_range() - write protect stage2 memory region range
>> - * @mmu:        The KVM stage-2 MMU pointer
>> + * @mmu:	The KVM stage-2 MMU pointer
>>    * @addr:	Start address of range
>>    * @end:	End address of range
>>    */
>> -- 
>> 2.23.0
>>
>>


WARNING: multiple messages have this Message-ID (diff)
From: "wangyanan (Y)" <wangyanan55@huawei.com>
To: Marc Zyngier <maz@kernel.org>
Cc: Will Deacon <will@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	linux-kernel@vger.kernel.org, kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] KVM: arm64: Fix inconsistency from function comment of __unmap_stage2_range
Date: Tue, 15 Jun 2021 18:08:42 +0800	[thread overview]
Message-ID: <d10107ec-6448-e69c-ecad-6d24c3dd42ae@huawei.com> (raw)
In-Reply-To: <87mtrrihgl.wl-maz@kernel.org>



On 2021/6/15 17:51, Marc Zyngier wrote:
> On Tue, 15 Jun 2021 10:04:36 +0100,
> Yanan Wang <wangyanan55@huawei.com> wrote:
>> Commit 'b5331379bc626'
>> (KVM: arm64: Only reschedule if MMU_NOTIFIER_RANGE_BLOCKABLE is not set)
>> has converted the original function name 'unmap_stage2_range' to
>> '__unmap_stage2_range', but leaving the corresponding function comment
>> unadjusted. So fix it for code readability.
>>
>> Incidentally, we also tewak some comment identation by using tabs instead
>> of spaces to be consistent with the other functions.
>>
>> Signed-off-by: Yanan Wang <wangyanan55@huawei.com>
> Same as the previous patch. The first hunk is OK, as it fixes an
> actual defect (wrong documentation), and adjusting the alignment is OK
> as your changing the context.
>
> However, the last 3 are just noise. Please drop them.
Ok, will drop them.

Thanks,
Yanan
> Thanks,
>
> 	M.
>
>> ---
>>   arch/arm64/kvm/mmu.c | 18 +++++++++---------
>>   1 file changed, 9 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>> index 5742ba765ff9..80040af147a2 100644
>> --- a/arch/arm64/kvm/mmu.c
>> +++ b/arch/arm64/kvm/mmu.c
>> @@ -151,11 +151,11 @@ static void *kvm_host_va(phys_addr_t phys)
>>    * does.
>>    */
>>   /**
>> - * unmap_stage2_range -- Clear stage2 page table entries to unmap a range
>> - * @mmu:   The KVM stage-2 MMU pointer
>> - * @start: The intermediate physical base address of the range to unmap
>> - * @size:  The size of the area to unmap
>> - * @may_block: Whether or not we are permitted to block
>> + * __unmap_stage2_range -- Clear stage2 page table entries to unmap a range
>> + * @mmu:	The KVM stage-2 MMU pointer
>> + * @start:	The intermediate physical base address of the range to unmap
>> + * @size:	The size of the area to unmap
>> + * @may_block:	Whether or not we are permitted to block
>>    *
>>    * Clear a range of stage-2 mappings, lowering the various ref-counts.  Must
>>    * be called while holding mmu_lock (unless for freeing the stage2 pgd before
>> @@ -190,7 +190,7 @@ static void stage2_flush_memslot(struct kvm *kvm,
>>   
>>   /**
>>    * stage2_flush_vm - Invalidate cache for pages mapped in stage 2
>> - * @kvm: The struct kvm pointer
>> + * @kvm:	The struct kvm pointer
>>    *
>>    * Go through the stage 2 page tables and invalidate any cache lines
>>    * backing memory already mapped to the VM.
>> @@ -527,7 +527,7 @@ static void stage2_unmap_memslot(struct kvm *kvm,
>>   
>>   /**
>>    * stage2_unmap_vm - Unmap Stage-2 RAM mappings
>> - * @kvm: The struct kvm pointer
>> + * @kvm:	The struct kvm pointer
>>    *
>>    * Go through the memregions and unmap any regular RAM
>>    * backing memory already mapped to the VM.
>> @@ -578,7 +578,7 @@ void kvm_free_stage2_pgd(struct kvm_s2_mmu *mmu)
>>    * @guest_ipa:	The IPA at which to insert the mapping
>>    * @pa:		The physical address of the device
>>    * @size:	The size of the mapping
>> - * @writable:   Whether or not to create a writable mapping
>> + * @writable:	Whether or not to create a writable mapping
>>    */
>>   int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa,
>>   			  phys_addr_t pa, unsigned long size, bool writable)
>> @@ -616,7 +616,7 @@ int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa,
>>   
>>   /**
>>    * stage2_wp_range() - write protect stage2 memory region range
>> - * @mmu:        The KVM stage-2 MMU pointer
>> + * @mmu:	The KVM stage-2 MMU pointer
>>    * @addr:	Start address of range
>>    * @end:	End address of range
>>    */
>> -- 
>> 2.23.0
>>
>>

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

WARNING: multiple messages have this Message-ID (diff)
From: "wangyanan (Y)" <wangyanan55@huawei.com>
To: Marc Zyngier <maz@kernel.org>
Cc: James Morse <james.morse@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<kvmarm@lists.cs.columbia.edu>, <linux-kernel@vger.kernel.org>,
	<yuzenghui@huawei.com>, <wanghaibin.wang@huawei.com>
Subject: Re: [PATCH] KVM: arm64: Fix inconsistency from function comment of __unmap_stage2_range
Date: Tue, 15 Jun 2021 18:08:42 +0800	[thread overview]
Message-ID: <d10107ec-6448-e69c-ecad-6d24c3dd42ae@huawei.com> (raw)
In-Reply-To: <87mtrrihgl.wl-maz@kernel.org>



On 2021/6/15 17:51, Marc Zyngier wrote:
> On Tue, 15 Jun 2021 10:04:36 +0100,
> Yanan Wang <wangyanan55@huawei.com> wrote:
>> Commit 'b5331379bc626'
>> (KVM: arm64: Only reschedule if MMU_NOTIFIER_RANGE_BLOCKABLE is not set)
>> has converted the original function name 'unmap_stage2_range' to
>> '__unmap_stage2_range', but leaving the corresponding function comment
>> unadjusted. So fix it for code readability.
>>
>> Incidentally, we also tewak some comment identation by using tabs instead
>> of spaces to be consistent with the other functions.
>>
>> Signed-off-by: Yanan Wang <wangyanan55@huawei.com>
> Same as the previous patch. The first hunk is OK, as it fixes an
> actual defect (wrong documentation), and adjusting the alignment is OK
> as your changing the context.
>
> However, the last 3 are just noise. Please drop them.
Ok, will drop them.

Thanks,
Yanan
> Thanks,
>
> 	M.
>
>> ---
>>   arch/arm64/kvm/mmu.c | 18 +++++++++---------
>>   1 file changed, 9 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>> index 5742ba765ff9..80040af147a2 100644
>> --- a/arch/arm64/kvm/mmu.c
>> +++ b/arch/arm64/kvm/mmu.c
>> @@ -151,11 +151,11 @@ static void *kvm_host_va(phys_addr_t phys)
>>    * does.
>>    */
>>   /**
>> - * unmap_stage2_range -- Clear stage2 page table entries to unmap a range
>> - * @mmu:   The KVM stage-2 MMU pointer
>> - * @start: The intermediate physical base address of the range to unmap
>> - * @size:  The size of the area to unmap
>> - * @may_block: Whether or not we are permitted to block
>> + * __unmap_stage2_range -- Clear stage2 page table entries to unmap a range
>> + * @mmu:	The KVM stage-2 MMU pointer
>> + * @start:	The intermediate physical base address of the range to unmap
>> + * @size:	The size of the area to unmap
>> + * @may_block:	Whether or not we are permitted to block
>>    *
>>    * Clear a range of stage-2 mappings, lowering the various ref-counts.  Must
>>    * be called while holding mmu_lock (unless for freeing the stage2 pgd before
>> @@ -190,7 +190,7 @@ static void stage2_flush_memslot(struct kvm *kvm,
>>   
>>   /**
>>    * stage2_flush_vm - Invalidate cache for pages mapped in stage 2
>> - * @kvm: The struct kvm pointer
>> + * @kvm:	The struct kvm pointer
>>    *
>>    * Go through the stage 2 page tables and invalidate any cache lines
>>    * backing memory already mapped to the VM.
>> @@ -527,7 +527,7 @@ static void stage2_unmap_memslot(struct kvm *kvm,
>>   
>>   /**
>>    * stage2_unmap_vm - Unmap Stage-2 RAM mappings
>> - * @kvm: The struct kvm pointer
>> + * @kvm:	The struct kvm pointer
>>    *
>>    * Go through the memregions and unmap any regular RAM
>>    * backing memory already mapped to the VM.
>> @@ -578,7 +578,7 @@ void kvm_free_stage2_pgd(struct kvm_s2_mmu *mmu)
>>    * @guest_ipa:	The IPA at which to insert the mapping
>>    * @pa:		The physical address of the device
>>    * @size:	The size of the mapping
>> - * @writable:   Whether or not to create a writable mapping
>> + * @writable:	Whether or not to create a writable mapping
>>    */
>>   int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa,
>>   			  phys_addr_t pa, unsigned long size, bool writable)
>> @@ -616,7 +616,7 @@ int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa,
>>   
>>   /**
>>    * stage2_wp_range() - write protect stage2 memory region range
>> - * @mmu:        The KVM stage-2 MMU pointer
>> + * @mmu:	The KVM stage-2 MMU pointer
>>    * @addr:	Start address of range
>>    * @end:	End address of range
>>    */
>> -- 
>> 2.23.0
>>
>>


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-06-15 10:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-15  9:04 [PATCH] KVM: arm64: Fix inconsistency from function comment of __unmap_stage2_range Yanan Wang
2021-06-15  9:04 ` Yanan Wang
2021-06-15  9:04 ` Yanan Wang
2021-06-15  9:51 ` Marc Zyngier
2021-06-15  9:51   ` Marc Zyngier
2021-06-15 10:08   ` wangyanan (Y) [this message]
2021-06-15 10:08     ` wangyanan (Y)
2021-06-15 10:08     ` wangyanan (Y)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d10107ec-6448-e69c-ecad-6d24c3dd42ae@huawei.com \
    --to=wangyanan55@huawei.com \
    --cc=alexandru.elisei@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=james.morse@arm.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=suzuki.poulose@arm.com \
    --cc=wanghaibin.wang@huawei.com \
    --cc=will@kernel.org \
    --cc=yuzenghui@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.