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 26CBFC4332F for ; Wed, 19 Oct 2022 13:35:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A26216B0071; Wed, 19 Oct 2022 09:35:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9D62D6B0073; Wed, 19 Oct 2022 09:35:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8775B6B0074; Wed, 19 Oct 2022 09:35:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 75E766B0071 for ; Wed, 19 Oct 2022 09:35:28 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 47DC4120B10 for ; Wed, 19 Oct 2022 13:35:28 +0000 (UTC) X-FDA: 80037795936.08.3B4EA78 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by imf07.hostedemail.com (Postfix) with ESMTP id 5F6564003A for ; Wed, 19 Oct 2022 13:35:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1666186527; x=1697722527; h=date:from:to:cc:subject:message-id:reply-to:references: mime-version:in-reply-to; bh=4xcGc4T12PBypY/VcZfHNkEly5yZ/s7CT5KUy36zg78=; b=Fz8zNTFJ0pG9yjYFH3iZ6akZgStRDYjS6vhlzXt4gx+PWfPm2ixKqkSk B2DJLAV3dPPIfkZjLm9wIo7ToI4ccihCqlrWDbG3kR+oHPA/uiy2wFVyo y1wk5S/Ze7KzzJIW6Orwu4Wg7U4ue1BuFC4xXi/wxnOw5TVKso3E8Kiud QqgQ1sYJRwA+q+pHavRN6peas7NkYumWLJ/krheTe/8AZmA0IeqI25/y8 nb3FzAbFszGjCEW9FxuUfSKSvAFwQPGygao10Ya8cLW+cuspEnd4e8NTI 4PYQEbcQCxETRJq7kk8rfgE16QoYhYT5kkuvsUKYOQGKpT5WWNOwZ9tfw A==; X-IronPort-AV: E=McAfee;i="6500,9779,10505"; a="308096806" X-IronPort-AV: E=Sophos;i="5.95,196,1661842800"; d="scan'208";a="308096806" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Oct 2022 06:35:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10505"; a="624137726" X-IronPort-AV: E=Sophos;i="5.95,196,1661842800"; d="scan'208";a="624137726" Received: from chaop.bj.intel.com (HELO localhost) ([10.240.193.75]) by orsmga007.jf.intel.com with ESMTP; 19 Oct 2022 06:35:14 -0700 Date: Wed, 19 Oct 2022 21:30:43 +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: <20221019133043.GB3496045@chaop.bj.intel.com> Reply-To: Chao Peng References: <20220926142330.GC2658254@chaop.bj.intel.com> <20221013133457.GA3263142@chaop.bj.intel.com> <20221017145856.GB3417432@chaop.bj.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666186527; a=rsa-sha256; cv=none; b=4V8ilJDdbNQpWB9HjmCIW2yhN0B6CzN1UPQInfmkhYyxHMR5opPyhmcQPNcbHPRjgt9yB5 e6R1QW5i26K2RckKG08zDEiX0QoALVSsrwQ1ymeIF6s8k4tCTyS9QOYzbEu6KSjBVQEcw8 AUC+lkCDtfWk4aYMR6T/6J1UHIjjkx8= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=Fz8zNTFJ; spf=none (imf07.hostedemail.com: domain of chao.p.peng@linux.intel.com has no SPF policy when checking 134.134.136.65) smtp.mailfrom=chao.p.peng@linux.intel.com; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666186527; 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=ZYlo4aSdnNnEAh/dxPH/ZApKTFUaYIPsaLIT4suSCzI=; b=2h2FvStyursWX8lzE2qMNvRydWuQ++HKVJFphOi4mEtLzMfFRHvHHAX9RhmUaFQnkOph9S Z9JxVPQHvGez/NFWTHm9N4UKWWnG74WeXJ5wAkCbhnBLlbiGobkizi4VPE974LWRNY5edO y3DLzY+xIStYKfvRJ7gH9l/x2x0V6Tw= X-Rspam-User: Authentication-Results: imf07.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=Fz8zNTFJ; spf=none (imf07.hostedemail.com: domain of chao.p.peng@linux.intel.com has no SPF policy when checking 134.134.136.65) smtp.mailfrom=chao.p.peng@linux.intel.com; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none) X-Stat-Signature: jm5xnzccn1ua9rwhstye57uydztowxne X-Rspamd-Queue-Id: 5F6564003A X-Rspamd-Server: rspam10 X-HE-Tag: 1666186527-512304 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 08:05:10PM +0100, Fuad Tabba wrote: > Hi, > > > > > 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. > > All these sound good, since they all capture the potential use cases. > Restricted might be the most logical choice if that's going to also > become the name for the mem_fd. Thanks, I will use 'restricted' for them. e.g.: - memfd_restricted() syscall - restricted_fd - restricted_offset The memslot flags will still be KVM_MEM_PRIVATE, since I think pKVM will create its own one? Chao > > Thanks, > /fuad > > > Thanks, > > Chao > > > > > > What do you think? > > > > > > Cheers, > > > /fuad > > > > > > > > > > > Thanks, > > > > Chao > > > > > > > > > > Cheers, > > > > > /fuad