All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Peter Fang <peter.fang@intel.com>
Cc: Yosry Ahmed <yosry@kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	 Madhavan Srinivasan <maddy@linux.ibm.com>,
	Nicholas Piggin <npiggin@gmail.com>,
	kvm@vger.kernel.org,  linuxppc-dev@lists.ozlabs.org,
	linux-kernel@vger.kernel.org,
	 KarimAllah Ahmed <karahmed@amazon.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [PATCH] KVM: Fix kvm_vcpu_map[_readonly]() function prototypes
Date: Thu, 2 Apr 2026 16:52:24 -0700	[thread overview]
Message-ID: <ac8BOGXIPMnJ7kIg@google.com> (raw)
In-Reply-To: <acxjMsx/UixNa2R/@pedri>

On Tue, Mar 31, 2026, Peter Fang wrote:
> On Tue, Mar 31, 2026 at 02:22:47AM +0000, Yosry Ahmed wrote:
> > 
> > Most callers are converting a GPA to a GFN, I wonder if we should make

Not most, all.  The two outliers just do "gpa >> PAGE_SHIFT" instead of
using gpa_to_gfn().

> > the function take in a GPA instead? But then we'll need to the GPA not
> > being aligned to a page boundary (either do gpa_to_gfn() in
> > __kvm_vcpu_map() or fail if it's not aligned).

Just do gpa_to_pfn().  If someone gets confused, we can add a comment explaining
that kvm_vcpu_map() maps the entire page containing the gpa, but that should really
go without saying...

> Thanks for the feedback!
> 
> Mapping guest memory into the host feels more like a GFN-based operation
> to me. struct kvm_host_map is also designed around GFNs/PFNs so I think
> using gfn_t in the function prototypes seems more natural. The caller
> can handle the offset-in-page cases without creating a lot of complexity
> in the APIs. But I'm happy to rework this if there's a desire to make
> them more GPA-friendly.

I vote to rework the APIs (after first fixing the prototypes) to take a GPA.
I agree that mapping a page at a given gfn is conceptually more natural, but
as Yosry points out, requiring literally every caller to convert to a gfn doesn't
make a whole lot of sense from a code maintenance perspective.

  reply	other threads:[~2026-04-02 23:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-25  9:15 [PATCH] KVM: Fix kvm_vcpu_map[_readonly]() function prototypes Peter Fang
2026-03-31  2:22 ` Yosry Ahmed
2026-04-01  0:13   ` Fang, Peter
2026-04-02 23:52     ` Sean Christopherson [this message]
2026-04-03 10:18       ` Fang, Peter
2026-04-04  9:37   ` Ritesh Harjani
2026-04-06 20:19     ` Peter Fang

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=ac8BOGXIPMnJ7kIg@google.com \
    --to=seanjc@google.com \
    --cc=karahmed@amazon.de \
    --cc=konrad.wilk@oracle.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.ibm.com \
    --cc=npiggin@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.fang@intel.com \
    --cc=yosry@kernel.org \
    /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.