Thread (97 messages) 97 messages, 14 authors, 2022-11-03

Re: [PATCH v8 5/8] KVM: Register/unregister the guest private memory regions

From: Fuad Tabba <hidden>
Date: 2022-10-19 18:33:05
Also in: kvm, linux-doc, linux-fsdevel, linux-mm, lkml, qemu-devel

On Wed, Oct 19, 2022 at 5:09 PM Sean Christopherson [off-list ref] wrote:
On Wed, Oct 19, 2022, Fuad Tabba wrote:
quoted
quoted
quoted
quoted
This sounds good. Thank you.
I like the idea of a separate Kconfig, e.g. CONFIG_KVM_GENERIC_PRIVATE_MEM or
something.  I highly doubt there will be any non-x86 users for multiple years,
if ever, but it would allow testing the private memory stuff on ARM (and any other
non-x86 arch) without needing full pKVM support and with only minor KVM
modifications, e.g. the x86 support[*] to test UPM without TDX is shaping up to be
trivial.
CONFIG_KVM_GENERIC_PRIVATE_MEM looks good to me.
That sounds good to me, and just keeping the xarray isn't really an
issue for pKVM.
The xarray won't exist for pKVM if the #ifdefs in this patch are changed from
CONFIG_HAVE_KVM_PRIVATE_MEM => CONFIG_KVM_GENERIC_PRIVATE_MEM.
quoted
We could end up using it instead of some of the other
structures we use for tracking.
I don't think pKVM should hijack the xarray for other purposes.  At best, it will
be confusing, at worst we'll end up with a mess if ARM ever supports the "generic"
implementation.
Definitely wasn't referring to hijacking it for other purposes, which
is the main reason I wanted to clarify the documentation and the
naming of private_fd. Anyway, I'm glad to see that we're in agreement.
Once I've tightened the screws, I'll share the pKVM port as an RFC as
well.

Cheers,
/fuad
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help