From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9F58BC43334 for ; Wed, 22 Jun 2022 19:50:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 247448E00EB; Wed, 22 Jun 2022 15:50:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 21EEA8E00E7; Wed, 22 Jun 2022 15:50:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0E6D48E00EB; Wed, 22 Jun 2022 15:50:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id F1D898E00E7 for ; Wed, 22 Jun 2022 15:50:29 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id CC1A0343EF for ; Wed, 22 Jun 2022 19:50:29 +0000 (UTC) X-FDA: 79606913778.15.7C16476 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by imf31.hostedemail.com (Postfix) with ESMTP id 391E1200B9 for ; Wed, 22 Jun 2022 19:50:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1655927427; x=1687463427; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=jK+Ip8TKjyJwk/sGYsCBvnwDGqA6k0xPk+0Grxe5TNg=; b=On9Ew3JAJhkz35R7R7knTsgwz4/h8VqntyCNMq7TdD0sdy27bS3d3NyT gjx8xc9TFnrZkvHei3v4cc8naAs35omEOnuohGjaG7Z5B0wcVLwqFEiMP zVc2pGtLmDTlxV9m+pmg6+lmsN55a49MA8WDLVUdW31d1vJ0XY1Eajo6o NnFEqtkOv2aUgbilOEMGSVxrTsnUztMm6vy5CvyguCZRYE6JEuPlHqQsd od7VzriHn6AuP84FPzejHRKKo3hS1eqLrF9FKwbEhGHDkpDV/8vympA2u Cy7UY2/uG1i/NV45vDjq8E079ln+ChjTFUOWMWvOeTlfDeFI5Gx02f4m+ Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10386"; a="263562096" X-IronPort-AV: E=Sophos;i="5.92,212,1650956400"; d="scan'208";a="263562096" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Jun 2022 12:50:13 -0700 X-IronPort-AV: E=Sophos;i="5.92,212,1650956400"; d="scan'208";a="677720725" Received: from bshakya-mobl.amr.corp.intel.com (HELO [10.212.188.76]) ([10.212.188.76]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Jun 2022 12:50:11 -0700 Message-ID: <5db37cc2-4fb1-7a73-c39a-3531260414d0@intel.com> Date: Wed, 22 Jun 2022 12:49:52 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH Part2 v6 05/49] x86/sev: Add RMP entry lookup helpers Content-Language: en-US To: "Kalra, Ashish" , "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" , "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" , "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" References: <8f63961f00fd170ba0e561f499292175f3155d26.1655761627.git.ashish.kalra@amd.com> <25be3068-be13-a451-86d4-ff4cc12ddb23@intel.com> <681e4e45-eff1-600c-9b81-1fa9bdf24232@intel.com> <99d72d58-a9bb-d75c-93af-79d497dfe176@intel.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655927427; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=1J4t68R9wm9IAHpBSUioIMmYatlc8Gl9nRLppxGLhDg=; b=ijY7Qa2KMWY5WsqmO6PCAOCboHDo9LNltOeyyiz5WG4lSPorBiguRihIGECIPD+KfL6MI2 FS0aTnbqyUU/G9I0dXthbNjk8lKSB4kVni1I/AF9h7tlXHRNETgCj0Tb/xn4WbHMY/CT7+ Xr1zHBrVsBKxngvVVlINPyJiShkrmAk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655927427; a=rsa-sha256; cv=none; b=mdVUSbzUhiwychGvtfdT48s8ec7a1tLATElvJxmMYYFTIPosKSKFzZ+Kd1bfRUoka7LUg3 +3IVgq28BK5SxoYQNnhkwTX1CCMX2z4qStNbY4whPkISYJHmkTi/XT7K3yGVDLwW4IRCrp mUKhmcSebXfgMNPvzujEZn85DY7StwM= ARC-Authentication-Results: i=1; imf31.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=On9Ew3JA; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf31.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 134.134.136.126) smtp.mailfrom=dave.hansen@intel.com X-Stat-Signature: 18d18pbyy7gyfj56w33rg3a1k6dpipeo X-Rspamd-Queue-Id: 391E1200B9 Authentication-Results: imf31.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=On9Ew3JA; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf31.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 134.134.136.126) smtp.mailfrom=dave.hansen@intel.com X-Rspamd-Server: rspam02 X-Rspam-User: X-HE-Tag: 1655927427-125131 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 6/22/22 12:43, Kalra, Ashish wrote: >> 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. That will be helpful down the road when there's more than one format. But, the real issue is that the kernel doesn't *support* a different RMP format. So, the SNP support should be disabled when encountering a model/family other than the known good one.