Re: [PATCH v4 1/8] x86/sev: Prepare for using the RMPREAD instruction to access the RMP

[Tom Lendacky]

On 10/25/24 04:00, Kalra, Ashish wrote:
> , 
> On 10/23/2024 1:41 PM, Tom Lendacky wrote:
>> The RMPREAD instruction returns an architecture defined format of an
>> RMP entry. This is the preferred method for examining RMP entries.
>>
>> In preparation for using the RMPREAD instruction, convert the existing
>> code that directly accesses the RMP to map the raw RMP information into
>> the architecture defined format.
>>
>> RMPREAD output returns a status bit for the 2MB region status. If the
>> input page address is 2MB aligned and any other pages within the 2MB
>> region are assigned, then 2MB region status will be set to 1. Otherwise,
>> the 2MB region status will be set to 0. For systems that do not support
>> RMPREAD, calculating this value would require looping over all of the RMP
>> table entries within that range until one is found with the assigned bit
>> set. Since this bit is not defined in the current format, and so not used
>> today, do not incur the overhead associated with calculating it.
>>
>> Signed-off-by: Tom Lendacky <thomas.lendacky@xxxxxxx>
>> ---
>>  arch/x86/virt/svm/sev.c | 121 +++++++++++++++++++++++++++++-----------
>>  1 file changed, 87 insertions(+), 34 deletions(-)
>>
>> diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c
>> index 0ce17766c0e5..4d095affdb4d 100644
>> --- a/arch/x86/virt/svm/sev.c
>> +++ b/arch/x86/virt/svm/sev.c

>>  
>> -	entry = get_rmpentry(pfn);
>> -	if (IS_ERR(entry))
>> -		return entry;
>> +	if (unlikely(pfn > rmptable_max_pfn))
> 
> rmptable_max_pfn is initialized in patch#5, shouldn't this patch be moved after patch #5 ?
> 
>> +		return ERR_PTR(-EFAULT);
>> +
>> +	return rmptable + pfn;
> 
> Again, rmptable is initialized/setup in patch#5, similarly shouldn't this patch be moved
> after patch #5 ?

rmptable_max_pfn is initialized in snp_rmptable_init(), as is rmptable.

Thanks,
Tom

> 
> Thanks,
> Ashish
>