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 21A9AC32789 for ; Tue, 23 Aug 2022 07:55:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8E1A96B0073; Tue, 23 Aug 2022 03:55:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 86A0E6B0074; Tue, 23 Aug 2022 03:55:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6BCEE8D0001; Tue, 23 Aug 2022 03:55:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 58BC36B0073 for ; Tue, 23 Aug 2022 03:55:10 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 2A867120745 for ; Tue, 23 Aug 2022 07:55:10 +0000 (UTC) X-FDA: 79830096780.05.7EA4EA7 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf27.hostedemail.com (Postfix) with ESMTP id B1C4840030 for ; Tue, 23 Aug 2022 07:55:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1661241309; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=EIwZ7BoTfdMUAhH2fOQC6fOziS/YjfnIvgRTO5vTHto=; b=DyCI55PulUdOrmKB+WgGxp1BNPAeh4juvIPpeXCF87rXoNnLnpMySUbuwRhr2S0tj1ME19 XoH2s5lhUgWm3ytjpdAK5bRJwjnYlJotPWAxLQCFL+JlZGmvCyohxuntZ48XyDsa5fE2YY haGZa/VSZ6I6oWfy2Vr9bHAQfLHmsYI= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-488-uFBHle1LMwmxiXXBqmx6sw-1; Tue, 23 Aug 2022 03:55:07 -0400 X-MC-Unique: uFBHle1LMwmxiXXBqmx6sw-1 Received: by mail-wm1-f69.google.com with SMTP id i132-20020a1c3b8a000000b003a537064611so7567237wma.4 for ; Tue, 23 Aug 2022 00:55:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:subject:organization:from :references:cc:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc; bh=EIwZ7BoTfdMUAhH2fOQC6fOziS/YjfnIvgRTO5vTHto=; b=eU0okn/9iUP7Ic52XGrD+/sGT4Zcz3fkbgD6DGYVtmbEhaQf+/UIQOKC27HZLsZAwz SN5JXiFeUd5gVOhgLmAqg4MQvGUIZaHM9IO7EB/30DBcNEuXoYTdjUxBNYQhXU1YQZ64 xXDgVt6dkFzA9SuR4ZoD1roLXvFb1iYmLd+WYs90V0p6yKX3nzPKok2oDYwj9gYOXjM7 lo6HznhrJicZQnYiTYWSBrhT7K9KTZ6VJYngvpOJ35zHlXBiDyTMMlzCUkVwC7z+3YFw BeyafLTH06YghnbdZEijf0MaQEyBj8CQrqGGKuKmaZNyIQ/Y0jYhJJRDvgsJ+jNScPJY mV9A== X-Gm-Message-State: ACgBeo2mBug/SnT1LuSR1kU+CQnX7ZArh2cztmNEYd73JPvnFuifTIkg T5mSNYiUk9wW1HuXtuaH2mTRY6WPR2GUeS0+i49AbXlreBGdXuVon8gnRhwTk4z/jc7uLW/2E0o 7rpwU+nx5ZQg= X-Received: by 2002:adf:f643:0:b0:225:2cb3:4b05 with SMTP id x3-20020adff643000000b002252cb34b05mr13203059wrp.12.1661241306644; Tue, 23 Aug 2022 00:55:06 -0700 (PDT) X-Google-Smtp-Source: AA6agR7QQcmZIjuOTP3rp/phaSR8BK9i2DfQ3gujUYj0ItGrG9WBrBV+POmli4zo4g6w/n8XuVdszg== X-Received: by 2002:adf:f643:0:b0:225:2cb3:4b05 with SMTP id x3-20020adff643000000b002252cb34b05mr13203037wrp.12.1661241306387; Tue, 23 Aug 2022 00:55:06 -0700 (PDT) Received: from ?IPV6:2003:cb:c70b:1600:c48b:1fab:a330:5182? (p200300cbc70b1600c48b1faba3305182.dip0.t-ipconnect.de. [2003:cb:c70b:1600:c48b:1fab:a330:5182]) by smtp.gmail.com with ESMTPSA id c9-20020a05600c100900b003a2f6367049sm16281074wmc.48.2022.08.23.00.55.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Aug 2022 00:55:05 -0700 (PDT) Message-ID: Date: Tue, 23 Aug 2022 09:55:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 To: Hugh Dickins , Sean Christopherson Cc: "Kirill A . Shutemov" , Chao Peng , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, linux-doc@vger.kernel.org, qemu-devel@nongnu.org, linux-kselftest@vger.kernel.org, Paolo Bonzini , Jonathan Corbet , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H . Peter Anvin" , Jeff Layton , "J . Bruce Fields" , Andrew Morton , Shuah Khan , Mike Rapoport , Steven Price , "Maciej S . Szmigiero" , Vlastimil Babka , Vishal Annapurve , Yu Zhang , luto@kernel.org, jun.nakajima@intel.com, dave.hansen@intel.com, ak@linux.intel.com, aarcange@redhat.com, ddutile@redhat.com, dhildenb@redhat.com, Quentin Perret , Michael Roth , mhocko@suse.com, Muchun Song , "Gupta, Pankaj" References: <20220706082016.2603916-1-chao.p.peng@linux.intel.com> <20220818132421.6xmjqduempmxnnu2@box> <226ab26d-9aa8-dce2-c7f0-9e3f5b65b63@google.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v7 00/14] KVM: mm: fd-based approach for supporting KVM guest private memory In-Reply-To: <226ab26d-9aa8-dce2-c7f0-9e3f5b65b63@google.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1661241309; a=rsa-sha256; cv=none; b=HjPTsKtFmMFbue9Y6Z2TFHVBsRl93s0QM/tFQa10t5hP7MwFSdqoHxCjoUUL2AkMT1eXz3 8WHlWOcCDnXy8rj2PY1ZRuA+XyGv0kol++/KuwYJDSxe0SWAcek/tpsJnPe8x0b/l8Hij9 t5AP4eFX1U9FRXora6Y/Dhv8M3IAImE= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=DyCI55Pu; spf=pass (imf27.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661241309; h=from:from:sender: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=EIwZ7BoTfdMUAhH2fOQC6fOziS/YjfnIvgRTO5vTHto=; b=AL3uw0S7SOH3UqcC5ACn+SnjeK0MhYuPmK72+wrZYEX+Z+1z7hnK0Xt+XFfTqT8U7Fxyea dEWJ0QUKJdDrZOAHjUF+SZKP+3ddsd/HL5MsAfDeDtpdcmt5hYDH93uCEhTBHSLHMr9ag3 RkcE0wlufsceVuuph12D0q3Qp+/UBzY= Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=DyCI55Pu; spf=pass (imf27.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: B1C4840030 X-Stat-Signature: owatk4mrhp8hsgsh9ariugj6qpujttar X-Rspam-User: X-HE-Tag: 1661241309-723897 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 19.08.22 05:38, Hugh Dickins wrote: > On Fri, 19 Aug 2022, Sean Christopherson wrote: >> On Thu, Aug 18, 2022, Kirill A . Shutemov wrote: >>> On Wed, Aug 17, 2022 at 10:40:12PM -0700, Hugh Dickins wrote: >>>> On Wed, 6 Jul 2022, Chao Peng wrote: >>>> But since then, TDX in particular has forced an effort into preventing >>>> (by flags, seals, notifiers) almost everything that makes it shmem/tmpfs. >>>> >>>> Are any of the shmem.c mods useful to existing users of shmem.c? No. >>>> Is MFD_INACCESSIBLE useful or comprehensible to memfd_create() users? No. >> >> But QEMU and other VMMs are users of shmem and memfd. The new features certainly >> aren't useful for _all_ existing users, but I don't think it's fair to say that >> they're not useful for _any_ existing users. > > Okay, I stand corrected: there exist some users of memfd_create() > who will also have use for "INACCESSIBLE" memory. As raised in reply to the relevant patch, I'm not sure if we really have to/want to expose MFD_INACCESSIBLE to user space. I feel like this is a requirement of specific memfd_notifer (memfile_notifier) implementations -- such as TDX that will convert the memory and MCE-kill the machine on ordinary write access. We might be able to set/enforce this when registering a notifier internally instead, and fail notifier registration if a condition isn't met (e.g., existing mmap). So I'd be curious, which other users of shmem/memfd would benefit from (MMU)-"INACCESSIBLE" memory obtained via memfd_create()? -- Thanks, David / dhildenb