[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <eadcab6f-b533-49e3-9aec-dc06036327f5@amd.com>
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
Powered by blists - more mailing lists