Re: [edk2-devel] [PATCH RFC v2 01/28] MdePkg: Expand the SEV MSR to include the SNP definition

["Brijesh Singh" <brijesh.singh@amd.com>]

On 5/3/21 3:39 AM, Laszlo Ersek wrote:
> On 04/30/21 13:51, Brijesh Singh wrote:
>> BZ: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D3275&data=04%7C01%7Cbrijesh.singh%40amd.com%7Ceea6f3b3eab148c16fdf08d90e0ef790%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637556279729207954%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=i4WYjB4hqOLiQR8dZyCLjSd8iUrE0QILyRavcHAEmGY%3D&reserved=0
>>
>> Define the SEV-SNP MSR bits.
>>
>> Cc: James Bottomley <jejb@linux.ibm.com>
>> Cc: Min Xu <min.m.xu@intel.com>
>> Cc: Jiewen Yao <jiewen.yao@intel.com>
>> Cc: Tom Lendacky <thomas.lendacky@amd.com>
>> Cc: Jordan Justen <jordan.l.justen@intel.com>
>> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
>> Cc: Laszlo Ersek <lersek@redhat.com>
>> Cc: Erdem Aktas <erdemaktas@google.com>
>> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
>> ---
>>  MdePkg/Include/Register/Amd/Fam17Msr.h | 7 ++++++-
>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/MdePkg/Include/Register/Amd/Fam17Msr.h b/MdePkg/Include/Register/Amd/Fam17Msr.h
>> index e4db09c518..4d33bef220 100644
>> --- a/MdePkg/Include/Register/Amd/Fam17Msr.h
>> +++ b/MdePkg/Include/Register/Amd/Fam17Msr.h
>> @@ -87,7 +87,12 @@ typedef union {
>>      ///
>>      UINT32  SevEsBit:1;
>>  
>> -    UINT32  Reserved:30;
>> +    ///
>> +    /// [Bit 2] Secure Nested Paging (SevSnp) is enabled
>> +    ///
>> +    UINT32  SevSnpBit:1;
>> +
>> +    UINT32  Reserved:29;
>>    } Bits;
>>    ///
>>    /// All bit fields as a 32-bit value
>>
> (1) When changing a Reserved field's meaning, the field should be
> renamed. Usually we do this by numbering, and the numbers only ever
> increase. This is because code might exist that uses a Reserved field.
> Such code should be prevented from compiling, because that's much better
> than silently breaking its behavior. So the new name of the field should
> be Reserved2.
>
> (If we modify Reserved2 later, it should be renamed to Reserved3, and so
> on -- we should never return to a field name used before.)


Noted, I will fix it in next rev. thanks