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 B7ED7C433EF for ; Tue, 28 Jun 2022 10:50:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0D8DA8E0002; Tue, 28 Jun 2022 06:50:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 089728E0001; Tue, 28 Jun 2022 06:50:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E6B858E0002; Tue, 28 Jun 2022 06:50:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id D62838E0001 for ; Tue, 28 Jun 2022 06:50:46 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id A20AD60E78 for ; Tue, 28 Jun 2022 10:50:46 +0000 (UTC) X-FDA: 79627326492.28.4F7916D Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf28.hostedemail.com (Postfix) with ESMTP id 03880C0021 for ; Tue, 28 Jun 2022 10:50:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1656413445; 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=fBnpEBJJsEjj4xp1XzlNmSDPEps8RE1TeLCO9pCV3b8=; b=SkYaCJ3aw8yYG2A60W8Ls7UT3W3arTz5lw4NWYcdT7U7QRxu3PK3+Lfs5BjOOINVWLy0RS UleCkdMpeB82MEE3pyIEMET2YmQPTwa/t+5kGkywSBScOWv0kdHOaL0G09aTsQGfJEWP6p SGiitsAeu9mg3Iho4eDKH9Sd1k771p4= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-384-XDZLxw-xOg20BZLPUX4wtg-1; Tue, 28 Jun 2022 06:50:44 -0400 X-MC-Unique: XDZLxw-xOg20BZLPUX4wtg-1 Received: by mail-wr1-f71.google.com with SMTP id t13-20020adfe10d000000b0021bae3def1eso1699503wrz.3 for ; Tue, 28 Jun 2022 03:50:43 -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=fBnpEBJJsEjj4xp1XzlNmSDPEps8RE1TeLCO9pCV3b8=; b=a1iX+zpp79vC9esDyt0X+5j/8vZwB66xtJW7NeiB48je7XhaLgw+7YEIKq/nfkb4wH UrvXKGRPy6Af/op1tUwAi8tXEN6ktQqeGZWsbT6vYwwXtWC++nMiip1zvnSdfZt7vPkC 2yvIE98xEkMhL7/Q8iHw0JJ6lFptKVrGSQQiWJQWxQnjHFDnP2hXuSvVSG3bn5HhNakX SiiNzZHOETUGH2CUvotjdTJsRF/v/5Kn4otdvyTZxrvJC5UCH+yBt1af+eSbvWTVvAUQ NNnfYcJSvRtqigSzHTJkmaknrSAmvDTBW+lLh86QuZIzXpwUHzhruMOzkQ7mNANXDW0d AFbA== X-Gm-Message-State: AJIora+C4J5XULwh49YREGHi2pOs9V4p4d/xGQcbvY+d+2zZ2zu8138I ieUOlbRCpZfkwmEylQhPxzx70kIKvIAfWBPrCt2cz35iTUKlztMxE9OmIjjbbsKLRcPQ0SIBfjH +RUH9/cWc1Ls= X-Received: by 2002:a05:600c:1547:b0:39c:7fc6:3082 with SMTP id f7-20020a05600c154700b0039c7fc63082mr26228191wmg.189.1656413442955; Tue, 28 Jun 2022 03:50:42 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sOc62+TwZm4Lysu7PiidKj6NprJiStBGJ45lIax1y18ihr6TTIBSDrSl64O72de4xS9gTWfQ== X-Received: by 2002:a05:600c:1547:b0:39c:7fc6:3082 with SMTP id f7-20020a05600c154700b0039c7fc63082mr26228150wmg.189.1656413442750; Tue, 28 Jun 2022 03:50:42 -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 s11-20020a5d4ecb000000b0020fe61acd09sm13521418wrv.12.2022.06.28.03.50.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Jun 2022 03:50:42 -0700 (PDT) Date: Tue, 28 Jun 2022 11:50:39 +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=1656413446; a=rsa-sha256; cv=none; b=7ATaN9mWAfup0idk61TMbfY7iK7c5dGutbjNDJrmTTsdmBynuZsdnrtW/MZByJG/FJQg/J 2yD4kxe7m0NKy7qUg/o0x2M1z/5OihduCdVRnFiu3ariYSTpFokfykKak380/RZx7yj6Pp tj+sY1HqK3ZSvRU24nXd+LNrt8Llzeg= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=SkYaCJ3a; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf28.hostedemail.com: domain of dgilbert@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=dgilbert@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656413446; 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=fBnpEBJJsEjj4xp1XzlNmSDPEps8RE1TeLCO9pCV3b8=; b=pH+4Kpj4G5AvaH3igL2QhUDqdmcPEOAISODS6u1OcGp8X3SzWO8hqavXa+JJsgCqa8Ww9C vE3Gzf/eQSEBhiJ33Dv+SAe0wHzr4JuOnvd/RjRRlWBMx59HVSSW8F92hIYW56YFaoMpjM l5KlW1I+zWmmrYhDaHO8mQJ34/2/IvU= X-Rspam-User: X-Stat-Signature: hawi7abgjermkaga45b71czqi6p9yhbq X-Rspamd-Queue-Id: 03880C0021 Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=SkYaCJ3a; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf28.hostedemail.com: domain of dgilbert@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=dgilbert@redhat.com X-Rspamd-Server: rspam03 X-HE-Tag: 1656413445-148659 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] > > >>> /* > >>> * 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. Dave > Thanks, > Ashish > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK