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 3561DC433EF for ; Wed, 1 Jun 2022 10:21:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BE8996B00B0; Wed, 1 Jun 2022 06:21:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B70F66B00B1; Wed, 1 Jun 2022 06:21:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A34466B00B2; Wed, 1 Jun 2022 06:21:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 9290C6B00B0 for ; Wed, 1 Jun 2022 06:21:42 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 6617234F9A for ; Wed, 1 Jun 2022 10:21:42 +0000 (UTC) X-FDA: 79529275644.01.5AF679A Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by imf05.hostedemail.com (Postfix) with ESMTP id D757F10005B for ; Wed, 1 Jun 2022 10:21:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1654078901; x=1685614901; h=date:from:to:cc:subject:message-id:reply-to:references: mime-version:in-reply-to; bh=MPDfwkz64kDPQGnp5LEYEWHtzrsbbGi1CtkgkpVVQ9g=; b=M3JUF9CxeVmdrLvYe+vI5f0soCFf8jLeTx0QSx3wBRAUE85EyOgYmmmY y5s6zeUDOBBGL/a6+ymUp8MiP79FEoXOQgfuH11tymp+PWZx5vfs12noa hPToH9I7XlG5sHLVr4ZSH+oKgObr/lMyVHwEUO3myVetnpo14qOvdEDFP 7TJn8HUBOY071ePoOKUFkIKNwptRTkZmEQOP+6xU5ZqhynWq2ikrCd1uP wDLKIhrXjhdOWQaN1aLgpdHdDOBRqIxPh6bO3nsLKL4PUPvmKUpqVrge6 rEqbDxTg2BqN2KAYjUJG0OFwVPGNmi3Nf769N48iKy1eIBXj2scJa4d6i g==; X-IronPort-AV: E=McAfee;i="6400,9594,10364"; a="300892196" X-IronPort-AV: E=Sophos;i="5.91,266,1647327600"; d="scan'208";a="300892196" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jun 2022 03:21:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.91,266,1647327600"; d="scan'208";a="755837829" Received: from chaop.bj.intel.com (HELO localhost) ([10.240.192.101]) by orsmga005.jf.intel.com with ESMTP; 01 Jun 2022 03:21:12 -0700 Date: Wed, 1 Jun 2022 18:17:47 +0800 From: Chao Peng To: Vishal Annapurve Cc: 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 , Sean Christopherson , 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 , Mike Rapoport , Steven Price , "Maciej S . Szmigiero" , Vlastimil Babka , Yu Zhang , "Kirill A . Shutemov" , Andy Lutomirski , Jun Nakajima , dave.hansen@intel.com, ak@linux.intel.com, david@redhat.com, aarcange@redhat.com, ddutile@redhat.com, dhildenb@redhat.com, Quentin Perret , Michael Roth , mhocko@suse.com Subject: Re: [PATCH v6 3/8] mm/memfd: Introduce MFD_INACCESSIBLE flag Message-ID: <20220601101747.GA1255243@chaop.bj.intel.com> Reply-To: Chao Peng References: <20220519153713.819591-1-chao.p.peng@linux.intel.com> <20220519153713.819591-4-chao.p.peng@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: D757F10005B X-Stat-Signature: tiswiac4sk6aoet4gfishr6r1xdf5ih3 X-Rspam-User: Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=M3JUF9Cx; spf=none (imf05.hostedemail.com: domain of chao.p.peng@linux.intel.com has no SPF policy when checking 192.55.52.88) smtp.mailfrom=chao.p.peng@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspamd-Server: rspam08 X-HE-Tag: 1654078866-520296 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 Tue, May 31, 2022 at 12:15:00PM -0700, Vishal Annapurve wrote: > On Thu, May 19, 2022 at 8:41 AM Chao Peng wrote: > > > > Introduce a new memfd_create() flag indicating the content of the > > created memfd is inaccessible from userspace through ordinary MMU > > access (e.g., read/write/mmap). However, the file content can be > > accessed via a different mechanism (e.g. KVM MMU) indirectly. > > > > SEV, TDX, pkvm and software-only VMs seem to have usecases to set up > initial guest boot memory with the needed blobs. > TDX already supports a KVM IOCTL to transfer contents to private > memory using the TDX module but rest of the implementations will need > to invent > a way to do this. There are some discussions in https://lkml.org/lkml/2022/5/9/1292 already. I somehow agree with Sean. TDX is using an dedicated ioctl to copy guest boot memory to private fd so the rest can do that similarly. The concern is the performance (extra memcpy) but it's trivial since the initial guest payload is usually optimized in size. > > Is there a plan to support a common implementation for either allowing > initial write access from userspace to private fd or adding a KVM > IOCTL to transfer contents to such a file, > as part of this series through future revisions? Indeed, adding pre-boot private memory populating on current design isn't impossible, but there are still some opens, e.g. how to expose private fd to userspace for access, pKVM and CC usages may have different requirements. Before that's well-studied I would tend to not add that and instead use an ioctl to copy. Whether we need a generic ioctl or feature-specific ioctl, I don't have strong opinion here. Current TDX uses a feature-specific ioctl so it's not covered in this series. Chao > > Regards, > Vishal