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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8F2F4C433E0 for ; Tue, 16 Feb 2021 16:55:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EF393614A7 for ; Tue, 16 Feb 2021 16:55:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EF393614A7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6B4B06B006C; Tue, 16 Feb 2021 11:55:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 662986B006E; Tue, 16 Feb 2021 11:55:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 579556B0070; Tue, 16 Feb 2021 11:55:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0047.hostedemail.com [216.40.44.47]) by kanga.kvack.org (Postfix) with ESMTP id 408FE6B006C for ; Tue, 16 Feb 2021 11:55:11 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 1083787D2 for ; Tue, 16 Feb 2021 16:55:11 +0000 (UTC) X-FDA: 77824731222.25.83CB17E Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by imf02.hostedemail.com (Postfix) with ESMTP id 157F7407F8E8 for ; Tue, 16 Feb 2021 16:55:01 +0000 (UTC) IronPort-SDR: pGbXggHPJTvvB5hBEs94PQamIb8uoBB/vseyKnEdDtBcCZ6aGbHPytWuHhDwlHTp+SOsnNwM9A s93xM8Dy62hw== X-IronPort-AV: E=McAfee;i="6000,8403,9897"; a="247009570" X-IronPort-AV: E=Sophos;i="5.81,184,1610438400"; d="scan'208";a="247009570" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Feb 2021 08:55:06 -0800 IronPort-SDR: yRMEQJNi1UiOvYqim4t7vxNy5IohBtfz6aBiZbUmNIO9VsGgZCzKyFCgGUrAxDiiMK3M7H75dH lr4MepSIWxRg== X-IronPort-AV: E=Sophos;i="5.81,184,1610438400"; d="scan'208";a="426521775" Received: from tassilo.jf.intel.com ([10.54.74.11]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Feb 2021 08:55:05 -0800 Date: Tue, 16 Feb 2021 08:55:03 -0800 From: Andi Kleen To: Peter Zijlstra Cc: Joerg Roedel , David Rientjes , Borislav Petkov , Andy Lutomirski , Sean Christopherson , Andrew Morton , "Kirill A. Shutemov" , Brijesh Singh , Tom Lendacky , Jon Grimm , Thomas Gleixner , Christoph Hellwig , Paolo Bonzini , Ingo Molnar , x86@kernel.org, linux-mm@kvack.org Subject: Re: AMD SEV-SNP/Intel TDX: validation of memory pages Message-ID: <20210216165503.GJ365765@tassilo.jf.intel.com> References: <20210212145318.GK5453@suse.de> <20210212152813.GA28884@suse.de> <20210212161849.GB28884@suse.de> <20210216100045.GE28884@suse.de> <20210216142741.GI365765@tassilo.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 157F7407F8E8 X-Stat-Signature: 98sdgsutrexmmztw9pcak8djpibxnwg8 Received-SPF: none (linux.intel.com>: No applicable sender policy available) receiver=imf02; identity=mailfrom; envelope-from=""; helo=mga07.intel.com; client-ip=134.134.136.100 X-HE-DKIM-Result: none/none X-HE-Tag: 1613494501-660601 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 16, 2021 at 03:46:36PM +0100, Peter Zijlstra wrote: > On Tue, Feb 16, 2021 at 06:27:41AM -0800, Andi Kleen wrote: > > I think the IST solution should at least be explored before > > dismissing it. It might be simpler than anything else (like > > using new APIs) > > Have you seen the trainwreck bonzini proposed? The very simplest thing > is saying no to TDX. #VE cannot nest until TDINFO. I'm thinking to always switch to the normal interrupt stack before TDINFO. With that one it should be equivalent to a non IST #VE, with any nesting you want supported. > So how about fixing TDX instead of forcing us to do horrible fragile > things we all know will end up in tears? I think we should explore both. If the IST variant is too horrible we can see about changing TDX. But at least should approach it with an open mind and see how the code looks like. -Andi