From: Paul Durrant <xadimgnik@gmail.com>
To: Sean Christopherson <seanjc@google.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Paul Durrant <pdurrant@amazon.com>,
David Woodhouse <dwmw@amazon.co.uk>,
David Woodhouse <dwmw2@infradead.org>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH v7 01/11] KVM: pfncache: add a map helper function
Date: Thu, 2 Nov 2023 17:09:40 +0000 [thread overview]
Message-ID: <d912e3ee-f2e5-4c40-99cd-214b16fe8fac@xen.org> (raw)
In-Reply-To: <ZUGL0syLTH09BbsI@google.com>
On 31/10/2023 23:20, Sean Christopherson wrote:
> On Mon, Oct 02, 2023, Paul Durrant wrote:
>> From: Paul Durrant <pdurrant@amazon.com>
>
> Please make the changelog standalone, i.e. don't rely on the shortlog to provide
> context. Yeah, it can be silly and repetive sometimes, particularly when viewing
> git commits where the shortlog+changelog are bundled fairly close together, but
> when viewing patches in a mail client, e.g. when I'm doing initial review, the
> shortlog is in the subject which may be far away or even completely hidden (as is
> the case as I'm typing this).
>
> I could have sworn I included this in Documentation/process/maintainer-kvm-x86.rst,
> but I'm not finding it.
>
OK, I'll add some more text.
>> We have an unmap helper but mapping is open-coded. Arguably this is fine
>
> Pronouns.
>
Sorry... didn't realize that was an issue.
>> because mapping is done in only one place, hva_to_pfn_retry(), but adding
>> the helper does make that function more readable.
>>
>> No functional change intended.
>>
>> Signed-off-by: Paul Durrant <pdurrant@amazon.com>
>> Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
>> ---
>> Cc: Sean Christopherson <seanjc@google.com>
>> Cc: David Woodhouse <dwmw2@infradead.org>
>> Cc: Paolo Bonzini <pbonzini@redhat.com>
>> ---
>> virt/kvm/pfncache.c | 43 +++++++++++++++++++++++++------------------
>> 1 file changed, 25 insertions(+), 18 deletions(-)
>>
>> diff --git a/virt/kvm/pfncache.c b/virt/kvm/pfncache.c
>> index 2d6aba677830..0f36acdf577f 100644
>> --- a/virt/kvm/pfncache.c
>> +++ b/virt/kvm/pfncache.c
>> @@ -96,17 +96,28 @@ bool kvm_gpc_check(struct gfn_to_pfn_cache *gpc, unsigned long len)
>> }
>> EXPORT_SYMBOL_GPL(kvm_gpc_check);
>>
>> -static void gpc_unmap_khva(kvm_pfn_t pfn, void *khva)
>> +static void *gpc_map(kvm_pfn_t pfn)
>> +{
>> + if (pfn_valid(pfn))
>> + return kmap(pfn_to_page(pfn));
>> +#ifdef CONFIG_HAS_IOMEM
>> + else
>
> There's no need for the "else", the happy path is terminal.
>
>> + return memremap(pfn_to_hpa(pfn), PAGE_SIZE, MEMREMAP_WB);
>> +#endif
>
> This needs a return for CONFIG_HAS_IOMEM=n. I haven't tried to compile, but I'm
> guessing s390 won't be happy.
>
Oops, yes, of course.
> This?
>
> static void *gpc_map(kvm_pfn_t pfn)
> {
> if (pfn_valid(pfn))
> return kmap(pfn_to_page(pfn));
>
> #ifdef CONFIG_HAS_IOMEM
> return memremap(pfn_to_hpa(pfn), PAGE_SIZE, MEMREMAP_WB);
> #else
> return NULL;
> #endif
> }
>
Looks good. Thanks,
Paul
>> +}
>> +
>> +static void gpc_unmap(kvm_pfn_t pfn, void *khva)
>> {
>> /* Unmap the old pfn/page if it was mapped before. */
>> - if (!is_error_noslot_pfn(pfn) && khva) {
>> - if (pfn_valid(pfn))
>> - kunmap(pfn_to_page(pfn));
>> + if (is_error_noslot_pfn(pfn) || !khva)
>> + return;
>> +
>> + if (pfn_valid(pfn))
>> + kunmap(pfn_to_page(pfn));
>> #ifdef CONFIG_HAS_IOMEM
>> - else
>> - memunmap(khva);
>> + else
>> + memunmap(khva);
>> #endif
>
> I don't mind the refactoring, but it needs to be at least mentioned in the
> changelog. And if we're going to bother, it probably makes sense to add a WARN
> in the CONFIG_HAS_IOMEM=n path, e.g.
>
> /* Unmap the old pfn/page if it was mapped before. */
> if (is_error_noslot_pfn(pfn) || !khva)
> return;
>
> if (pfn_valid(pfn))
> kunmap(pfn_to_page(pfn));
> else
> #ifdef CONFIG_HAS_IOMEM
> memunmap(khva);
> #else
> WARN_ON_ONCE(1);
> #endif
>
next prev parent reply other threads:[~2023-11-02 17:09 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-02 9:57 [PATCH v7 00/11] KVM: xen: update shared_info and vcpu_info handling Paul Durrant
2023-10-02 9:57 ` [PATCH v7 01/11] KVM: pfncache: add a map helper function Paul Durrant
2023-10-31 23:20 ` Sean Christopherson
2023-11-02 17:09 ` Paul Durrant [this message]
2023-10-02 9:57 ` [PATCH v7 02/11] KVM: pfncache: add a mark-dirty helper Paul Durrant
2023-10-31 23:28 ` Sean Christopherson
2023-11-02 17:52 ` Paul Durrant
2023-11-03 23:07 ` Sean Christopherson
2023-10-02 9:57 ` [PATCH v7 03/11] KVM: pfncache: add a helper to get the gpa Paul Durrant
2023-10-31 23:37 ` Sean Christopherson
2023-10-02 9:57 ` [PATCH v7 04/11] KVM: pfncache: base offset check on khva rather than gpa Paul Durrant
2023-10-31 23:40 ` Sean Christopherson
2023-11-02 18:11 ` Paul Durrant
2023-11-03 23:10 ` Sean Christopherson
2023-10-02 9:57 ` [PATCH v7 05/11] KVM: pfncache: allow a cache to be activated with a fixed (userspace) HVA Paul Durrant
2023-10-31 23:49 ` Sean Christopherson
2023-11-02 18:01 ` Paul Durrant
2023-11-03 23:12 ` Sean Christopherson
2023-10-02 9:57 ` [PATCH v7 06/11] KVM: xen: allow shared_info to be mapped by fixed HVA Paul Durrant
2023-10-31 23:52 ` Sean Christopherson
2023-10-02 9:57 ` [PATCH v7 07/11] KVM: xen: allow vcpu_info " Paul Durrant
2023-10-02 9:57 ` [PATCH v7 08/11] KVM: selftests / xen: map shared_info using HVA rather than GFN Paul Durrant
2023-10-02 9:57 ` [PATCH v7 09/11] KVM: selftests / xen: re-map vcpu_info using HVA rather than GPA Paul Durrant
2023-10-02 9:57 ` [PATCH v7 10/11] KVM: xen: advertize the KVM_XEN_HVM_CONFIG_SHARED_INFO_HVA capability Paul Durrant
2023-10-02 9:57 ` [PATCH v7 11/11] KVM: xen: allow vcpu_info content to be 'safely' copied Paul Durrant
2023-10-31 23:58 ` Sean Christopherson
2023-11-08 15:15 ` David Woodhouse
2023-11-08 20:55 ` Sean Christopherson
2023-11-08 21:56 ` David Woodhouse
2023-10-05 6:41 ` [PATCH v7 00/11] KVM: xen: update shared_info and vcpu_info handling David Woodhouse
2023-10-05 8:36 ` Paul Durrant
2023-11-09 10:02 ` David Woodhouse
2023-11-09 10:06 ` Paul Durrant
2023-10-30 12:00 ` Paul Durrant
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=d912e3ee-f2e5-4c40-99cd-214b16fe8fac@xen.org \
--to=xadimgnik@gmail.com \
--cc=dwmw2@infradead.org \
--cc=dwmw@amazon.co.uk \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paul@xen.org \
--cc=pbonzini@redhat.com \
--cc=pdurrant@amazon.com \
--cc=seanjc@google.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
all inboxes | Powered by JetHome®