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 07B39C433EF for ; Mon, 2 May 2022 15:30:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6A1306B0072; Mon, 2 May 2022 11:30:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6510D6B0073; Mon, 2 May 2022 11:30:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 519216B0074; Mon, 2 May 2022 11:30:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id 3E3936B0072 for ; Mon, 2 May 2022 11:30:34 -0400 (EDT) Received: from smtpin31.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 111FE3D8 for ; Mon, 2 May 2022 15:30:34 +0000 (UTC) X-FDA: 79421189988.31.75AD6BC Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by imf17.hostedemail.com (Postfix) with ESMTP id B423F4006B for ; Mon, 2 May 2022 15:30:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1651505432; x=1683041432; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=brUTtV6T+XmPkLqvYVny2AQobPKavAGZD6+tR/oLkJ8=; b=mr7qT7+drGLiFXRY1LG117RIbIpDzTuv/1KE68qy0VFV2ll1i1X7bRod T2fnSUKOVuXw4Ek0Po1rWpsUgwlbtxoCOt2TWrz/U2cvpQv5S+gjesVJ+ 3dJwvdEHLKr6Xb8ZwjGltC7YmAsSSC0+nvR3gcOucNgtMO7esHCQ1ihx5 Ah8fr+IiAnS5xLhXFufPC87AM9Bu07UQVfat3bXUHd6QE5NsUQRQ28U5w KdZAJ6/4ku8hlCz4i3BLNm2gh6+5MFYN4nhgCp0prtqRozgM992eA8+oV bd1W11Sk4Kb1ho+6a8OVKwWTR5NkdIrssZbnzUkopEP8+eAr/5H1DS3Bb Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10335"; a="267393527" X-IronPort-AV: E=Sophos;i="5.91,192,1647327600"; d="scan'208";a="267393527" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 May 2022 08:30:31 -0700 X-IronPort-AV: E=Sophos;i="5.91,192,1647327600"; d="scan'208";a="663567719" Received: from gsteinke-mobl.amr.corp.intel.com (HELO [10.209.165.8]) ([10.209.165.8]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 May 2022 08:30:30 -0700 Message-ID: <0d9086d3-520e-795e-4d26-f87d0e73d8c6@intel.com> Date: Mon, 2 May 2022 08:30:49 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [RFC] Expose a memory poison detector ioctl to user space. Content-Language: en-US To: Jue Wang Cc: Erdem Aktas , almasrymina@google.com, dave.hansen@linux.intel.com, gthelen@google.com, jiaqiyan@google.com, linux-mm@kvack.org, naoya.horiguchi@nec.com, seanjc@google.com, tony.luck@intel.com References: <20220428161551.722296-1-erdemaktas@google.com> <6f99684f-172c-ccf2-0be3-9aca85451079@intel.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Stat-Signature: 6nd1p48wi6gcfa8iyswtgyd6di9t7po8 X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: B423F4006B Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=mr7qT7+d; spf=none (imf17.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 192.55.52.115) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspam-User: X-HE-Tag: 1651505420-862964 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 4/29/22 12:46, Jue Wang wrote: > 1. Reading via direct mapping from guest private memory should not > generate #MC and it should result in expected memory error poisoning > behavior (to be confirmed). > > 2. Reading via direct mapping from SEV-SNP guest private memory does > not generate #MC or #PF. There are two different things you need to look at here: 1. What is the *implementation* today? 2. What is the architecture to which the hardware vendors will commit? Let's say that, today, a TDX host accessing guest-private memory doesn't trigger the error handling that you want. Then, this scheme simply won't work on today's TDX hardware. You can only hope for better hardware in the future. Now, consider if you get lucky: Today, a TDX host accessing guest-private memory *DOES* trigger the error handling that you want. That's great, but it doesn't mean that the behavior will stick. Intel might change it _tomorrow_ without telling anyone because folks believe it to be software-invisible. Either way, you need to extract promises from hardware vendors if you want to depend on this scheme.