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 4D252C433EF for ; Tue, 28 Jun 2022 18:58:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6C2E26B0071; Tue, 28 Jun 2022 14:58:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 64AF88E0002; Tue, 28 Jun 2022 14:58:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4C4BA8E0001; Tue, 28 Jun 2022 14:58:25 -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 3BE4A6B0071 for ; Tue, 28 Jun 2022 14:58:25 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 1423C21FAB for ; Tue, 28 Jun 2022 18:58:25 +0000 (UTC) X-FDA: 79628555370.11.5618E8B Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf16.hostedemail.com (Postfix) with ESMTP id 93D52180048 for ; Tue, 28 Jun 2022 18:58:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1656442704; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2lf7QwNhxdo+quqMTGK7aQY+8Wzt942aQ0JT7PbSYKk=; b=SyTmFW282YTD3EDjwq1JfANHrUxwXkfqHVR6YVjWd+jXkq1AlYtPhrSZHp3Jb88kDyYHDk uiktWrVZkKBUVn4sdYXCIm+DJFG1imVbv5q04j9mebHr6egX3MXdYzfBVZ8P1W0DM9ueSc xVetUBGKoPmDN6t4buGA+qTyjCXl00U= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-132-wKSCJYqQMj-2z2ft_KdefQ-1; Tue, 28 Jun 2022 14:58:20 -0400 X-MC-Unique: wKSCJYqQMj-2z2ft_KdefQ-1 Received: by mail-wm1-f70.google.com with SMTP id n35-20020a05600c3ba300b003a02d7bd5caso7504126wms.2 for ; Tue, 28 Jun 2022 11:58:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=2lf7QwNhxdo+quqMTGK7aQY+8Wzt942aQ0JT7PbSYKk=; b=H6UvgRmpw6c1+UKmg3rTe4cLpLJjQNMxiHpX8Gs4eHSqR7sDWslRV3Nraz6G7A7z6j /h7w3P0LHHHEeZqINBSIZRG8DhSM4hdo3EIHsFarUkHCYH5exuhkWQ8e2D3iT0BXTs/Z tyezJfS0EeQ4o8rqjsU21abrozH3Fx5fCpeF12XC53GA1aN0ncc9tAwrbVSlyE4C02L4 i3DQEyc2lpgbEnSPVU245Qlw2/pIfHnUKpksgycSfCK6SJjSCb6iULrUudwyLgJdIARP yAnsHKQKTqWcg9/Jc9GYzsL9eFoT5Bs7heN56u9WQWpEHBgi2dA6Dlq/1TwLqfIy+9W5 WU2A== X-Gm-Message-State: AJIora8db8eJaZHCIh+nyRI1516OfEG49ZMO6siVDCx/H+PNkDU0sXkk ZZHrs3FngUNmMV1cTrceKNDMkGKUFn1ThBMcw2IhDc1hhOHC2JgGf8Ol32UJvj4CqNQp2tzoH8D GodlpXB5cp/g= X-Received: by 2002:a05:600c:5022:b0:39c:7f6c:ab44 with SMTP id n34-20020a05600c502200b0039c7f6cab44mr1136469wmr.97.1656442699757; Tue, 28 Jun 2022 11:58:19 -0700 (PDT) X-Google-Smtp-Source: AGRyM1szlySBmm8GkNFrjrCF0IMcWnh1Lja8Zw3SseqWkis7etEldh2DCLEG7RhUJHJijP9HlpeLSQ== X-Received: by 2002:a05:600c:5022:b0:39c:7f6c:ab44 with SMTP id n34-20020a05600c502200b0039c7f6cab44mr1136417wmr.97.1656442699439; Tue, 28 Jun 2022 11:58:19 -0700 (PDT) Received: from work-vm (cpc109025-salf6-2-0-cust480.10-2.cable.virginm.net. [82.30.61.225]) by smtp.gmail.com with ESMTPSA id s2-20020adfea82000000b0021b90d7b2c9sm14365759wrm.24.2022.06.28.11.58.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Jun 2022 11:58:18 -0700 (PDT) Date: Tue, 28 Jun 2022 19:58:15 +0100 From: "Dr. David Alan Gilbert" To: "Kalra, Ashish" 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" Subject: Re: [PATCH Part2 v6 06/49] x86/sev: Add helper functions for RMPUPDATE and PSMASH instruction Message-ID: References: MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/2.2.6 (2022-06-05) X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656442704; a=rsa-sha256; cv=none; b=Gy6saYJjjpBqarpQj2sCN3lKDi5Gg5eeiTr5+1y6RFysGXIyy80Bsw2+3G61+0PRgqEpcD dXwzOBBXelBuhUaAG3hclFXip+BIVdEq8ayiRk8MkzdmSzzrT7YaiPZPSll8nF+GtpyV31 o8GPVGadAKUz/glsh9qBPaM32HhSUWY= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=SyTmFW28; spf=none (imf16.hostedemail.com: domain of dgilbert@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=dgilbert@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656442704; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=2lf7QwNhxdo+quqMTGK7aQY+8Wzt942aQ0JT7PbSYKk=; b=WUCYOWbKB4hqx2MvrMNAOd1LVQaoWgNx4v3UeW5xRAbDrqPESn1Ve3fHxM7QOyga1ed6gz QTEEkLmj2AWSQBBrLrnOWMHVFnTXMMjtoLtGU6NvTb8EksmzjSZ8N5W/1qBgjczOs1zxdT JCPqPHdpwfdR4f0srgFtvvjy707SAhI= X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 93D52180048 X-Rspam-User: X-Stat-Signature: e9zfuzsx1zerhrsggd6pghj3tyeiqgoi Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=SyTmFW28; spf=none (imf16.hostedemail.com: domain of dgilbert@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=dgilbert@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-HE-Tag: 1656442704-417184 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: * Kalra, Ashish (Ashish.Kalra@amd.com) wrote: > [AMD Official Use Only - General] > > Hello Dave, > > -----Original Message----- > From: Dr. David Alan Gilbert > Sent: Tuesday, June 28, 2022 5:51 AM > To: Kalra, Ashish > 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 > Subject: Re: [PATCH Part2 v6 06/49] x86/sev: Add helper functions for RMPUPDATE and PSMASH instruction > > * Kalra, Ashish (Ashish.Kalra@amd.com) wrote: > > [AMD Official Use Only - General] > > > > >>> /* > > >>> * The RMP entry format is not architectural. The format is > > >>> defined in PPR @@ -126,6 +128,15 @@ struct snp_guest_platform_data { > > >>> u64 secrets_gpa; > > >>> }; > > >>> > > >>> +struct rmpupdate { > > >>> + u64 gpa; > > >>> + u8 assigned; > > >>> + u8 pagesize; > > >>> + u8 immutable; > > >>> + u8 rsvd; > > >>> + u32 asid; > > >>> +} __packed; > > > > >>I see above it says the RMP entry format isn't architectural; is this 'rmpupdate' structure? If not how is this going to get handled when we have a couple >of SNP capable CPUs with different layouts? > > > > >Architectural implies that it is defined in the APM and shouldn't change in such a way as to not be backward compatible. > > >I probably think the wording here should be architecture independent or more precisely platform independent. > > > > Some more clarity on this: > > > > Actually, the PPR for family 19h Model 01h, Rev B1 defines the RMP entry format as below: > > > > 2.1.4.2 RMP Entry Format > > Architecturally the format of RMP entries are not specified in APM. In order to assist software, the following table specifies select portions of the RMP entry format for this specific product. Each RMP entry is 16B in size and is formatted as follows. Software should not rely on any field definitions not specified in this table and the format of an RMP entry may change in future processors. > > > > Architectural implies that it is defined in the APM and shouldn't change in such a way as to not be backward compatible. So non-architectural in this context means that it is only defined in our PPR. > > > > So actually this RPM entry definition is platform dependent and will need to be changed for different AMD processors and that change has to be handled correspondingly in the dump_rmpentry() code. > > > You'll need a way to make that fail cleanly when run on a newer CPU with different layout, and a way to build kernels that can handle more than one layout. > > Yes, I will be adding a check for CPU family/model as following : > > static int __init snp_rmptable_init(void) > { > + int family, model; > > if (!boot_cpu_has(X86_FEATURE_SEV_SNP)) > return 0; > > + family = boot_cpu_data.x86; > + model = boot_cpu_data.x86_model; > > + /* > + * 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; please add a print there to say why you're not enabling SNP. It would be great if your firmware could give you an 'rmpentry version'; and then if a new model came out that happened to have the same layout everything would just carryon working by checking that rather than the actual family/model. > + > > 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. > > Additionally as per Sean's suggestion, I will be moving the RMP structure definition to sev.c, > which will make it a private structure and not exposed to other parts of the kernel. > > Also in the future we will have an architectural interface to read the RMP table entry, > we will first check for it's availability and if not available fall back to the RMP table > entry structure definition. Dave > Thanks, > Ashish > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK