[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6a7a8892-bb8d-4f03-a802-d7eee48045b5@amd.com>
Date: Tue, 23 Apr 2024 09:52:41 +0530
From: "Nikunj A. Dadhania" <nikunj@....com>
To: Borislav Petkov <bp@...en8.de>
Cc: linux-kernel@...r.kernel.org, thomas.lendacky@....com, x86@...nel.org,
kvm@...r.kernel.org, mingo@...hat.com, tglx@...utronix.de,
dave.hansen@...ux.intel.com, pgonda@...gle.com, seanjc@...gle.com,
pbonzini@...hat.com
Subject: Re: [PATCH v8 06/16] virt: sev-guest: Move SNP Guest command mutex
On 4/22/2024 6:30 PM, Borislav Petkov wrote:
> On Thu, Feb 15, 2024 at 05:01:18PM +0530, Nikunj A Dadhania wrote:
>> SNP command mutex is used to serialize the shared buffer access, command
>> handling and message sequence number races. Move the SNP guest command
>> mutex out of the sev guest driver and provide accessors to sev-guest
>
> And why in the hell are we doing this?
SNP guest messaging will be moving as part of sev.c, and Secure TSC code
will use this mutex.
> Always, *ALWAYS* make sure a patch's commit message answers *why*
> a change is done. This doesn't explain why so I'm reading "just because"
> and "just because" doesn't fly.
Sure, will change.
>
>> driver. Remove multiple lockdep check in sev-guest driver, next patch adds
>> a single lockdep check in snp_send_guest_request().
>
> The concept of "next patch" is meaningless once the patch is in git.
Sure. As direct access to the mutex was not available now, I had removed lockdep
check here and documented that lockdep gets added at later point.
Regards
Nikunj
Powered by blists - more mailing lists