On 1/15/25 20:14, Edgecombe, Rick P wrote:
It looks like you missed these build issues and bugs from v2:
https://lore.kernel.org/
kvm/6345272506c5bc707f11b6f54c4bd5015cedcd95.camel@xxxxxxxxx/
https://lore.kernel.org/
kvm/3f8fa8fc98b532add1ff14034c0c868cdbeca7f8.camel@xxxxxxxxx/
I did, I'll update tomorrow and repost.
WRT hkid, I interpreted "I'd personally probably just keep 'hkid' as an
int everywhere until the point where it gets shoved into the TDX module
ABI" as "it can be u16 in the SEAMCALLs and in mk_keyed_paddr" (as the
latter builds an argument to the SEAMCALLs).
I understood his objection to be more about
tdx_guest_keyid_alloc/tdx_guest_keyid_free and struct kvm_tdx:
Oh, and casts like this:
static inline void tdx_disassociate_vp(struct kvm_vcpu *vcpu)
@@ -2354,7 +2354,8 @@ static int __tdx_td_init(struct kvm *kvm, struct td_params *td_params,
ret = tdx_guest_keyid_alloc();
if (ret < 0)
return ret;
- kvm_tdx->hkid = ret;
+ kvm_tdx->hkid = (u16)ret;
+ kvm_tdx->hkid_assigned = true;
are a bit silly, don't you think?
so I didn't change tdx_guest_keyid_alloc().
Paolo
