Re: [PATCH v3 2/8] x86/sev: Add support for the RMPREAD instruction

[Tom Lendacky <thomas.lendacky@amd.com>]

On 10/17/24 10:26, Borislav Petkov wrote:
> On Mon, Sep 30, 2024 at 10:22:10AM -0500, Tom Lendacky wrote:
>> +	if (cpu_feature_enabled(X86_FEATURE_RMPREAD)) {
>> +		int ret;
>> +
>> +		asm volatile(".byte 0xf2, 0x0f, 0x01, 0xfd"
>> +			     : "=a" (ret)
>> +			     : "a" (pfn << PAGE_SHIFT), "c" (entry)
>> +			     : "memory", "cc");
>> +
>> +		return ret;
>> +	}
>> +
>>  	e = __get_rmpentry(pfn);
> 
> So dump_rmpentry() still calls this but it doesn't require the newly added
> services of RMPREAD and so this is looking to be disambiguated: a function
> which gives you the entry coming from RMPREAD, I guess the architectural one,
> and the other one.

Right, because for debugging purposes we want to dump the raw RMP entry
that is in the RMP table, not just the information returned by RMPREAD
(since RMPREAD doesn't return everything defined in the RMP entry).

This is why dump_rmpentry() merely prints out the RMP entry as two u64
values.

> 
> IOW, I am still unclear on the nomenclature:
> 
> The _raw* entries do not come from the insn but then what's the raw-ness about
> them?

The raw-ness is that it is the actual data in the RMP table. The reason
for RMPREAD is because there is no guarantee that the raw data won't be
reformatted in a future program, which is why we only allow access to
the RMP entry for Milan and Genoa, where the format is known and the same.

Thanks,
Tom

> 
> This convention sounds weird as it is now, I'd say.
> 
> Thx.
>