mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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
> 


  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®