On Thu, 2024-05-16 at 12:25 +1200, Huang, Kai wrote:
On 16/05/2024 12:19 pm, Edgecombe, Rick P wrote:
On Thu, 2024-05-16 at 12:12 +1200, Huang, Kai wrote:
I don't have strong objection if the use of kvm_gfn_shared_mask() is
contained in smaller areas that truly need it. Let's discuss in
relevant patch(es).
However I do think the helpers like below makes no sense (for SEV-SNP):
+static inline bool kvm_is_private_gpa(const struct kvm *kvm, gpa_t gpa)
+{
+ gfn_t mask = kvm_gfn_shared_mask(kvm);
+
+ return mask && !(gpa_to_gfn(gpa) & mask);
+}
You mean the name? SNP doesn't have a concept of "private GPA" IIUC. The C
bit
is more like an permission bit. So SNP doesn't have private GPAs, and the
function would always return false for SNP. So I'm not sure it's too
horrible.
Hmm.. Why SNP doesn't have private GPAs? They are crypto-protected and
KVM cannot access directly correct?
I suppose a GPA could be pointing to memory that is private. But I think in SNP
it is more the memory that is private. Now I see more how it could be confusing.
If it's the name, can you suggest something?
The name make sense, but it has to reflect the fact that a given GPA is
truly private (crypto-protected, inaccessible to KVM).
If this was a function that tested whether memory is private and took a GPA, I
would call it is_private_mem() or something. Because it's testing the memory and
takes a GPA, not testing the GPA. Usually a function name should be about what
the function does, not what arguments it takes.
I can't think of a better name, but point taken that it is not ideal. I'll try
to think of something.