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 8C02AC433F5 for ; Thu, 6 Oct 2022 15:07:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D92526B0072; Thu, 6 Oct 2022 11:07:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D412D6B0073; Thu, 6 Oct 2022 11:07:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BE2878E0001; Thu, 6 Oct 2022 11:07:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id AB83F6B0072 for ; Thu, 6 Oct 2022 11:07:15 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 7C0EA1C26AA for ; Thu, 6 Oct 2022 15:07:15 +0000 (UTC) X-FDA: 79990852830.09.25D5D7E Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf06.hostedemail.com (Postfix) with ESMTP id 6D480180015 for ; Thu, 6 Oct 2022 15:07:14 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 686EB619EB; Thu, 6 Oct 2022 15:07:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4FB2EC433D6; Thu, 6 Oct 2022 15:07:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1665068832; bh=aOkXuECcbSjQISc+01I1tvXXXenJbSlH28e8M1BvI94=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ipL5LglSgB96d6J8L2HRVMl+jXPn9WaZCDeQ01bYQBl4fNvQ1dM3lsq4Q1rZT43/e 04qttZa16SWURI2GfkK0oPR51suEX+KmL9EsCjFdWia96LnfzBWvtuqNVtpUW3BtJU vcNgsuDIFvSsLikBs88sxH/LdhpbfjE4y6loO4Mu7LZwOPT9sRBT/8sLT04H22RAal QWzkjxZVHXql+4CQTc3Zt3ML52Z7jwbzo3dBaWVQ7tNHxkNILSrzI4WPmGEaVVk6pI qS7RDP6QwQGatrjUNvs0hohnNuzTtFZ1Mq8tk9g2NPUW0j9qCUC4fQjJGqzWtnoJZi NyQ6cXDs2lPnw== Date: Thu, 6 Oct 2022 18:07:09 +0300 From: Jarkko Sakkinen To: Chao Peng 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 , 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, david@redhat.com, aarcange@redhat.com, ddutile@redhat.com, dhildenb@redhat.com, Quentin Perret , Michael Roth , mhocko@suse.com, Muchun Song , wei.w.wang@intel.com Subject: Re: [PATCH v8 2/8] KVM: Extend the memslot to support fd-based private memory Message-ID: References: <20220915142913.2213336-1-chao.p.peng@linux.intel.com> <20220915142913.2213336-3-chao.p.peng@linux.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=1665068834; a=rsa-sha256; cv=none; b=JXvvEwU9UBvYf+SblHD7Bqw/qAzN4ffR96/LCQ4kzkPxMDfs0fsuRxmL4DkqWay1RlZjcy qq4qegN79DVrGDJ/ut84JQUc3Abw2h/9/5HVFdBvUTT7ENAJE4SXdhL2eeACHT0ULwvrFW FqS5TnR4eXJ3t+doj9hJLCOeGmQb1i0= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ipL5LglS; spf=pass (imf06.hostedemail.com: domain of jarkko@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=jarkko@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665068834; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=FN1hS+Pq0UrG6SAfV8+9rjVAz5w2MtqpsI0JDrcKQn0=; b=aKRWkE9DO6UTK1v53ht9Ha9vdI4JC3I/FxEkSz7V8Fa611qe0NMnY5fVeibIy/qNd4xgWl f/23KiQf+WqzHoquJS1vmOA36XxCbvqWS6Utyeq9C+1g/b0KnoF+CIM7JULHfvaSPl56Ym yvQWfOOuesFF5LJTKAMuAcnoPO5Q+aU= X-Rspamd-Server: rspam08 X-Rspam-User: X-Rspamd-Queue-Id: 6D480180015 Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ipL5LglS; spf=pass (imf06.hostedemail.com: domain of jarkko@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=jarkko@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Stat-Signature: fyj3w1r6jjyyn6qx4z1xhmrttj7qqf6n X-HE-Tag: 1665068834-179432 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 Thu, Oct 06, 2022 at 05:58:03PM +0300, Jarkko Sakkinen wrote: > On Thu, Sep 15, 2022 at 10:29:07PM +0800, Chao Peng wrote: > > This new extension, indicated by the new flag KVM_MEM_PRIVATE, adds two > > additional KVM memslot fields private_fd/private_offset to allow > > userspace to specify that guest private memory provided from the > > private_fd and guest_phys_addr mapped at the private_offset of the > > private_fd, spanning a range of memory_size. > > > > The extended memslot can still have the userspace_addr(hva). When use, a > > single memslot can maintain both private memory through private > > fd(private_fd/private_offset) and shared memory through > > hva(userspace_addr). Whether the private or shared part is visible to > > guest is maintained by other KVM code. > > What is anyway the appeal of private_offset field, instead of having just > 1:1 association between regions and files, i.e. one memfd per region? > > If this was the case, then an extended struct would not be needed in the > first place. A simple union inside the existing struct would do: > > union { > __u64 userspace_addr, > __u64 private_fd, > }; Also, why is this mechanism just for fd's with MFD_INACCESSIBLE flag? I'd consider instead having KVM_MEM_FD flag. For generic KVM (if memfd does not have MFD_INACCESSIBLE set), KVM could just use the memory as it is using mapped memory. This would simplify user space code, as you can the use the same thing for both cases. BR, Jarkko