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 B4C4FC433F5 for ; Wed, 23 Feb 2022 12:01:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F30BD8D0002; Wed, 23 Feb 2022 07:01:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EB7F58D0001; Wed, 23 Feb 2022 07:01:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D32D38D0002; Wed, 23 Feb 2022 07:01:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0237.hostedemail.com [216.40.44.237]) by kanga.kvack.org (Postfix) with ESMTP id BE3478D0001 for ; Wed, 23 Feb 2022 07:01:16 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 7D47A8248D52 for ; Wed, 23 Feb 2022 12:01:16 +0000 (UTC) X-FDA: 79173904152.29.618E8D2 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by imf14.hostedemail.com (Postfix) with ESMTP id 679D710001D for ; Wed, 23 Feb 2022 12:01:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1645617675; x=1677153675; h=date:from:to:cc:subject:message-id:reply-to:references: mime-version:in-reply-to; bh=eoV+NoqJpfdApzLIf0eBSfJu/vs2jcIFT1WCrSXOtdw=; b=Oz5wXzzt+oXKiGv2/3dRmZq50/8mzrgCsN1xUpApxQOEFkcKiCP8xm5m HKVd3ovjHlFbb4c6hFwiwC4VRjchUZrBYFaNSuEL1aeR2xBuyngE8fJAG ip7r6CZ+DJYTP/hZ2xaaM40CwcVKiHju9rhduBGlYf0kwUDtIoj49wJre /WvCgwo81E2oWGJpUIOhstHFkeFpQy4BBrmLlQjBNAgokj3VVVh79p3UP E2SHysfBKMaRIZDQ7Q4l4FW/HEjs7VUsZYO181b9WxM5dM8uzQ9Z4njGx ooaQnGQVW2wMVfiE9PIdUTRTOx65dEnWMnfmGS7C/0SE6SsiqZwAiBjJ2 w==; X-IronPort-AV: E=McAfee;i="6200,9189,10266"; a="232568278" X-IronPort-AV: E=Sophos;i="5.88,390,1635231600"; d="scan'208";a="232568278" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Feb 2022 04:01:14 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.88,390,1635231600"; d="scan'208";a="532653565" Received: from chaop.bj.intel.com (HELO localhost) ([10.240.192.101]) by orsmga007.jf.intel.com with ESMTP; 23 Feb 2022 04:01:07 -0800 Date: Wed, 23 Feb 2022 20:00:47 +0800 From: Chao Peng To: "Maciej S. Szmigiero" Cc: Yu Zhang , Paolo Bonzini , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Jonathan Corbet , Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , kvm@vger.kernel.org, Borislav Petkov , x86@kernel.org, "H . Peter Anvin" , Hugh Dickins , Jeff Layton , "J . Bruce Fields" , Andrew Morton , "Kirill A . Shutemov" , luto@kernel.org, jun.nakajima@intel.com, dave.hansen@intel.com, ak@linux.intel.com, david@redhat.com, qemu-devel@nongnu.org Subject: Re: [PATCH v4 12/12] KVM: Expose KVM_MEM_PRIVATE Message-ID: <20220223120047.GB53733@chaop.bj.intel.com> Reply-To: Chao Peng References: <20220118132121.31388-1-chao.p.peng@linux.intel.com> <20220118132121.31388-13-chao.p.peng@linux.intel.com> <20220217134548.GA33836@chaop.bj.intel.com> <45148f5f-fe79-b452-f3b2-482c5c3291c4@maciej.szmigiero.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45148f5f-fe79-b452-f3b2-482c5c3291c4@maciej.szmigiero.name> User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspam-User: Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Oz5wXzzt; spf=none (imf14.hostedemail.com: domain of chao.p.peng@linux.intel.com has no SPF policy when checking 192.55.52.151) smtp.mailfrom=chao.p.peng@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 679D710001D X-Stat-Signature: sas6gbahs9ks9odzt3hut5n8x8sg9786 X-HE-Tag: 1645617675-749460 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, Feb 22, 2022 at 02:16:46AM +0100, Maciej S. Szmigiero wrote: > On 17.02.2022 14:45, Chao Peng wrote: > > On Tue, Jan 25, 2022 at 09:20:39PM +0100, Maciej S. Szmigiero wrote: > > > On 18.01.2022 14:21, Chao Peng wrote: > > > > KVM_MEM_PRIVATE is not exposed by default but architecture code can turn > > > > on it by implementing kvm_arch_private_memory_supported(). > > > > > > > > Also private memslot cannot be movable and the same file+offset can not > > > > be mapped into different GFNs. > > > > > > > > Signed-off-by: Yu Zhang > > > > Signed-off-by: Chao Peng > > > > --- > > > (..) > > > > static bool kvm_check_memslot_overlap(struct kvm_memslots *slots, int id, > > > > - gfn_t start, gfn_t end) > > > > + struct file *file, > > > > + gfn_t start, gfn_t end, > > > > + loff_t start_off, loff_t end_off) > > > > { > > > > struct kvm_memslot_iter iter; > > > > + struct kvm_memory_slot *slot; > > > > + struct inode *inode; > > > > + int bkt; > > > > kvm_for_each_memslot_in_gfn_range(&iter, slots, start, end) { > > > > if (iter.slot->id != id) > > > > return true; > > > > } > > > > + /* Disallow mapping the same file+offset into multiple gfns. */ > > > > + if (file) { > > > > + inode = file_inode(file); > > > > + kvm_for_each_memslot(slot, bkt, slots) { > > > > + if (slot->private_file && > > > > + file_inode(slot->private_file) == inode && > > > > + !(end_off <= slot->private_offset || > > > > + start_off >= slot->private_offset > > > > + + (slot->npages >> PAGE_SHIFT))) > > > > + return true; > > > > + } > > > > + } > > > > > > That's a linear scan of all memslots on each CREATE (and MOVE) operation > > > with a fd - we just spent more than a year rewriting similar linear scans > > > into more efficient operations in KVM. > > > > In the last version I tried to solve this problem by using interval tree > > (just like existing hva_tree), but finally we realized that in one VM we > > can have multiple fds with overlapped offsets so that approach is > > incorrect. See https://lkml.org/lkml/2021/12/28/480 for the discussion. > > That's right, in this case a two-level structure would be necessary: > the first level matching a file, then the second level matching that > file ranges. > However, if such data is going to be used just for checking possible > overlap at memslot add or move time it is almost certainly an overkill. Yes, that is also what I'm seeing. > > > So linear scan is used before I can find a better way. > > Another option would be to simply not check for overlap at add or move > time, declare such configuration undefined behavior under KVM API and > make sure in MMU notifiers that nothing bad happens to the host kernel > if it turns out somebody actually set up a VM this way (it could be > inefficient in this case, since it's not supposed to ever happen > unless there is a bug somewhere in the userspace part). Specific to TDX case, SEAMMODULE will fail the overlapping case and then KVM prints a message to the kernel log. It will not cause any other side effect, it does look weird however. Yes warn that in the API document can help to some extent. Thanks, Chao > > > Chao > > Thanks, > Maciej