On Wed, Oct 19, 2022 at 5:09 PM Sean Christopherson <[email protected]> wrote: > > On Wed, Oct 19, 2022, Fuad Tabba wrote: > > > > > 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. > > > 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
