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 98A4BCCA473 for ; Wed, 15 Jun 2022 08:56:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3070E6B0071; Wed, 15 Jun 2022 04:56:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2B6A56B0072; Wed, 15 Jun 2022 04:56:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 17DD86B0073; Wed, 15 Jun 2022 04:56:54 -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 09CFA6B0071 for ; Wed, 15 Jun 2022 04:56:54 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id C8759603E4 for ; Wed, 15 Jun 2022 08:56:53 +0000 (UTC) X-FDA: 79579865106.10.BE082FB Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by imf09.hostedemail.com (Postfix) with ESMTP id DF043140084 for ; Wed, 15 Jun 2022 08:56:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1655283412; x=1686819412; h=date:from:to:cc:subject:message-id:reply-to:references: mime-version:in-reply-to; bh=YUylNu9M17rCKFlfGnkhsZRqok22qMLdjCA7fnGzy7c=; b=hYAnPULmm56KC16KzSN/Q0JrMpQfzMzjBjuUWgJaHs65ClOL+MhGKq1t 40j3DsZQeuqr2tjyoQv3uKmTWj5HjP7m2zxZyRRVhHEk5BVt6IzxRig3q blJBxnUuZSzzV+/yWXkuupYOxoRNicRSN5FRARFBZDaSgrDeC1LEI/TLY JzpSvUq32Gt5c0D/Zt7F5bsQISmyiZe90oStSxoNfV1AYShr53kn4Nij5 9Px6LLGiM9DcDIRbJDcT+9VTMZ2Tx8Sy83loTxrIIRdND9Fqy74ApuFDy 9yKBv/+Q/rocM+P7BStBg7vUPMcCR+3TSElGemxvLJnkJpkfSZRFL3kwh Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10378"; a="342850907" X-IronPort-AV: E=Sophos;i="5.91,300,1647327600"; d="scan'208";a="342850907" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Jun 2022 01:56:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.91,300,1647327600"; d="scan'208";a="589000276" Received: from chaop.bj.intel.com (HELO localhost) ([10.240.192.101]) by fmsmga007.fm.intel.com with ESMTP; 15 Jun 2022 01:56:38 -0700 Date: Wed, 15 Jun 2022 16:53:16 +0800 From: Chao Peng To: Sean Christopherson Cc: "Gupta, Pankaj" , Vishal Annapurve , 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 , 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: <20220615085316.GA1823790@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> <20220601101747.GA1255243@chaop.bj.intel.com> <1f1b17e8-a16d-c029-88e0-01f522cc077a@amd.com> <20220602100733.GA1296997@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=1655283412; a=rsa-sha256; cv=none; b=C+AKdetPQ1xQpLxUq5pjlfk8AqD1eeQI0eG07etastu4FwtCM0xbgjjrVwWI07h4netQPE 2qLIwOns5QrHE3mhzH2pGwXVTQFHtGheuCkJIIMi2BRvFrt3FeJ9SxaZn69FaIcLwCGFJi AVCNUOJDBsBqF+meP2n+s9yqidg4noY= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=hYAnPULm; spf=none (imf09.hostedemail.com: domain of chao.p.peng@linux.intel.com has no SPF policy when checking 134.134.136.100) smtp.mailfrom=chao.p.peng@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655283412; 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=PJtvW+1e5trQrGylq5MwpSsq+OqVKmujOGbQEzylhTs=; b=5tiG/t49rfw94F3iJUlPxsbKKGg0oYtmLDwOC0Eecblof+JVvfIH15q4kNo4tyWCvd+TOE P9qiZ7ApWdGIW55y78B/fgXwqitYCFyryKwLHogLY4bATplm7O8kxr0MpyQU/iO7KKUd6G L50Yya3VCdxIbBgRHLyLOiIrNzRPB8Q= X-Stat-Signature: tz1xntzd844e98q64gby9y7qhcmhj6k6 X-Rspamd-Queue-Id: DF043140084 Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=hYAnPULm; spf=none (imf09.hostedemail.com: domain of chao.p.peng@linux.intel.com has no SPF policy when checking 134.134.136.100) smtp.mailfrom=chao.p.peng@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspamd-Server: rspam07 X-Rspam-User: X-HE-Tag: 1655283411-336831 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, Jun 14, 2022 at 08:23:46PM +0000, Sean Christopherson wrote: > On Thu, Jun 02, 2022, Chao Peng wrote: > > On Wed, Jun 01, 2022 at 02:11:42PM +0200, Gupta, Pankaj 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org%2Flkml%2F2022%2F5%2F9%2F1292&data=05%7C01%7Cpankaj.gupta%40amd.com%7Cb81ef334e2dd44c6143308da43b87d17%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637896756895977587%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=oQbM2Hj7GlhJTwnTM%2FPnwsfJlmTL7JR9ULBysAqm6V8%3D&reserved=0 > > > > 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. > > > > > > Common function or ioctl to populate preboot private memory actually makes > > > sense. > > > > > > Sorry, did not follow much of TDX code yet, Is it possible to filter out > > > the current TDX specific ioctl to common function so that it can be used by > > > other technologies? > > > > TDX code is here: > > https://patchwork.kernel.org/project/kvm/patch/70ed041fd47c1f7571aa259450b3f9244edda48d.1651774250.git.isaku.yamahata@intel.com/ > > > > AFAICS It might be possible to filter that out to a common function. But > > would like to hear from Paolo/Sean for their opinion. > > Eh, I wouldn't put too much effort into creating a common helper, I would be very > surprised if TDX and SNP can share a meaningful amount of code that isn't already > shared, e.g. provided by MMU helpers. > > The only part I truly care about sharing is whatever ioctl(s) get added, i.e. I > don't want to end up with two ioctls that do the same thing for TDX vs. SNP. OK, then that part would be better to be added in TDX or SNP series. Chao