Messages in this thread | | | Date | Thu, 5 Jan 2023 16:04:51 +0100 | From | Borislav Petkov <> | Subject | Re: [PATCH RFC v7 03/64] KVM: SVM: Advertise private memory support to KVM |
| |
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
| |