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 542C6C38145 for ; Fri, 2 Sep 2022 10:24:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 74DDD8D001E; Fri, 2 Sep 2022 06:24:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6FD2A8D001B; Fri, 2 Sep 2022 06:24:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5C5558D001E; Fri, 2 Sep 2022 06:24:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 4A6618D001B for ; Fri, 2 Sep 2022 06:24:02 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 18B051A1157 for ; Fri, 2 Sep 2022 10:24:02 +0000 (UTC) X-FDA: 79866759924.06.939A871 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by imf13.hostedemail.com (Postfix) with ESMTP id 025582003F for ; Fri, 2 Sep 2022 10:24:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1662114241; x=1693650241; h=date:from:to:cc:subject:message-id:reply-to:references: mime-version:content-transfer-encoding:in-reply-to; bh=Hmx1025FThlE9cx1UE6O8SOkWc9A3kuNYU7VIFp8RZU=; b=lI4nJSOsnNO+F10TuA2UftYjt9bEdlyPos2gxrhdKiE2BeCZbquyoO1/ 0pi3CiB/xVda7rOYOXYDEQtLHzXomLgnN9D0nhn9ct5uxW9l7aq7aNPd9 0746AhmeD9EG7a3oZt0JRfFzprI1KcDYaAkjhSZ4xo4DZXM1uD4trUI1t fbbgoVnbwhy5DHiUdRAXiW+7cvk2rxkLYxpgIe+FeDvirhc68DLnY/cXF yZQ5XkTdClArZxrRuYXquHA9yyN8mIzvYrLQ8rw1Xo4nx7008zn7Jdl6F gvHManVyBNLT3M3IAByZg2rmrNtrg2/ROu5kHB6rei32TNQWzcdIkk3es w==; X-IronPort-AV: E=McAfee;i="6500,9779,10457"; a="382250572" X-IronPort-AV: E=Sophos;i="5.93,283,1654585200"; d="scan'208";a="382250572" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Sep 2022 03:23:59 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.93,283,1654585200"; d="scan'208";a="608943940" Received: from chaop.bj.intel.com (HELO localhost) ([10.240.193.75]) by orsmga007.jf.intel.com with ESMTP; 02 Sep 2022 03:23:46 -0700 Date: Fri, 2 Sep 2022 18:19:05 +0800 From: Chao Peng To: Fuad Tabba 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, linux-kselftest@vger.kernel.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 , Marc Zyngier , Will Deacon Subject: Re: [PATCH v7 00/14] KVM: mm: fd-based approach for supporting KVM guest private memory Message-ID: <20220902101905.GA1712673@chaop.bj.intel.com> Reply-To: Chao Peng References: <20220706082016.2603916-1-chao.p.peng@linux.intel.com> <20220829151756.GB1586678@chaop.bj.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662114241; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=IlQv9rxZxqDPlPwd71hyeD73AAm2Zyf4Z9yoEETv6tI=; b=uljrisO2NqkDuQpv6GGJWkITQH1sa9bCdfyJmxRXAEwrIEHZkPCLOYk6tc9VH6B6meRdIM fHMJ2j30tAq3xYVvfLuOWZyr7sgRF8AVeegtdxubzefZ7avC4NItB2mCHBM3g3mLlaxJiz SRz51535UPNykQl3zmbwyGWEvrc1zQI= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=lI4nJSOs; spf=none (imf13.hostedemail.com: domain of chao.p.peng@linux.intel.com has no SPF policy when checking 192.55.52.43) 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=1662114241; a=rsa-sha256; cv=none; b=DS72b9knOiM+p61p+pLHx0bIDhAUFukXTdQIOTGkMU+ui+P1DlG81+LG7N+0c47RM+4WA4 nsuPccOUrdn7SK/+293oO3YlicHTem+OYbOb2JGCG+13uFYEi0e6uHpbBc05f4uZmstubl XpK71XTMmpDBMoLpjZAyiiNnQKycS6w= X-Stat-Signature: zj1afgwjhfxoaxa4c1drm1nxikn5oxg5 X-Rspamd-Queue-Id: 025582003F Authentication-Results: imf13.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=lI4nJSOs; spf=none (imf13.hostedemail.com: domain of chao.p.peng@linux.intel.com has no SPF policy when checking 192.55.52.43) smtp.mailfrom=chao.p.peng@linux.intel.com; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none) X-Rspamd-Server: rspam12 X-Rspam-User: X-HE-Tag: 1662114240-216498 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 Wed, Aug 31, 2022 at 10:12:12AM +0100, Fuad Tabba wrote: > > > Moreover, something which was discussed here before [3], is the > > > ability to share in-place. For pKVM/arm64, the conversion between > > > shared and private involves only changes to the stage-2 page tables, > > > which are controlled by the hypervisor. Android supports this in-place > > > conversion already, and I think that the cost of copying for many > > > use-cases that would involve large amounts of data would be big. We > > > will measure the relative costs in due course, but in the meantime > > > we¡¯re nervous about adopting a new user ABI which doesn¡¯t appear to > > > cater for in-place conversion; having just the fd would simplify that > > > somewhat > > > > I understand there is difficulty to achieve that with the current > > private_fd + userspace_addr (they basically in two separate fds), but is > > it possible for pKVM to extend this? Brainstorming for example, pKVM can > > ignore userspace_addr and only use private_fd to cover both shared and > > private memory, or pKVM introduce new KVM memslot flag? > > It's not that there's anything blocking pKVM from doing that. It's > that the disconnect of using a memory address for the shared memory, > and a file descriptor for the private memory doesn't really make sense > for pKVM. I see how it makes sense for TDX and the Intel-specific > implementation. It just seems that this is baking in an > implementation-specific aspect as a part of the KVM general api, and > the worry is that this might have some unintended consequences in the > future. It's true this API originates from supporting TDX and probably other similar confidential computing(CC) technologies. But if we ever get chance to make it more common to cover more usages like pKVM, I would also like to. The challenge on this point is pKVM diverges a lot from CC usages, putting both shared and private memory in the same fd complicates CC usages. If two things are different enough, I'm also thinking implementation-specific may not be that bad. Chao