On 4/23/2024 3:58 PM, Borislav Petkov wrote: > On Tue, Apr 23, 2024 at 09:52:41AM +0530, Nikunj A. Dadhania wrote: >> SNP guest messaging will be moving as part of sev.c, and Secure TSC code >> will use this mutex. > > No, this is all backwards. > > You have a *static* function in sev-guest - snp_guest_ioctl- which takes > an exported lock - snp_guest_cmd_lock - in order to synchronize with > other callers which are only in that same sev-guest driver. > > Why do you even need the guest messaging in sev.c? > > I guess this: "Many of the required functions are implemented in the > sev-guest driver and therefore not available at early boot." Yes. > > But then your API is misdesigned: the lock should be private to sev.c > and none of the callers should pay attention to grabbing it - the > callers simply call the functions and underneath the locking works > automatically for them - they don't care. Just like any other shared > resource, users see only the API they call and the actual > synchronization is done behind the scenes. > > Sounds like you need to go back to the drawing board and think how this > thing should look like. Something like below ? snp_guest_ioctl() -> get_report()/get_derived_key()/get_ext_report() -> snp_send_guest_request() snp_guest_cmd_lock(); ... snp_guest_cmd_lock(); With this the cmd_lock will be private to sev.c and lock/unlock function doesn't need to be exported. Regards Nikunj