Received: by 2002:ac0:da4c:0:0:0:0:0 with SMTP id a12csp544818imi; Fri, 22 Jul 2022 04:42:16 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vxQAVJgdYnu8eeG2pJ+sd3EdqAATO2QrR1aa3afZ1fVciOVOec/gtKg0mYf5x5GPDgfhUY X-Received: by 2002:a17:902:d0d2:b0:16d:2b24:abf9 with SMTP id n18-20020a170902d0d200b0016d2b24abf9mr3057547pln.107.1658490135756; Fri, 22 Jul 2022 04:42:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658490135; cv=none; d=google.com; s=arc-20160816; b=YhES+s9EooOGcixD/oWGY2VPHk/ftiWGc+9Xg0GOnakRgUlTy9NmRJjzR8Ahj1zqcB YzJ/umaZfa0ORjSbHGLPuzOmOrkrbAbhegDMpiTuP31kF5ISZowp1yu7exkiNU9ZVn6n DUMr2S0dftGRB2nrHXMEtq5Y9PnYQoPLZ0HsT49fgfKjdWlFEc02uubgbNweSHJp5Sqg KPJnY8ZDxwYuQdSp6Z9xttb/ixyXjQTRDUqdgpgCzA76Pmfk56ISqMnY/VultB9HkHno nCOKOSrCcMIycZ0hZzJlG71YJggJ6tPFus0HjieLBbiaRJoLWahGaRQdzJNViNUbyHLH LjdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=iA4hF9kkPlWcq5B8sNQx2XUmWFJBZdfDGxazbgtSxSs=; b=yBQXwbjq4ACKweEzJKYZpwwMp6Y/EGkNWiKdoqm52AWyUNNU/4IFW76p1zZg9svADg 8mjB/h/U3JXohGbbmVNebShATox/T+Cq44YReC0aRu7cuY2yPnUK+rAr5wbSwEcDlsbX noxbmwVQAA6Xv8sEpRes1Gdr1/wGINoNfj149HIPUPg0z2rPwMXYWWt6QbA2AHWjs8N7 qlO7VfS7ysOxEm2DlvI6LAj9iExL+oCej9mCn7NnEjB/tVZ3cyyzdFoHIUcOInCaXKjT neHtCPQ8BBPvVtqA25ewbWjTpw/1azd+2WcBad7wRtAWOlmC11B9qOWrNY56m1C6TlRU JZtg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=Gfc3qmAZ; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c141-20020a624e93000000b0051078cc4fd5si5563454pfb.354.2022.07.22.04.41.51; Fri, 22 Jul 2022 04:42:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=Gfc3qmAZ; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230199AbiGVLfr (ORCPT + 99 others); Fri, 22 Jul 2022 07:35:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36920 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230134AbiGVLfq (ORCPT ); Fri, 22 Jul 2022 07:35:46 -0400 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E8CA7AF868; Fri, 22 Jul 2022 04:35:43 -0700 (PDT) Received: from zn.tnic (p200300ea97297665329c23fffea6a903.dip0.t-ipconnect.de [IPv6:2003:ea:9729:7665:329c:23ff:fea6:a903]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id E5EF91EC04E4; Fri, 22 Jul 2022 13:35:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1658489738; 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: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=iA4hF9kkPlWcq5B8sNQx2XUmWFJBZdfDGxazbgtSxSs=; b=Gfc3qmAZEapfyhMcE8YqM23jtcCxb3f562sZrP/kg89pc7XVy8A0voe5xVEINVUjkO8ZaW m4rhZaFIc53CaGiUZGsfxI0n7W63uo5tIJG6Ml78lhKPPuk10M76vzqvHbod4qaMEiPiSw UGND80nYqOiUPTj4DE81rtyPQKffhqE= Date: Fri, 22 Jul 2022 13:35:32 +0200 From: Borislav Petkov To: "Kalra, Ashish" Cc: Sean Christopherson , Dave Hansen , "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" , "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" , "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" Subject: Re: [PATCH Part2 v6 05/49] x86/sev: Add RMP entry lookup helpers Message-ID: References: <25be3068-be13-a451-86d4-ff4cc12ddb23@intel.com> <681e4e45-eff1-600c-9b81-1fa9bdf24232@intel.com> <99d72d58-a9bb-d75c-93af-79d497dfe176@intel.com> <5db37cc2-4fb1-7a73-c39a-3531260414d0@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Thu, Jun 23, 2022 at 10:43:40PM +0000, Kalra, Ashish wrote: > Yes, that's a nice way to hide it from the rest of the kernel which > does not require access to this structure anyway, in essence, it > becomes a private structure. So this whole discussion whether there should be a model check or not in case a new RMP format gets added in the future is moot - when a new model format comes along, *then* the distinction should be done and added in code - not earlier. This is nothing else but normal CPU enablement work - it should be done when it is really needed. Because the opposite can happen: you can add a model check which excludes future model X, future model X comes along but does *not* change the RMP format and then you're going to have to relax that model check again to fix SNP on the new model X. So pls add the model checks only when really needed. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette