linux-kernel - Re: [PATCH v8 07/16] x86/sev: Move and reorganize sev guest request api

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 23 Apr 2024 09:56:38 +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 07/16] x86/sev: Move and reorganize sev guest request
 api

On 4/22/2024 6:44 PM, Borislav Petkov wrote:
> On Thu, Feb 15, 2024 at 05:01:19PM +0530, Nikunj A Dadhania wrote:
>> Subject: Re: [PATCH v8 07/16] x86/sev: Move and reorganize sev guest request api
> 
> s/api/API/g
> 
> Please check your whole patchset for proper naming/abbreviations
> spelling, etc.
> 
> Another one: s/sev/SEV/g and so on. You should know the drill by now.

Sure.

>> For enabling Secure TSC, SEV-SNP guests need to communicate with the
>> AMD Security Processor early during boot. Many of the required
>> functions are implemented in the sev-guest driver and therefore not
>> available at early boot. Move the required functions and provide
>> API to the sev guest driver for sending guest message and vmpck
>> routines.
> 
> Patches which move and reorganize must always be split: first patch(es):
> you do *purely* *mechanical* move without any code changes. 

Yes, I had tried that compilation/guest boot does not break at this stage. 
That was the reason for intermixing movement and code change.

Let me give a second stab at this and I will try just to make sure compilation does not break.

> Then you do the code changes ontop so that a reviewer can have a chance of seeing
> what you're doing.

Sure

Regards,
Nikunj