Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp466623imw; Wed, 13 Jul 2022 01:44:56 -0700 (PDT) X-Google-Smtp-Source: AGRyM1s95zgJHTi94UoQze9LsKNiPuxuF//VooTdTcTGdLinoXBvjmbkP+1RLn937AtEyiZL+vXF X-Received: by 2002:a17:90b:30c4:b0:1ef:8d1b:f9bf with SMTP id hi4-20020a17090b30c400b001ef8d1bf9bfmr2653366pjb.158.1657701896075; Wed, 13 Jul 2022 01:44:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657701896; cv=none; d=google.com; s=arc-20160816; b=tgvROej14KccZ1eKEDENeGFXfa7++QmT78DqJ1saji1YgLKKF5gLsCjcqWfWiaXmtx 5L7XbwrR9KjKWzDqi1+ESorDxbpiXMF1OxW21ri1NWNebrHRDPVOeQrg2QMCsqLUWE7h 9iawPdkl1VKqD8czioBj6YlRLQRU3XXeyjDR4l9TFqDIL/0qvlnqYhj6RR9P4hOpASqx d/qxNU92oHbKlSWLPpAMTruloY6phybJDrwC1fuGPq954NOYrI6tMRaJjxqpoLU+kzNS OXNRjlNyvBPO2lUch/QpELJshlvwRUUDmkQD38OeFBZS4tfQwHAmGCxsowzNfdcou+r6 IaOA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=O499a85AGcx1AeCcCjNcN2V+ptL9yUsKefwHfLeWiZ8=; b=xAiRRC1llFXPesUxLEoD/erzNFVy7i8H+HNmTMZILVhOqOUhAvHOInDPvB8yOPjUk/ t+d2qusklQf+g+ddCH0N5Hg4uISP+KoRfMZl/xdJip2Pk8FYDlx4sIJKntLcIhLz3/pF yP+00/2Au7m5gOEEs8xXUdnYCIgqiTlE65WVTp/37DP0qybNdPE+806BwzNkQ/IN4qZO 5FIz5LJVaGATFR7f+UF57Z2AOpAbDjYZkmdbnRb3QKNjdt4G1nGgczXiUKAmuVJ+F1TB gqNBLfJvEiGmmaqb47lBcPO0gC9RYVASiwK91vPvVYgYhirkktre/cFl3auTA3b07sbe bT7g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=kNCjkJ85; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i190-20020a6387c7000000b00414de676c21si13660657pge.649.2022.07.13.01.44.43; Wed, 13 Jul 2022 01:44:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=kNCjkJ85; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234889AbiGMIB2 (ORCPT + 99 others); Wed, 13 Jul 2022 04:01:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59916 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231664AbiGMIBZ (ORCPT ); Wed, 13 Jul 2022 04:01:25 -0400 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2ED1FE024B; Wed, 13 Jul 2022 01:01:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1657699284; x=1689235284; h=date:from:to:cc:subject:message-id:reply-to:references: mime-version:in-reply-to; bh=7ENYqPqKTk0ESIJ/QoNgf3KZMY16w1kA6fyDKtIJ5rs=; b=kNCjkJ85qfjLYK9qXQSQByNS+v9xJRKUpuzu8lH80gStYi9Iozs7Rl0h 0HWCpUEP5oZSEvmpeWEXVAV+YKETkCaOUeZ3C7XOuk59dNVJkhoQKYaEI GiPmRlpQ8wZQPNJDZokx6u0l3H9jYr7KtOsoh0Dwl96MjgUuJBz++qjsh kqkF32AcVYSyINx5VEzI0vbCScmCr08tsJaZJ4tMhc+b6DZ6c8Rp6xi4C /RCaXDMVFL9tbZ+xIJdK2hij6L3q9l23+m8Kt8u3D76xOALO4b1TytUNh VIeD9HjgOzaIS2Tf8JHtjjtaePuqrlqN41IOwCDb860KmKZJPxx2d0s75 w==; X-IronPort-AV: E=McAfee;i="6400,9594,10406"; a="286277206" X-IronPort-AV: E=Sophos;i="5.92,267,1650956400"; d="scan'208";a="286277206" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jul 2022 01:01:08 -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: X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >