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 EA56BC25B0E for ; Tue, 16 Aug 2022 12:22:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 72CCF6B0073; Tue, 16 Aug 2022 08:22:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6B51B6B007B; Tue, 16 Aug 2022 08:22:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 52E498D0001; Tue, 16 Aug 2022 08:22:06 -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 3F3926B0073 for ; Tue, 16 Aug 2022 08:22:06 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 07B2CC06A3 for ; Tue, 16 Aug 2022 12:22:06 +0000 (UTC) X-FDA: 79805367852.04.11D2C0A Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by imf05.hostedemail.com (Postfix) with ESMTP id 2C39C1001B7 for ; Tue, 16 Aug 2022 12:22:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1660652525; x=1692188525; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=B3uUd/yG6wpuTb/aR5iTfAme30Qm6tQlD5VU32Fh/CI=; b=Tifp/ISUfjpNRaPP/CY94u94leOZ91YRfJkuv3BDszBornbMs5Q6XRQ7 Ixcw0xfxSGlJ1Jg0hiYU0p5uFCXRilB6YP1Oef6lmkw0edqQbDB88Z1Zk 92hPzlG/ufTn1JT3E+1Bor79jl97sbJHqhdZcxEGuqk0Z1IAVbJxaAgBF 8TkLB0HHACBU+bOr/uWseGqjadJawZfkVjkgEF0OV/8Hm9kAqrgBq7FeF TucuT2O8paNDEBJxQExyYRDVCGdFPd1jsimk54wcpS0qKHTZDzhCHAQ47 lhhOfV7Q2m5H6OH4cSsSeil9POTww0F/BnV3p9UUmF5ySbm27HvydlkBK g==; X-IronPort-AV: E=McAfee;i="6400,9594,10440"; a="318196883" X-IronPort-AV: E=Sophos;i="5.93,241,1654585200"; d="scan'208";a="318196883" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Aug 2022 05:22:03 -0700 X-IronPort-AV: E=Sophos;i="5.93,241,1654585200"; d="scan'208";a="675194031" Received: from damianos-mobl.ger.corp.intel.com (HELO box.shutemov.name) ([10.252.40.45]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Aug 2022 05:21:54 -0700 Received: by box.shutemov.name (Postfix, from userid 1000) id 4FB31104A4E; Tue, 16 Aug 2022 15:24:57 +0300 (+03) Date: Tue, 16 Aug 2022 15:24:57 +0300 From: "Kirill A . Shutemov" To: "Gupta, Pankaj" Cc: Chao Peng , "Nikunj A. Dadhania" , Sean Christopherson , 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 , Shuah Khan , Mike Rapoport , Steven Price , "Maciej S . Szmigiero" , Vlastimil Babka , Vishal Annapurve , Yu Zhang , 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 , bharata@amd.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, linux-api@vger.kernel.org, linux-doc@vger.kernel.org, qemu-devel@nongnu.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v7 00/14] KVM: mm: fd-based approach for supporting KVM guest private memory Message-ID: <20220816122457.2fjyd4uz5hp5cani@box.shutemov.name> References: <20220706082016.2603916-1-chao.p.peng@linux.intel.com> <9e86daea-5619-a216-fe02-0562cf14c501@amd.com> <9dc91ce8-4cb6-37e6-4c25-27a72dc11dd0@amd.com> <422b9f97-fdf5-54bf-6c56-3c45eff5e174@amd.com> <1407c70c-0c0b-6955-10bb-d44c5928f2d9@amd.com> <1136925c-2e37-6af4-acac-be8bed9f6ed5@amd.com> <1b02db9d-f2f1-94dd-6f37-59481525abff@amd.com> <20220815130411.GA1073443@chaop.bj.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b="Tifp/ISU"; spf=none (imf05.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.88) smtp.mailfrom=kirill.shutemov@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=1660652525; a=rsa-sha256; cv=none; b=rxJkMXdFIHqqgAeEGNw9oUFpGINV2Y5PJzitoW99+z6zgwxp2I2yqKawikgIJTBaLpzxY0 LrpgitekiMSyz6ElXfawCvALW8Yr/1/Tae4OsQs7LHSxPXUc39lHStT3NakO3yDX0BotL5 dAi2JhD1pQD+1FduFHut1g79AdzX4c4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660652525; 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=nP7nUuidZW4hNzTqKU45P4PsyG6Glx3zHv3sZb4A4o0=; b=gQViMX8+5m3zvXZGfThj8OURa/u7CzyweWtrmIrjjr/Mu85FS+iJaitFnLpzzWRv0j9me5 ywAGSFQ5Q02n8j95Ud7FaMBEoq5g/9oLBySfG16oPwooPkMzQXoOL4Qa4YB5a9WKNjVUID ymJ/+d90nUU/jiuhGZVJpKTBPhPddxw= Authentication-Results: imf05.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b="Tifp/ISU"; spf=none (imf05.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.88) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none) X-Rspam-User: X-Rspamd-Server: rspam12 X-Stat-Signature: br8dqi7cr416zriou7pdcrqwqfjzi1td X-Rspamd-Queue-Id: 2C39C1001B7 X-HE-Tag: 1660652524-178053 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, Aug 16, 2022 at 01:33:00PM +0200, Gupta, Pankaj wrote: > Hi Chao, > > > > > Actually the current version allows you to delay the allocation to a > > later time (e.g. page fault time) if you don't call fallocate() on the > > private fd. fallocate() is necessary in previous versions because we > > treat the existense in the fd as 'private' but in this version we track > > private/shared info in KVM so we don't rely on that fact from memory > > backstores. > > Does this also mean reservation of guest physical memory with secure > processor (both for SEV-SNP & TDX) will also happen at page fault time? > > Do we plan to keep it this way? If you are talking about accepting memory by the guest, it is initiated by the guest and has nothing to do with page fault time vs fallocate() allocation of host memory. I mean acceptance happens after host memory allocation but they are not in lockstep, acceptance can happen much later. -- Kiryl Shutsemau / Kirill A. Shutemov