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 6E4E1C433EF for ; Tue, 28 Jun 2022 19:04:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ABC0E8E0001; Tue, 28 Jun 2022 15:04:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A6B496B0072; Tue, 28 Jun 2022 15:04:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 90C3D8E0001; Tue, 28 Jun 2022 15:04:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 819366B0071 for ; Tue, 28 Jun 2022 15:04:47 -0400 (EDT) Received: from smtpin31.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 54E53E1A for ; Tue, 28 Jun 2022 19:04:47 +0000 (UTC) X-FDA: 79628571414.31.A1E4541 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by imf02.hostedemail.com (Postfix) with ESMTP id C4AAF80041 for ; Tue, 28 Jun 2022 19:04:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1656443085; x=1687979085; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=N1AIQgmubreattzHLRnM0HT3Yc8fAoLHRwgDBlBS8LA=; b=PtVPRbFGOirr4yMASiCFOErbJDINFvRlKyc+ruYqvoaG2BSEQI1gwZMS n7Cyn3OvE9X7VvFBybPtHpPRVOs4cP2ubLi0vaeXwNhlHYRqGESs+xEjV 9roksrhSzmDI+ZInyvkdCLQ9ezJ2lGTXh7rprjGmMFk9hiAmJZFo9bHMF CT7jxTYmgX/UZ01fW949mfkYhfuMIpEcxfZewl/JoJClUX45Zr8rjcMv1 bQUvAyhKJIexdjtFreIl7VnYIX9/dV+TCizAE0rEP2ahot+ATtAI78huS ioWZLOxk8qhYfGhKp83rzVIwzvleE0RG87Y581/3w0n0epnMo17ZYfjJv A==; X-IronPort-AV: E=McAfee;i="6400,9594,10392"; a="282559364" X-IronPort-AV: E=Sophos;i="5.92,229,1650956400"; d="scan'208";a="282559364" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jun 2022 12:04:44 -0700 X-IronPort-AV: E=Sophos;i="5.92,229,1650956400"; d="scan'208";a="587977804" Received: from staibmic-mobl1.amr.corp.intel.com (HELO [10.209.67.166]) ([10.209.67.166]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jun 2022 12:04:43 -0700 Message-ID: <33e38ba3-0865-8a9f-0739-af25a63d0beb@intel.com> Date: Tue, 28 Jun 2022 12:03:38 -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 06/49] x86/sev: Add helper functions for RMPUPDATE and PSMASH instruction Content-Language: en-US To: "Kalra, Ashish" , "Dr. David Alan Gilbert" Cc: "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" , "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" , "jarkko@kernel.org" References: From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656443086; a=rsa-sha256; cv=none; b=k5+wFlkGQDfo9wFhRLSX4PKzUItSWDm/gO0cnisTHWUf6qJU4RFVksza9oOn60yWzm1ZeB aCVJah2F2UcYVjoAujTp/cRD/t6v4pVd/9VdXzmLPea8glgxhfr7zy8Sy+GhljdiWsqIoW PMpDeNE5FwMi/1+Jehb9+B9Gl1fkQE8= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=PtVPRbFG; spf=none (imf02.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 134.134.136.24) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656443086; 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=gpRiKxY38033qLU1aVwF1e8IiAKz7V9UArtAJ2GQDWM=; b=wiOwp72QoGIGjvF++r94XtUnQLqbIEJnWC2IS9cgN/Arh7U2m83NVYfn/J+kZ14gecQhLF uUBoIc+dI1GFk3tkhGMEpzGAilbphfg5u5kwgPtDYbHWw9gFkbk3DS/nxDXKoMBlJFgwWC VdhoXyt/YuBzqnFxYFBSO9/ltPdMxRg= X-Rspam-User: Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=PtVPRbFG; spf=none (imf02.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 134.134.136.24) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspamd-Server: rspam02 X-Stat-Signature: qp791ybqzrcsjgpy6rspfgwkdtqkifir X-Rspamd-Queue-Id: C4AAF80041 X-HE-Tag: 1656443085-227618 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/28/22 10:57, Kalra, Ashish wrote: > + /* > + * RMP table entry format is not architectural and it can vary by processor and > + * is defined by the per-processor PPR. Restrict SNP support on the known CPU > + * model and family for which the RMP table entry format is currently defined for. > + */ > + if (family != 0x19 || model > 0xaf) > + goto nosnp; > + > > This way SNP will only be enabled specifically on the platforms for which this RMP entry > format is defined in those processor's PPR. This will work for Milan and Genoa as of now. At some point, it would be really nice if the AMD side of things could work to kick the magic number habit on these things. This: arch/x86/include/asm/intel-family.h has been really handy. It lets you do things like grep INTEL_FAM6_SKYLAKE arch/x86 That's a *LOT* more precise than: egrep -i '0x5E|94' arch/x86