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 A7128C4332F for ; Mon, 17 Oct 2022 15:03:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 111876B0074; Mon, 17 Oct 2022 11:03:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0C1266B0075; Mon, 17 Oct 2022 11:03:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ECAC06B0078; Mon, 17 Oct 2022 11:03:42 -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 DB8AF6B0074 for ; Mon, 17 Oct 2022 11:03:42 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id ABDC11C672A for ; Mon, 17 Oct 2022 15:03:42 +0000 (UTC) X-FDA: 80030760684.25.E5307E3 Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by imf23.hostedemail.com (Postfix) with ESMTP id 53405140039 for ; Mon, 17 Oct 2022 15:03:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1666019021; x=1697555021; h=date:from:to:cc:subject:message-id:reply-to:references: mime-version:in-reply-to; bh=PvgBjoYyaoMX/iKVZUi6GVXenC/pYD5E0G2UFDGF3Zw=; b=k6W5aNG7MGj3+voIk1a2K1qhDAdu8fjmeRlyWc0VJ1XF6QqY/fsnYogx 6jPvUyK/0j8jpMN9bi1ZdVys07Pbn0YlfE2gvLANqhR/6TMLKXGQyztMB ZTNtpseCEoZR2J86nduTD3gw/UMZW8sdXDGvas0iwpcbOwEgWB/viLwg/ JntG+vf5Tx3TOGWJpdB18XTgkhRkkCcbM0NOdRotiStDwYNZ0tmnwAZQq euJ1eRAxZInB5+czAPFBOKAR6O3ewt3D4puABz39obf73JEOXjrsLrjs3 DfoYoWbsW6Hv/wLUzp+WaNKyj4U4Q0XR7u8a6A3A0WsQYLmqLm/mtnYGV Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10503"; a="367841835" X-IronPort-AV: E=Sophos;i="5.95,191,1661842800"; d="scan'208";a="367841835" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2022 08:03:37 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10503"; a="691387974" X-IronPort-AV: E=Sophos;i="5.95,191,1661842800"; d="scan'208";a="691387974" Received: from chaop.bj.intel.com (HELO localhost) ([10.240.193.75]) by fmsmga008.fm.intel.com with ESMTP; 17 Oct 2022 08:03:27 -0700 Date: Mon, 17 Oct 2022 22:58:56 +0800 From: Chao Peng To: Fuad Tabba Cc: Sean Christopherson , David Hildenbrand , 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, Paolo Bonzini , Jonathan Corbet , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H . Peter Anvin" , Hugh Dickins , Jeff Layton , "J . Bruce Fields" , Andrew Morton , Shuah Khan , Mike Rapoport , Steven Price , "Maciej S . Szmigiero" , Vlastimil Babka , Vishal Annapurve , Yu Zhang , "Kirill A . Shutemov" , 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 , wei.w.wang@intel.com, Will Deacon , Marc Zyngier Subject: Re: [PATCH v8 1/8] mm/memfd: Introduce userspace inaccessible memfd Message-ID: <20221017145856.GB3417432@chaop.bj.intel.com> Reply-To: Chao Peng References: <20220915142913.2213336-2-chao.p.peng@linux.intel.com> <20220926142330.GC2658254@chaop.bj.intel.com> <20221013133457.GA3263142@chaop.bj.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666019022; h=from:from:sender:reply-to: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:dkim-signature; bh=SmPEl3YZH+yvnx1ZNW7yWTDOzUnIm+7YZ7MaFsnPbIo=; b=TH+wzb51bf3v7dJMEVlRYyB4gQ40jpN2PRVxdNF0vEP7i51NP1+C6KXV5rG+C/XAGwW+Yd bwRoWWMqV3GCEBf1UIvlUsUxmAv86DEfzs4MFj9OzDWgUsiRhnElwpYH31plaD5vvc5p6U yZfLOxaqD4b09zeaQ+25i83VvQNXGDk= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=k6W5aNG7; spf=none (imf23.hostedemail.com: domain of chao.p.peng@linux.intel.com has no SPF policy when checking 134.134.136.31) smtp.mailfrom=chao.p.peng@linux.intel.com; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666019022; a=rsa-sha256; cv=none; b=C/RzDOwCS++Dg15ZUiqBMxU2mB08LLHIeUGxEvLfe4x8cIBGEvq03ovkjzSA+TJKSlsEPq vmwWUtqOWFd11kT/tT2cxLZ6M2HA6PLcHQsevSn4jSMzMELlStdoEIYvPcwIZ6tGMuD2xV UjjhRuZZM3BfzTeq/632XRvcNKpL7OY= X-Rspamd-Server: rspam12 X-Rspam-User: Authentication-Results: imf23.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=k6W5aNG7; spf=none (imf23.hostedemail.com: domain of chao.p.peng@linux.intel.com has no SPF policy when checking 134.134.136.31) smtp.mailfrom=chao.p.peng@linux.intel.com; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none) X-Stat-Signature: nyriheuh174thdawixhgiejm5enbjrtr X-Rspamd-Queue-Id: 53405140039 X-HE-Tag: 1666019021-977197 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, Oct 17, 2022 at 11:31:19AM +0100, Fuad Tabba wrote: > Hi, > > > > > > > Actually, for pKVM, there is no need for the guest memory to be > > > GUP'able at all if we use the new inaccessible_get_pfn(). > > > > If pKVM can use inaccessible_get_pfn() to get pfn and can avoid GUP (I > > think that is the major concern?), do you see any other gap from > > existing API? > > Actually for this part no, there aren't any gaps and > inaccessible_get_pfn() is sufficient. Thanks for the confirmation. > > > > This of > > > course goes back to what I'd mentioned before in v7; it seems that > > > representing the memslot memory as a file descriptor should be > > > orthogonal to whether the memory is shared or private, rather than a > > > private_fd for private memory and the userspace_addr for shared > > > memory. The host can then map or unmap the shared/private memory using > > > the fd, which allows it more freedom in even choosing to unmap shared > > > memory when not needed, for example. > > > > Using both private_fd and userspace_addr is only needed in TDX and other > > confidential computing scenarios, pKVM may only use private_fd if the fd > > can also be mmaped as a whole to userspace as Sean suggested. > > That does work in practice, for now at least, and is what I do in my > current port. However, the naming and how the API is defined as > implied by the name and the documentation. By calling the field > private_fd, it does imply that it should not be mapped, which is also > what api.rst says in PATCH v8 5/8. My worry is that in that case pKVM > would be mis/ab-using this interface, and that future changes could > cause unforeseen issues for pKVM. That is fairly enough. We can change the naming and the documents. > > Maybe renaming this to something like "guest_fp", and specifying in > the documentation that it can be restricted, e.g., instead of "the > content of the private memory is invisible to userspace" something > along the lines of "the content of the guest memory may be restricted > to userspace". Some other candidates in my mind: - restricted_fd: to pair with the mm side restricted_memfd - protected_fd: as Sean suggested before - fd: how it's explained relies on the memslot.flag. Thanks, Chao > > What do you think? > > Cheers, > /fuad > > > > > Thanks, > > Chao > > > > > > Cheers, > > > /fuad