On 1/10/23 02:48, Huang, Kai wrote: >>> >>> + /* >>> + * Use the first private KeyID as the global KeyID, and pass >>> + * it along with the TDMRs to the TDX module. >>> + */ >>> + ret = config_tdx_module(&tdmr_list, tdx_keyid_start); >>> + if (ret) >>> + goto out_free_pamts; >> This is "consuming" tdx_keyid_start. Does it need to get incremented >> since the first guest can't use this KeyID now? > > It depends on how we treat 'tdx_keyid_start'. If it means the first _usable_ > KeyID for KVM, then we should increase it; but if it only used for the hardware- > enabled TDX KeyID range, then we don't need to increase it. > > Currently it is marked as __ro_after_init so my intention is the latter (also in > the spirit of keeping this series minimal). > > Eventually we will need to have functions to allocate/free TDX KeyIDs anyway for > KVM, but in that we can just treat 'tdx_keyid_start + 1' as the first usable > KeyID. So, basically, you're going to depend on the KVM code (which isn't in this series) to magically know exactly what this series did? Then, you're expecting that this code will never change in a way that breaks this random KVM code? That's frankly awful. Make the variable read/write. Call it tdx_guest_keyid_start, and increment it when you make a keyid unavailable for guest use.
