Received-SPF: pass (google.com: domain of linux-kernel+bounces-41227-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Message-ID: <c0e1cd6a-4065-51ac-a398-aa48245f748f@amd.com>
Date: Sat, 27 Jan 2024 08:43:57 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.15.1
Subject: Re: [PATCH 04/11] x86/sev: Use kernel provided SVSM Calling Areas
Content-Language: en-US
To: Dionna Amalie Glaze <dionnaglaze@google.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
 Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>,
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
 "H. Peter Anvin" <hpa@zytor.com>, Andy Lutomirski <luto@kernel.org>,
 Peter Zijlstra <peterz@infradead.org>,
 Dan Williams <dan.j.williams@intel.com>, Michael Roth
 <michael.roth@amd.com>, Ashish Kalra <ashish.kalra@amd.com>
References: <cover.1706307364.git.thomas.lendacky@amd.com>
 <8de29476ed1fcfeae79cbe43ee6dbbfecf7e86ea.1706307364.git.thomas.lendacky@amd.com>
 <CAAH4kHZh1AdjLBNZ-=R6MK3OUmaSSFPWi==C0KVnTOCfVJkYBA@mail.gmail.com>
From: Tom Lendacky <thomas.lendacky@amd.com>
In-Reply-To: <CAAH4kHZh1AdjLBNZ-=R6MK3OUmaSSFPWi==C0KVnTOCfVJkYBA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?d0VhNWNDM2pVRitxZ3NkWVE1VEN6VnNja2xDSkd6bG0vMnV5YW1ORkc3Tlo1?=
 =?utf-8?B?QUpGK1EyUUNWMXNkOENZUUVrTWwxcGZCUXgwMk1Yd2I3Z0ZPOTJLV3YzeEVR?=
 =?utf-8?B?WXNhbWkzcU9scG1UWmtWc0FxL1BrRUhFT2pGaEhIeW1CNHVLMzVxb3BxZ241?=
 =?utf-8?B?VXg2ejNOeGhybTRqWFZhZmdkL29BTTVoczl1TVlSL0M2NWxhRDM4c25BMEo3?=
 =?utf-8?B?SHZWbFA5aUlvQ1VnRFJ1dm1Jd3B0bU5QdmlXQVZjaVRCRXkzRzBXK05nSXpi?=
 =?utf-8?B?QkpqOXdZM2s5WlBBZDBoNitXaDN3S2JlUWhieGpWcklqQ1FIU3MzM2VybVJl?=
 =?utf-8?B?Y3Y1RDNIZk05bTlQOUxtTlVpM2FXZTBIZkJqRStKdXptaTdvdDdSd1p1R1Rn?=
 =?utf-8?B?WHNtWmlDNWF0TWxDbDdnYmRWWHQ3Z0oxdU5KeTdUUVNLeTJmWTFMMnMyVVpi?=
 =?utf-8?B?UmllbEtlUmk4aGpOVi81VDVndzByaXBsK2V1OEJDaVN2bWFsSXV5NnF3MFRI?=
 =?utf-8?B?WlJ2NjRtaDFiUStGL1pnN3AxZ01xb2ZOMndzbCtsa3V6NnArMFBvUCsrWVJL?=
 =?utf-8?B?VkxIY3Z5SnRtR1NkQmdJNTBwcEtzWHZSZmxuUzVUL0xlc0F5R2pXakVaTE13?=
 =?utf-8?B?a1pDWmFKa3pNYVdBMnZneTBuT1ZtSGpEblQ5bjYxVjhDRlhZOENXOFF2QkZo?=
 =?utf-8?B?NERUcHNOa1FmUFcrVTVnYzBGNW1qSTJtM0hFVTNUUFZucHY0eWVBZDAvMEMr?=
 =?utf-8?B?Nk5wLzBqTzlwZHEzSlRjUVpyYVJpYXNDYW9XSjlhU3pBK3EySXlSTkxNRUtU?=
 =?utf-8?B?cm5uQUM4VXN0Y2VUcWpwVE9HSlZBSytybk5LOE8zeXVCdjRpQVU3WWdkUzdo?=
 =?utf-8?B?bzhkNmd3cUhaMkJkb1NjenozTnNzOGd1UVdKS1pXZDhQNW1oSkZFYlBLd2s5?=
 =?utf-8?B?dXhKSGVuL2lBWTUzYmFaTTJvWWFRdGM5VWhFREo0SUFFTVlTWnlqYzJkbDI4?=
 =?utf-8?B?U1FibHRPMWhweWhtSko0Q3lKblZ1bGErSitMRWlldVBjNzRXU3FNTFlaSHpG?=
 =?utf-8?B?MGprMVlSS2pYYjhVT0plWFpkUGM5UUp1NVVzTlNUOS90Y05KRlBwMW5Pem5I?=
 =?utf-8?B?TkoyeVpDaUpBeVlsaE1GZ21HdklXKzhVRFpmUVR3ZDd0cGJXeHp1WVZvY2VI?=
 =?utf-8?B?eWltSnNLbHR2amc1b2xSWWVFa0NEbllnS24ySVBScElDVi8zNzNrL29NNVc1?=
 =?utf-8?B?dUNDQ0kwc1BvS2FMK05sUCtoWEtnRDh5QlJnZ0RNaGlQODI4V21QZ25vVHRY?=
 =?utf-8?B?UlNVb21jai9Sa25NRlFxOEhGL042TmxLb1NpKzAzaHMzTzljRWErRWpFaFFr?=
 =?utf-8?B?MHhnRWpSTFpNVlZqZytiWDJLTnZCeVJMQllsVjkrRFRGaExtZDNteVF6SVdO?=
 =?utf-8?B?K21wekludFhRS3VlTE5KbFpWTWJkeS9rRWNzbEpLaVZ3V0tJTTNKVzUrYm5t?=
 =?utf-8?B?N3o5YUNDeTRnVmdPdi9JY3h1L2h5Ti9wZER5S0FEbUMxdTBDZklzVlNDU3c3?=
 =?utf-8?B?TG9zUVQ4OGx1ajV4bnMyZkJ0MFZUZmVwVHNxbHBDN1ZrSTdneDBOVVJGWXVY?=
 =?utf-8?B?UjdaM3JjUGRtdnRMNDNtNHFidXFpWktLVU04WXBJbDFlU2dnUFNqU0hHNXRm?=
 =?utf-8?B?d0JRU1cyQWM5NVNidXVwY0ppcWxGNW1RYVJXVllkcW1nSFhvRlAwdmpQT3F0?=
 =?utf-8?B?UTVwd0tSbUpoQzlEbXNiS3preTlaQ3grVUYraEhzdzE4MzdIZEdTN0pjZlVO?=
 =?utf-8?B?RllQaVlrL0dpMGtMKzFZTEl2MG5uN1lzRi9xcDRkNWZVNXVMUnpXa21OYTFu?=
 =?utf-8?B?WjhjUWZKV21oRFZCTHBTdTNtdzlsWXdDa3FtUUR2UzBjNXF0NHNlaTRHNVM0?=
 =?utf-8?B?cnYxRDVSMHpOb0VRY0hSakQvd0gvTDczUDlHK2pQMkYyaU9NWUsvWXlZREc5?=
 =?utf-8?B?c2gxZDFITytiRmdtTUlBeDZTckY3VE1iV1h4bXhlNDBPb0poNllyVjdkcEYw?=
 =?utf-8?B?QmRYdXZUZks0Q25kODJTZTI5eUNlREtyb1RaYjgzM2s5d084R2laUXh0SWdB?=
 =?utf-8?Q?iNI85IEvlIV/5L1q+dOibmT15?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b359acc7-9f75-4841-97ab-08dc1f466605
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5732.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2024 14:44:00.0618
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: jQ+NxQRzlUsimDTODvUWhLHneUjTUNPuaCgYsP+a3nOPVM7IB4TivlXo/a3IYcgXw79fG18V9/6lWRrzA72TkQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4926

On 1/26/24 18:45, Dionna Amalie Glaze wrote:
> On Fri, Jan 26, 2024 at 2:17 PM Tom Lendacky <thomas.lendacky@amd.com> wrote:
>>
>> The SVSM Calling Area (CA) is used to communicate between Linux and the
>> SVSM. Since the firmware supplied CA for the BSP is likely to be in
>> reserved memory, switch off that CA to a kernel provided CA so that access
>> and use of the CA is available during boot. The CA switch is done using
>> the SVSM core protocol SVSM_CORE_REMAP_CAA call.
> 
> REMAP_CA, not CAA.

Will fix.

> 
>>
>> An SVSM call is executed by filling out the SVSM CA and setting the proper
>> register state as documented by the SVSM protocol. The SVSM is invoked by
>> by requesting the hypervisor to run VMPL0.
>>
>> Once it is safe to allocate/reserve memory, allocate a CA for each CPU.
>> After allocating the new CAs, the BSP will switch from the boot CA to the
>> per-CPU CA. The CA for an AP is identified to the SVSM when creating the
>> VMSA in preparation for booting the AP.
>>
>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>> ---
>>   arch/x86/include/asm/sev-common.h |  13 ++
>>   arch/x86/include/asm/sev.h        |  32 +++++
>>   arch/x86/include/uapi/asm/svm.h   |   1 +
>>   arch/x86/kernel/sev-shared.c      |  94 +++++++++++++-
>>   arch/x86/kernel/sev.c             | 207 +++++++++++++++++++++++++-----
>>   arch/x86/mm/mem_encrypt_amd.c     |   8 +-
>>   6 files changed, 320 insertions(+), 35 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/sev-common.h b/arch/x86/include/asm/sev-common.h
>> index 68a8cdf6fd6a..71db5ba020b9 100644
>> --- a/arch/x86/include/asm/sev-common.h
>> +++ b/arch/x86/include/asm/sev-common.h

>> +
>> +#define SVSM_CORE_CALL(x)              ((0ULL << 32) | (x))
> 
> Given that we should expect to see other SVSM protocols used in the
> kernel, should we not have
> 
> #define SVSM_PROTOCOL_CALL(protocol, call) (((unsigned long)(protocol)
> << 32) | (call))
> #define SVSM_CORE_PROTOCOL 0
> #define SVSM_ATTESTATION_PROTOCOL 1
> #define SVSM_VTPM_PROTOCOL 2
> 
> And then
> 
> #define SVSM_CORE_CALL(x) SVSM_PROTOCOL_CALL(SVSM_CORE_PROTOCOL, x)
> 
> or be cute and use symbol concatenation like
> 
> #define SVSM_PROTOCOL_ID(id) SVSM_##id##_PROTOCOL
> #define SVSM_CALL(id, call) SVSM_PROTOCOL_CALL(SVSM_PROTOCOL_ID(id), call)
> 
> So you can just do SVSM_CALL(CORE, 0) ?

I thought about doing things along that line. You could do it any number 
of ways, but it really just comes down to preference. I decided with just 
the explicit SVSM_CORE_CALL() form.

Thanks,
Tom

>