On Wed, Jan 04, 2023 at 08:14:19PM -0600, Michael Roth wrote: > Maybe that's not actually enforced, by it seems awkward to try to use a > bool return instead. At least for KVM_X86_OP_OPTIONAL_RET0(). I don't see there being a problem/restriction for bool functions, see 5be2226f417d ("KVM: x86: allow defining return-0 static calls") and __static_call_return0() returns a long which, if you wanna interpret as bool, works too as "false". I still need to disassemble and single-step through a static_call to see what all that magic does in detail, to be sure. > However, we could just use KVM_X86_OP() to declare it so we can cleanly > use a function that returns bool, and then we just need to do: > > bool kvm_arch_has_private_mem(struct kvm *kvm) > { > if (kvm_x86_ops.private_mem_enabled) > return static_call(kvm_x86_private_mem_enabled)(kvm); That would be defeating the whole purpose of static calls, AFAICT, as you're testing the pointer. Might as well leave it be a normal function pointer then. > On a separate topic though, at a high level, this hook is basically a way > for platform-specific code to tell generic KVM code that private memslots > are supported by overriding the kvm_arch_has_private_mem() weak > reference. In this case the AMD platform is using using kvm->arch.upm_mode > flag to convey that, which is in turn set by the > KVM_CAP_UNMAPPED_PRIVATE_MEMORY introduced in this series. > > But if, as I suggested in response to your PATCH 2 comments, we drop > KVM_CAP_UNAMMPED_PRIVATE_MEMORY in favor of > KVM_SET_SUPPORTED_MEMORY_ATTRIBUTES ioctl to enable "UPM mode" in SEV/SNP > code, then we need to rethink things a bit, since KVM_SET_MEMORY_ATTRIBUTES > in-part relies on kvm_arch_has_private_mem() to determine what flags are > supported, whereas SEV/SNP code would be using what was set by > KVM_SET_MEMORY_ATTRIBUTES to determine the return value in > kvm_arch_has_private_mem(). > > So, for AMD, the return value of kvm_arch_has_private_mem() needs to rely > on something else. Maybe the logic can just be: > > bool svm_private_mem_enabled(struct kvm *kvm) > { > return sev_enabled(kvm) || sev_snp_enabled(kvm) I haven't followed the whole discussion in detail but this means that SEV/SNP *means* UPM. I.e., no SEV/SNP without UPM, correct? I guess that's the final thing you guys decided to do ... Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette