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 71B44C433EF for ; Mon, 21 Feb 2022 18:06:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B75228D0002; Mon, 21 Feb 2022 13:06:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B23C38D0001; Mon, 21 Feb 2022 13:06:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9C4A68D0002; Mon, 21 Feb 2022 13:06:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0152.hostedemail.com [216.40.44.152]) by kanga.kvack.org (Postfix) with ESMTP id 8D68C8D0001 for ; Mon, 21 Feb 2022 13:06:38 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 4BAFB181C65DB for ; Mon, 21 Feb 2022 18:06:38 +0000 (UTC) X-FDA: 79167567276.16.A21C80E Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by imf20.hostedemail.com (Postfix) with ESMTP id 73FBF1C000E for ; Mon, 21 Feb 2022 18:06:32 +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 6FFC01EC0531; Mon, 21 Feb 2022 19:06:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1645466786; 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=MWw/afFsOSxJd3d13rKUZHwqChPZ/A+IszeqZt9+ZxE=; b=Zk1raW6/fw1YdurcyqLzeJQ7rNXBWPIoUVEVWPfTnDlK2Nwh9wuLji4gF4dQ7Po3Fh4lTz UOJLIha0PKE4e4iR6cRUEl0q+kqm+K9Gv+Fppz5xJ2HVXKKgBiY4u3QfZGeYH6b7LHNOMA suVVW2daCREEY+ZHQxlrBtkZRhicKz8= Date: Mon, 21 Feb 2022 19:06:29 +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: <20220216160457.1748381-1-brijesh.singh@amd.com> <20220221174121.ceeplpoaz63q72kv@box> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20220221174121.ceeplpoaz63q72kv@box> X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 73FBF1C000E X-Rspam-User: Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=alien8.de header.s=dkim header.b="Zk1raW6/"; spf=temperror (imf20.hostedemail.com: error in processing during lookup of bp@alien8.de: DNS error) smtp.mailfrom=bp@alien8.de; dmarc=pass (policy=none) header.from=alien8.de X-Stat-Signature: d6r1xohqfhn1piqh6fumocj6pib49cn8 X-HE-Tag: 1645466792-357592 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 Mon, Feb 21, 2022 at 08:41:21PM +0300, Kirill A. Shutemov wrote: > On Wed, Feb 16, 2022 at 10:04:57AM -0600, Brijesh Singh wrote: > > @@ -287,6 +301,7 @@ struct x86_platform_ops { > > struct x86_legacy_features legacy; > > void (*set_legacy_features)(void); > > struct x86_hyper_runtime hyper; > > + struct x86_guest guest; > > }; > > I used 'cc' instead of 'guest'. 'guest' looks too generic. But guest is what is needed there. Not all cases where the kernel runs as a guest are confidential ones. Later, that hyperv thing should be merged into the guest one too as the hyperv should be a guest too. AFAICT. > Also, I'm not sure why not to use pointer to ops struct instead of stroing > them directly in x86_platform. Yes, it is consistent with 'hyper', but I > don't see it as a strong argument. There should be no big difference but we're doing it with direct struct member assignment so far so we should keep doing the same and not start doing pointers now, all of a sudden. > This doesn't cover difference in flushing requirements. Can we get it too? What are the requirements you have for TDX on this path? This is the main reason why I'm asking you to review this - I'd like to have one version which works for both and then I'll queue it on a common branch. This is also why I'd like for you and SEV folks to agree on all the common code so that I can apply it and you can both base your patchsets ontop. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette