Received-SPF: pass (google.com: domain of linux-kernel+bounces-183811-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <f8a92b19-9090-40ea-c2cf-707005f583a5@amd.com>
Date: Mon, 20 May 2024 08:57:43 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.15.1
Content-Language: en-US
To: Borislav Petkov <bp@alien8.de>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org, linux-coco@lists.linux.dev,
 svsm-devel@coconut-svsm.dev, Thomas Gleixner <tglx@linutronix.de>,
 Ingo Molnar <mingo@redhat.com>, 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.1713974291.git.thomas.lendacky@amd.com>
 <6cf54cac47f212f4c2b59b123855d8c183989022.1713974291.git.thomas.lendacky@amd.com>
 <20240502093520.GRZjNeWLXU5j2UMOAM@fat_crate.local>
 <66928741-aa5c-4bbb-9155-dc3a0609c50a@amd.com>
 <20240517155858.GDZkd-wkWmYegos-eT@fat_crate.local>
From: Tom Lendacky <thomas.lendacky@amd.com>
Subject: Re: [PATCH v4 04/15] x86/sev: Check for the presence of an SVSM in
 the SNP Secrets page
In-Reply-To: <20240517155858.GDZkd-wkWmYegos-eT@fat_crate.local>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?YmVwNW4ySXRsUGQzMzRwd2tvUWJjdnJ4Z2FTOXVsbE9rWEIxKytmOTN5M0lZ?=
 =?utf-8?B?WUJ6Nm9LZ2gwa0E2bmpPYWthSmV5OG5BVjR6Uy9ydk5Ub09rY2NqbmJlUFpI?=
 =?utf-8?B?cXlINGR3c21GTE8xVlBRQi9VNmxUbjU0TEszY2hkN3hyd3A0Rlg1NUVmelpV?=
 =?utf-8?B?cGlpU0J4c0ZGR1dQN3dSVzh1YnE0c2dQOWZucm56KzcyUHZQQk5WSlN3RXo3?=
 =?utf-8?B?SGw0L3Z2cVJDU0lHYlZVbnB1aXpoN3VsbzZ4bWFaRmxXSnpUbHJETXNkS1hI?=
 =?utf-8?B?K2tlQXRxZHh0VEdMNzhWeWxmMmxqTkljQWhqcmIrTk1pajE0WHkveHlod2Rq?=
 =?utf-8?B?c2dBaHJSREdpWkMrcmhRVlIyVWVlZEFFWUVucjMrM0pwS0MwcFllR29yWWY3?=
 =?utf-8?B?NDU2Z2dVUWI4dlZMdzUvMVV4NlNveU0xVERJSUNjYjFaWGtrOHpsR1Zzb2tT?=
 =?utf-8?B?SDRDbDZGQXdWVkg2b1paVzhZb0hiV1R6eTE1T3lSRkViWEJxNlcxOXpIMEhF?=
 =?utf-8?B?bE01V2wyM3FONU1MOGlUR2NwVk0xTXR2U2ZYdy80N291TnRIWnhCOVdnL0xU?=
 =?utf-8?B?TWFuSU9vZnk5WmlKVmU4QmlWdVAzZVNXZjd1bWR4VDZ2eG1VanhnRWVwcGs5?=
 =?utf-8?B?NnpYWGN4QWRteGNHbk9zbFRFUzBNQWYxLzFROWltT1U4RlVMQXlRT0ZtNnMw?=
 =?utf-8?B?Rk9SMWc1TkNJZkM5cmxDdGdWYlUwZ3JtMXRHMVkyUURIclN0K0cySndhRHhV?=
 =?utf-8?B?bzZQdnVHRFJwS3haR1J4dWpqV0l0VEtUS3dWZ05Bb3JQV0tXSWVpNHVEWHBv?=
 =?utf-8?B?Wlg2SW5zV3hLRDE1VkdiVW85eWQ3ZS82cWJGMFNsdkl3Z01hNUd5OVduKzN3?=
 =?utf-8?B?UkxsMUZ4RW5yWFdsUTJ2Q0hXZHVVMVArMjhoTUtrTWtwUXl3SUwrN2xGWVo4?=
 =?utf-8?B?Q2cvdkU2a2VMSTZjb1gxOHFVZnBnTHZGZ3dKK2ZycnBHd1Jkc0VmTi9DTXo1?=
 =?utf-8?B?dmZkUjJ6S3JSSlVhaXYxTFV4bUVxUFFjUFhNdkJqOVpNcGtjemJuSUhPUmlI?=
 =?utf-8?B?SmZMc3pHUGNkQ3dxYzFQRkdrTVhGNldHa0NWaEU3N1loVUhaRmdmZlVKSVl3?=
 =?utf-8?B?UzNOazdHS2RoWVdoa1dSZ0ZhTnpWaVVFMGNvV01iVmh3QW5xck5udjJodzkw?=
 =?utf-8?B?ek5pcWJyaThraHFmcUx0V1RHY1lOaVNQSG9wWHorNDJtM1hMd3FaRjRkUkls?=
 =?utf-8?B?WWxXeXA4ODRXYlRiZVlRY0hJcEdVU0VCT1ZRZXltd0cyYVYwUXBqQjBDY0Rh?=
 =?utf-8?B?cThjT09nVncyTjFGdCtkTVUrWHVsNUFHOExsQU41bHdCd2RWR3ovZlVDR2pa?=
 =?utf-8?B?cEhxZzBUMWEzMk12K0Y1VmhhOGdRb3BaN2cyeDV3dTRzNkxGc0tnWUt4Zzlm?=
 =?utf-8?B?VXZOMlpKVjZGTFpPMzFpTjU5d1UrbG1SNUV2RExNUU5FYzk3RWRtd08waGtN?=
 =?utf-8?B?Vk9mZitCNnhRM3FDcGJMRnl3dDk4NlVFR3FKQlk0clRMeDdHY0ZUZXRSaEFY?=
 =?utf-8?B?cUMzQnFtT3locTNnRmtWazdvNkx0dW9oalRSN3pBd1ZTMUdmMlZua0RvWWE1?=
 =?utf-8?B?VmUzRDJTWU9tNjBxSW5yNlhlSGhVQWxGamw1elpCZEN6OHlxZE5xdWV4OGM4?=
 =?utf-8?B?UnltWU5LY0t2a0tmM1JzWkhoampqTk5BMVR5bExpTUNqVE5IblRnLzYwVDh2?=
 =?utf-8?B?eDgzM0ViRlhUQzM0SHpGZ0lVV0ppSmFpT1hNOHRUUERGWFQwWVlGVEc5d3Np?=
 =?utf-8?B?WWM5Z0R2dEFsVDg4UXp2TUc2UWw4bWpPRDVwTytJWkJPMFlGcjdGV3ZYV1Qz?=
 =?utf-8?B?bVFVWTVQTlI4UFZVYURGbHNERWdkamQvSXJLUTVtMEpuaEVXcFVQSWErNXRR?=
 =?utf-8?B?TWNtOGpQNUNNc0pTM25kSWJnVFFWZzg2ajRsZTByUDlXQ0duQVEwcDFPeVYx?=
 =?utf-8?B?WHQ0MmJVYVMxYzBDZENFR1BkTkthU2ZPaHBHMjU2VnhHWWNVSGtWcGhXWXRU?=
 =?utf-8?B?Q3hNa2lBTC93d2M1ODg2eXRoTjZYTGtHWjBJaVBZbEtzb0J4YlJ6Q242V3Vr?=
 =?utf-8?Q?IjH9bkh5IF3QR4zZGvFDI9qFN?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f434e58c-ae14-4ec2-3233-08dc78d4d38c
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5732.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 May 2024 13:57:45.9340
 (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: rneZGh8mAk8oMPb0ceAcAflYfuLS4/bA/MLoPOzEnuek0iA4xHbKPPqYKrQaHWFaRcsUBcPR9Mz6lS6wQiQYXg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8187

On 5/17/24 10:58, Borislav Petkov wrote:
> On Thu, May 02, 2024 at 10:29:02AM -0500, Tom Lendacky wrote:
>> PAGE_ALIGNED and IS_ALIGNED are from two separate header files (mm.h and
>> align.h) which seems like a lot of extra changes for just one check.
> 
> No, pls put them in a single shared/mm.h header. And no, those are not
> a lot of extra changes - those are changes which are moving the code in
> the right direction and we do them sooner rather than later, otherwise
> they'd pile up and we'll never be able to find time to do them - sev.c
> movement attempt case-in-point.

So this will be a new shared directory in the top level include 
directory (as PAGE_ALIGNED is defined in include/linux/mm.h), not just 
in the arch/x86/include directory like the others (io.h, msr.h and 
tdx.h). Is that what you want?

Thanks,
Tom

> 
>> Not sure I agree. I'd prefer to keep the comment here because it is
>> specific to this rmpadjust() call. See below.
> 
> Just don't replicate some versions of the same comment all over the
> place. Do one big comment which explains which RMPADJUST has to do with
> VMPL levels - perhaps over the insn - and then refer to it from the
> other places after adding the specific explanations for them.
> 
>> Right. Not sure about the "cannot", more like "must not." The specification
>> states that the guest should run at a VMPL other than 0. If an SVSM starts
>> the guest at VMPL0, then the SVSM would not be protected from guest.
> 
> Yeah, well, you do terminate the guest if it is running at VMPL 0 *in*
> the presence of a SVSM so it is a "must not". Ok.
>