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 15543C433F5 for ; Fri, 29 Apr 2022 22:29:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5F0FE6B0071; Fri, 29 Apr 2022 18:29:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 578726B0072; Fri, 29 Apr 2022 18:29:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3F2146B0073; Fri, 29 Apr 2022 18:29:42 -0400 (EDT) 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 2C65A6B0071 for ; Fri, 29 Apr 2022 18:29:42 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id EA1C320B8E for ; Fri, 29 Apr 2022 22:29:41 +0000 (UTC) X-FDA: 79411359762.11.7CA311F Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by imf11.hostedemail.com (Postfix) with ESMTP id EDA4E4005F for ; Fri, 29 Apr 2022 22:29:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1651271381; x=1682807381; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=aG+Ql7ye3fRbhKulObvFKAKAgxo76KOlhmrCqKgpnHc=; b=GiwLC+xy+OdKdtdgY6qSm6RHH3O4Se4wL/SEjtLIFa+aHrDqNpv9F7u/ oJ+jcnvGdsW6VvT0PltLqIzwVVFEy5TTRDq018mzZBB0DIj3NpqX3vSKe 7v2YN2ZjZqwbJMfSCdlwU+HCRedKA0Rsb0V95f69fFDz2ue5oDmS3hmMG 028t6dJw71QBKARTZtENB3lcIvqMR9yl6fGMLx1ZL4qH8m0H98okXGD2w DjfRA4w/4YrksGuPOuRiDLSaZMmsfxQHvjSMMxxPwt2MenVbLUsvzJyhE KLaRXvlam2TU9McDBae0AEMR1uhJeHaiKd4uj8GO/UUWMcnlbIU6K0oK9 g==; X-IronPort-AV: E=McAfee;i="6400,9594,10332"; a="266947413" X-IronPort-AV: E=Sophos;i="5.91,186,1647327600"; d="scan'208";a="266947413" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Apr 2022 15:29:39 -0700 X-IronPort-AV: E=Sophos;i="5.91,186,1647327600"; d="scan'208";a="582431720" Received: from sbecht-mobl.amr.corp.intel.com (HELO [10.212.12.102]) ([10.212.12.102]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Apr 2022 15:29:38 -0700 Message-ID: Date: Fri, 29 Apr 2022 15:29:54 -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> <2bf733e7-49f3-12de-bf9d-73b23286754d@intel.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=GiwLC+xy; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf11.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 192.55.52.115) smtp.mailfrom=dave.hansen@intel.com X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: EDA4E4005F X-Rspam-User: X-Stat-Signature: 1gpw6ggw6mrqro7sz54zkgjhetjb76c3 X-HE-Tag: 1651271377-645203 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 14:32, Jue Wang wrote: > On Fri, Apr 29, 2022 at 2:10 PM Dave Hansen wrote: >> I wouldn't go that far. The unaccepted TDX guest memory thing is just >> the obvious one at the moment. There are a whole ton of other guest >> ballooning mechanisms out there and I'm not sure that all of them are >> happy to let you touch ballooned-away memory. > > This type of scanning is intended to be run on the host side. That > should avoid concerns around the guest ballooning or any effects to > the host side reclaim that's based on the guest's working set. Hint: Talk is cheap. Just saying how it is intended doesn't avoid concerns. Saying how it is intended, then backing up that intent with code and deliberate design that matches that intent would be nice. > I don't know why a guest wants to spend its CPU cycles and pollute its > caches etc to run this scanner, anyway. This should be a benefit > provide by the cloud platform transparently to the guest. "This should only be used by and made available by cloud providers!" ... says the cloud provider. ;) Also, who said anything about polluting the caches? Aren't there lots of reasons for a memory poison detector to intentionally not use the caches? First, you really *do* always want to go to memory. That's kinda the point. If this code hits the caches, it's kinda pointless. Second, you want this code to have a low profile. Not polluting the caches seems like a good way to have a low profile. >> But, the bigger issue is that those cases had not even been considered. >> It means that there is a *LOT* of homework needed to seek out and cover >> all the other weird cases. >> >> I also think the proposed ABI -- exposing physical addresses to >> userspace as a part of the design -- is an utter non-starter. > > This can be addressed with a different design.