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
>>
>>
prev parent reply other threads:[~2021-06-15 10:08 UTC|newest]
Thread overview: 2+ 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
[not found] ` <87mtrrihgl.wl-maz@kernel.org>
2021-06-15 10:08 ` wangyanan (Y) [this message]
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).