Messages in this thread | | | From | "Kalra, Ashish" <> | Subject | RE: [PATCH Part2 v6 05/49] x86/sev: Add RMP entry lookup helpers | Date | Wed, 22 Jun 2022 19:43:24 +0000 |
| |
[AMD Official Use Only - General]
-----Original Message----- From: Dave Hansen <dave.hansen@intel.com> Sent: Wednesday, June 22, 2022 1:43 PM To: Kalra, Ashish <Ashish.Kalra@amd.com>; x86@kernel.org; linux-kernel@vger.kernel.org; kvm@vger.kernel.org; linux-coco@lists.linux.dev; linux-mm@kvack.org; linux-crypto@vger.kernel.org Cc: tglx@linutronix.de; mingo@redhat.com; jroedel@suse.de; Lendacky, Thomas <Thomas.Lendacky@amd.com>; hpa@zytor.com; ardb@kernel.org; pbonzini@redhat.com; seanjc@google.com; vkuznets@redhat.com; jmattson@google.com; luto@kernel.org; dave.hansen@linux.intel.com; slp@redhat.com; pgonda@google.com; peterz@infradead.org; srinivas.pandruvada@linux.intel.com; rientjes@google.com; dovmurik@linux.ibm.com; tobin@ibm.com; bp@alien8.de; Roth, Michael <Michael.Roth@amd.com>; vbabka@suse.cz; kirill@shutemov.name; ak@linux.intel.com; tony.luck@intel.com; marcorr@google.com; sathyanarayanan.kuppuswamy@linux.intel.com; alpergun@google.com; dgilbert@redhat.com; jarkko@kernel.org Subject: Re: [PATCH Part2 v6 05/49] x86/sev: Add RMP entry lookup helpers
On 6/22/22 11:34, Kalra, Ashish wrote: >>> So, if the RMP entry format changes in future processors, how do we >>> make sure that the kernel does not try to use *this* code on those >>> processors? >> Functions snp_lookup_rmpentry() and dump_rmpentry() which rely on this >> structure definition will need to handle it accordingly.
>In other words, old kernels will break on new hardware?
>I think that needs to be fixed. It should be as simple as a model/family check, though. If someone (for example) attempts to use SNP (and thus snp_lookup_rmpentry() and dump_rmpentry()) code on a newer CPU, the kernel should refuse.
More specifically I am thinking of adding RMP entry field accessors so that they can do this cpu model/family check and return the correct field as per processor architecture.
Thanks, Ashish
| |