From: "Fang, Peter" <peter.fang@intel.com>
To: Yosry Ahmed <yosry@kernel.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Sean Christopherson <seanjc@google.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: Tue, 31 Mar 2026 17:13:38 -0700 [thread overview]
Message-ID: <acxjMsx/UixNa2R/@pedri> (raw)
In-Reply-To: <acsvbxIdtlQzUw4q@google.com>
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
> 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).
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.
>
> Not sure if that's a net improvement, mostly thinking out loud here.
next prev parent reply other threads:[~2026-04-01 0:13 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 [this message]
2026-04-02 23:52 ` Sean Christopherson
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=acxjMsx/UixNa2R/@pedri \
--to=peter.fang@intel.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=seanjc@google.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.