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 1E641C43334 for ; Wed, 13 Jul 2022 08:01:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 910A06B00BE; Wed, 13 Jul 2022 04:01:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 89B616B00C0; Wed, 13 Jul 2022 04:01:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 713E86B00C2; Wed, 13 Jul 2022 04:01:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 5E31E6B00BE for ; Wed, 13 Jul 2022 04:01:10 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 30C3834C3D for ; Wed, 13 Jul 2022 08:01:10 +0000 (UTC) X-FDA: 79681331100.25.99B0B5C Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by imf13.hostedemail.com (Postfix) with ESMTP id EFC6D2008C for ; Wed, 13 Jul 2022 08:01:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1657699269; x=1689235269; h=date:from:to:cc:subject:message-id:reply-to:references: mime-version:in-reply-to; bh=7ENYqPqKTk0ESIJ/QoNgf3KZMY16w1kA6fyDKtIJ5rs=; b=SH0sLHiK4A97kpmZXVQP95z9Q6DTW7hWNkyAwwoKsw9UESJXBP3A4abY Mm3+1NRaOMvaHhx5MM0QGPF4vSkCrorIgQxRdMxtnGxKwkrSwutjOTkT9 tAVfY9zzkluplb4sJDvLCWIlr6luEQef4OweFOi20pjE99IjEuuA66sQ1 stflNycZkIkJ5wsEABuiDDxgMbvjoNJJuYBSdRGMw+lv2XrxxGub7k/tD KlVir1LSRHnAITmmYYDfR6LAEVUA4KmF4mW/xcb+ynTmajfWf65vzfwzT cDGU1Q6ydmqwORf+GPRCI8B5mboGHZBTmxI+mPRW5rViQv6ILPo8COajV Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10406"; a="285168803" X-IronPort-AV: E=Sophos;i="5.92,267,1650956400"; d="scan'208";a="285168803" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jul 2022 01:01:07 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.92,267,1650956400"; d="scan'208";a="685071104" Received: from chaop.bj.intel.com (HELO localhost) ([10.240.192.101]) by FMSMGA003.fm.intel.com with ESMTP; 13 Jul 2022 01:00:56 -0700 Date: Wed, 13 Jul 2022 15:57:38 +0800 From: Chao Peng To: "Gupta, Pankaj" 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 Subject: Re: [PATCH v7 00/14] KVM: mm: fd-based approach for supporting KVM guest private memory Message-ID: <20220713075738.GC2831541@chaop.bj.intel.com> Reply-To: Chao Peng References: <20220706082016.2603916-1-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=1657699269; a=rsa-sha256; cv=none; b=nl0mFVNF/Kqeu+vxpF/gwuU+9bUe/kcSO5srObbLytNRTeCosfkVO7wMNgC6E7Q3AhkhKx h6fLEASP8qCh9RK8L7nhbYZZEztL1gva10pi0rsgDLaFGeGKRuVS0g//vnwAakdFd74qax LcH60a9qi6N0utDTX4xeSdh+H7vQ58E= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=SH0sLHiK; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf13.hostedemail.com: domain of chao.p.peng@linux.intel.com has no SPF policy when checking 192.55.52.115) smtp.mailfrom=chao.p.peng@linux.intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657699269; 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=O499a85AGcx1AeCcCjNcN2V+ptL9yUsKefwHfLeWiZ8=; b=Bi/YTm2qnLS7DIEr2rCewZNN5Ua/GlDKLivWzaBgpKiOMwK1xEVtslo0N75tQi0urC2tt8 iUUxUe1Aqv65xe8c9uOXRjN77k/LD8+NWe2s6t6fTc6iItcvhRdsnL0vkG1+mlqnAB5Re9 zZfsqfpXqYA91wmMVKjy5eN3zfhP1hw= X-Stat-Signature: 6t7u3mjxatgjw4qqdrfw33zwtnug6s6n X-Rspamd-Queue-Id: EFC6D2008C Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=SH0sLHiK; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf13.hostedemail.com: domain of chao.p.peng@linux.intel.com has no SPF policy when checking 192.55.52.115) smtp.mailfrom=chao.p.peng@linux.intel.com X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1657699268-447625 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, Jul 13, 2022 at 05:58:32AM +0200, Gupta, Pankaj wrote: > > > This is the v7 of this series which tries to implement the fd-based KVM > > guest private memory. The patches are based on latest kvm/queue branch > > commit: > > > > b9b71f43683a (kvm/queue) KVM: x86/mmu: Buffer nested MMU > > split_desc_cache only by default capacity > > > > Introduction > > ------------ > > In general this patch series introduce fd-based memslot which provides > > guest memory through memory file descriptor fd[offset,size] instead of > > hva/size. The fd can be created from a supported memory filesystem > > like tmpfs/hugetlbfs etc. which we refer as memory backing store. KVM > > Thinking a bit, As host side fd on tmpfs or shmem will store memory on host > page cache instead of mapping pages into userspace address space. Can we hit > double (un-coordinated) page cache problem with this when guest page cache > is also used? This is my understanding: in host it will be indeed in page cache (in current shmem implementation) but that's just the way it allocates and provides the physical memory for the guest. In guest, guest OS will not see this fd (absolutely), it only sees guest memory, on top of which it can build its own page cache system for its own file-mapped content but that is unrelated to host page cache. Chao > > Thanks, > Pankaj >