Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp4960710pxb; Wed, 26 Jan 2022 01:27:12 -0800 (PST) X-Google-Smtp-Source: ABdhPJwxZ+pjjKuucS2MlDqoa6VYBRDfMr5Cu0yyqwBCQSQclglH0MrefPI9ogJ3PnVWk941OYG6 X-Received: by 2002:aa7:91d1:0:b0:4c0:27ac:4d6b with SMTP id z17-20020aa791d1000000b004c027ac4d6bmr21518537pfa.85.1643189231905; Wed, 26 Jan 2022 01:27:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643189231; cv=none; d=google.com; s=arc-20160816; b=M4lR6vPX2swmYYwWjL+pTMqxIFhp5gUJdQKgSXH0fJxMeLtrhm47QwJVzhu+Op8sDO tNxmVfcP3QQLrNq7c3OQurdXpsD6szTrSY0z/WAx9P7rWA+tZtS1kIynwGK+zQ1dRfBL cSUl3bOanFIGNGpWR3m4C5ZzAZA4XmymI8FwMja8GdBnnofx9vld0WQqcAaR0+Ybe2NN zPA10ahBztcQ6Oselg0xTNtUfxEVkZmqFTrseu7nrJAG4EDgMWizr4NPlLbU7TjqewBR a+TMuMADhi8j5dVNSdoncLfyCdcU5/+jBSm+uF+KMIy0kJq8znPSBhJz+cOOwJ1ehzv+ W9jA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:subject :from:references:cc:to:content-language:user-agent:mime-version:date :message-id; bh=UCAq6AtTq8pJWSM4wDgyLxylMxJzlPgnoTZ49XEYWA8=; b=HYRDuh8zkLWUz2nahUZ2ngC9Gm/vlNd4eyEsYyskdWMe97icnaTCtJkZ0wsNZtgLBQ v2G3kaLnt4/iiRtQ/IHB2H+pYmgVGojhk7bakc0NabnFdnhFNbfSqk5YLUluaK9HqENP j0kF8DtUUdLSpUzScpDXCil4/IUld6ewDAyrULxoRGcDULsW85cErilSyFCbt+CrzD40 Og2qf00O+HWLQ74wJohRJg0S5X59hqoBw8SZ03p4wCkpHshdS5X34qLJ0V+XhWTVkSmY tTz9/1CALE+IxrDbausshSaMJtaNgWFljFeu6UAudXXDLo6O1G4F/WTkZopudCjli/ny 6Jaw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v202si10362696pgb.401.2022.01.26.01.26.59; Wed, 26 Jan 2022 01:27:11 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231806AbiAYUVa (ORCPT + 99 others); Tue, 25 Jan 2022 15:21:30 -0500 Received: from vps-vb.mhejs.net ([37.28.154.113]:58180 "EHLO vps-vb.mhejs.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231669AbiAYUVX (ORCPT ); Tue, 25 Jan 2022 15:21:23 -0500 Received: from MUA by vps-vb.mhejs.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1nCSJ4-0006nf-3P; Tue, 25 Jan 2022 21:20:46 +0100 Message-ID: Date: Tue, 25 Jan 2022 21:20:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: Chao Peng , Yu Zhang Cc: 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 References: <20220118132121.31388-1-chao.p.peng@linux.intel.com> <20220118132121.31388-13-chao.p.peng@linux.intel.com> From: "Maciej S. Szmigiero" Subject: Re: [PATCH v4 12/12] KVM: Expose KVM_MEM_PRIVATE In-Reply-To: <20220118132121.31388-13-chao.p.peng@linux.intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Thanks, Maciej