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 073BFC433EF for ; Tue, 15 Feb 2022 14:41:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8307F6B0078; Tue, 15 Feb 2022 09:41:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7DFB26B007B; Tue, 15 Feb 2022 09:41:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 659EF6B007D; Tue, 15 Feb 2022 09:41:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id 54A016B0078 for ; Tue, 15 Feb 2022 09:41:16 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 227F360AF1 for ; Tue, 15 Feb 2022 14:41:16 +0000 (UTC) X-FDA: 79145276952.05.034F601 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by imf08.hostedemail.com (Postfix) with ESMTP id 621C7160009 for ; Tue, 15 Feb 2022 14:41:15 +0000 (UTC) Received: from zn.tnic (dslb-088-067-221-104.088.067.pools.vodafone-ip.de [88.67.221.104]) (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 165F71EC0518; Tue, 15 Feb 2022 15:41:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1644936069; 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=SHIy0JOracxSZUX44JRM2zOEiCF50L0BbqI7lPnq/lg=; b=D+daksFOoyoSLR0f2z09XUHDSNPn8LQA3tsgm5xo8bZfaH0AXftJ1PbhtIB8uFRTlDgeN3 IhZrPaWjYY55BMCz3b9qcWUAeCmuhJ5xY1m5uq066+kwXprdzCQI0pJsdrNDTp0Rcll5OI qAHnm6YoNPR0BXK0WMHqnRqjx57sXwA= Date: Tue, 15 Feb 2022 15:41:10 +0100 From: Borislav Petkov To: "Kirill A. Shutemov" Cc: Brijesh Singh , x86@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-efi@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, Thomas Gleixner , Ingo Molnar , Joerg Roedel , Tom Lendacky , "H. Peter Anvin" , Ard Biesheuvel , Paolo Bonzini , Sean Christopherson , Vitaly Kuznetsov , Jim Mattson , Andy Lutomirski , Dave Hansen , Sergio Lopez , Peter Gonda , Peter Zijlstra , Srinivas Pandruvada , David Rientjes , Dov Murik , Tobin Feldman-Fitzthum , Michael Roth , Vlastimil Babka , Andi Kleen , "Dr . David Alan Gilbert" , brijesh.ksingh@gmail.com, tony.luck@intel.com, marcorr@google.com, sathyanarayanan.kuppuswamy@linux.intel.com Subject: Re: [PATCH v10 21/45] x86/mm: Add support to validate memory when changing C-bit Message-ID: References: <20220209181039.1262882-1-brijesh.singh@amd.com> <20220209181039.1262882-22-brijesh.singh@amd.com> <0242e383-5406-7504-ff3d-cf2e8dfaf8a3@amd.com> <20220215124331.i4vgww733fv5owrx@box.shutemov.name> <20220215131522.l3xytgmy4ufrgnlb@box.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20220215131522.l3xytgmy4ufrgnlb@box.shutemov.name> X-Rspamd-Queue-Id: 621C7160009 X-Rspam-User: Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=alien8.de header.s=dkim header.b=D+daksFO; spf=pass (imf08.hostedemail.com: domain of bp@alien8.de designates 5.9.137.197 as permitted sender) smtp.mailfrom=bp@alien8.de; dmarc=pass (policy=none) header.from=alien8.de X-Stat-Signature: zjhco3umkttyqscgrg553mtho5w6tmqu X-Rspamd-Server: rspam03 X-HE-Tag: 1644936075-417375 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 Tue, Feb 15, 2022 at 04:15:22PM +0300, Kirill A. Shutemov wrote: > I have no problem with cc_vendor idea. It looks good. Good. > Regarding the masks, if we want to have common ground here we can add two > mask: cc_enc_mask and cc_dec_mask. And then If we do two masks, then we can just as well leave the SME and TDX masks. The point of the whole exercise is to have simpler code and less ifdeffery. If you "hide" how the mask works on each vendor in the respective functions - and yes, cc_pgprot_dec/enc() reads better - then it doesn't matter how the mask is defined. Because you don't need two masks to encrypt/decrypt pages - you need a single mask but apply it differently. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette