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 3B153CD4942 for ; Thu, 21 Sep 2023 02:40:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A09756B017A; Wed, 20 Sep 2023 22:39:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9921F6B01F4; Wed, 20 Sep 2023 22:39:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 832E86B01F8; Wed, 20 Sep 2023 22:39:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 6F7136B017A for ; Wed, 20 Sep 2023 22:39:59 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 3D593C0E72 for ; Thu, 21 Sep 2023 02:39:59 +0000 (UTC) X-FDA: 81259049718.19.48C0EBA Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.151]) by imf13.hostedemail.com (Postfix) with ESMTP id B6DA020002 for ; Thu, 21 Sep 2023 02:39:56 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Q0XqABEU; spf=pass (imf13.hostedemail.com: domain of yilun.xu@intel.com designates 192.55.52.151 as permitted sender) smtp.mailfrom=yilun.xu@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695263997; 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=JAdcL1Vb0V3we8/jfNbxEuG94mdJ/UbpoVgc1qOsTSg=; b=0XdQSDc39gmbjVJUE/nFNaLnFyGfgs8Yb9CWqzwogyAxAqCB5uR60dPAzJwOEUdEi1oRTr anMg9mOcJOUmoztMOFAxkyNHFhEsJZfO4bO7aHNCAhwu/os10L4CwxsURMjMXODnH61Nyo 7g4mJkEJRW8/TviJSuLUXVWZkG265HE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695263997; a=rsa-sha256; cv=none; b=rTNAVSSIdYf7ptmnGnK+PjeSGfpdoOXvYmhaIYDV2j0iuh2cK5ZbYZwV9BIeaNS2ZArS8U jtOdPJbzkql/L9I3mMZp1NwynB6y7swYizOM7assZ3NsqGPyQLOBfWz+GBwSdRm2l5hin6 jJLZ9ViqEhBKFwi+T1ydkozB/Botl3Q= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Q0XqABEU; spf=pass (imf13.hostedemail.com: domain of yilun.xu@intel.com designates 192.55.52.151 as permitted sender) smtp.mailfrom=yilun.xu@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695263996; x=1726799996; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=iSkpE1N9Jcp84HPqnZ+sK/v5B9D3q8Q2ZGh6iASUxTU=; b=Q0XqABEUdlHN8XD3uFE9H0q1NCfJao/KwbUKk0ssyUpegrDI+YVZtm7B j5AXGfXxSnAHdaS0mjQxabU6cv/AbgKqwQ0ojxAC731IpbmxHwg5xEOEJ JEOqtk00fbFF8zqXz6ipSanOjRcV2ckx3FVihb2VHlEjCbqr7lSUWYAQE EADjJ+o7F9niYJxTXH9Q4LUGOfgDCIHiiONDt89cgzbbiumBILQXqjV7I CBcJcyvpd6DWudkGsg2IZASZfijhQ4ZeNYyLkpsUVbsrGEASWBBp821uk siDIAXEWM2eZWfQ4bMSljcx4sjQQ/MYKrNIAf0Bui2XQoKGPq6fzt7f2j w==; X-IronPort-AV: E=McAfee;i="6600,9927,10839"; a="360653937" X-IronPort-AV: E=Sophos;i="6.03,164,1694761200"; d="scan'208";a="360653937" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Sep 2023 19:39:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10839"; a="1077731075" X-IronPort-AV: E=Sophos;i="6.03,164,1694761200"; d="scan'208";a="1077731075" Received: from yilunxu-optiplex-7050.sh.intel.com (HELO localhost) ([10.239.159.165]) by fmsmga005.fm.intel.com with ESMTP; 20 Sep 2023 19:39:45 -0700 Date: Thu, 21 Sep 2023 10:39:18 +0800 From: Xu Yilun To: Sean Christopherson Cc: Paolo Bonzini , Marc Zyngier , Oliver Upton , Huacai Chen , Michael Ellerman , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , "Matthew Wilcox (Oracle)" , Andrew Morton , Paul Moore , James Morris , "Serge E. Hallyn" , kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, Chao Peng , Fuad Tabba , Jarkko Sakkinen , Anish Moorthy , Yu Zhang , Isaku Yamahata , Vlastimil Babka , Vishal Annapurve , Ackerley Tng , Maciej Szmigiero , David Hildenbrand , Quentin Perret , Michael Roth , Wang , Liam Merwick , Isaku Yamahata , "Kirill A . Shutemov" Subject: Re: [RFC PATCH v12 02/33] KVM: Use gfn instead of hva for mmu_notifier_retry Message-ID: References: <20230914015531.1419405-1-seanjc@google.com> <20230914015531.1419405-3-seanjc@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: B6DA020002 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: xdrhmd6zg4ddcqudnhd7jgh118o8buhu X-HE-Tag: 1695263996-38360 X-HE-Meta: U2FsdGVkX18r/ZghE3nvcL8NiQ+omv4z4mklIMb1zj++EsgMBC1Ab2W29Cial0V2td9yej/37pTNn5MvopGnMKiPQpAM8RmAej0TMHObC1lXny0LMSCt11oQ/Zp6HxdlbrQUQk4IcJzBJORRNykLHeJo5XtW7kkfeO6xYlAxkFvmIdtuCNG+FOYhAxUUVEi0/+C+dfFLXaFi3zhqcjLJTg8I+YU6t9l4e0pP0FNk5MNvrhTWTjlyboX+VgJI/tZno8v7zum8tl2pC3RgAgcRZliSBiaBlu+4hyTJaVR4oUqD6ZfJ+zibrWQWqY+0ySzi/y9m8Jn+UM0ZB6tlG+OQYKReUfpuU4FyUAdXMmUAMX11xErpawa0D3Pev7/wgqp8dKJeuEieXuPt6VD5e+4R/u4mfW9xPSveX/tRP9MfyrFfuExCqBGDWMtQmV3uGCPpfZ/k3pjHa7FeSTXz5KWo8h6kbQbteneT61R9/VCTEMMt1Oif4h4IaCakW3L4SWKJKO8rtfA6fScr8rpLZoAf0udy3qMavpU9xiY/Wjd17jOy72san8WTQM9GGxjOgaCN/AxpLw2Wb7CT4TGsvFW5d293jfmRADsDips9NbBxaMrrQ5XSMGt0s/KdshveexNdN7iDGVky0OZvhuXkjggGOZx3FrdRRDXx6Fug9bSJ+/1k1yWsaxZxobC/aEtMfxuAAu43dpC23yCw1nlqmT2MgyIlo6Xr1Vfkp+Q/JcbOA4zXEss51/5wAf/2EDPQiswRELTcWDr0sD+C+Y0OjmEQ1WK1ThOo23UglkIjCyXRVHwq6l3rEDp7YcYUWa+jCYES4c7jnh1HB6MJJ6dkd8XWG+vnvtTdA//MhA9Zjno1NBjNxVF2GQ8tEtyThBI3JzVEgVgJng/pF0TPLI05TzRJZqulTrfM3yPhOlOzkjFQVhN7aMDECD2BecjfwPiyzrfINrWwppYI2djuVTZdxgv RRLSVwnn 77EApA1HspiNNGhz5zdztfO4QeJvkE8Wk5nBw6gqr7K50nixlZijdKktUy6R32LzhEFifR0ND2Bk5ONyKs12R3+o3qcjVixKMl/8h7Q7/ZdrZssmEMYHiQMwVeQosrx6ZRDsfBr3kPdZH4tMZwFeNNTXtEljxl2saMlqAU7estSXQaAoEK19SpMRXLL1W+uLv35KlprD0klgqiGfn27A9eKGrMD8nss8NiZs6QNhbly62VocUWBHOXF2V8PAgGeEXwEOar2/j87kYI3glsiUsGQu1Zghq85SYel++MtPaENkV8hk= 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 2023-09-20 at 06:55:05 -0700, Sean Christopherson wrote: > On Wed, Sep 20, 2023, Xu Yilun wrote: > > On 2023-09-13 at 18:55:00 -0700, Sean Christopherson wrote: > > > +void kvm_mmu_invalidate_range_add(struct kvm *kvm, gfn_t start, gfn_t end) > > > +{ > > > + lockdep_assert_held_write(&kvm->mmu_lock); > > > + > > > + WARN_ON_ONCE(!kvm->mmu_invalidate_in_progress); > > > + > > > if (likely(kvm->mmu_invalidate_in_progress == 1)) { > > > kvm->mmu_invalidate_range_start = start; > > > kvm->mmu_invalidate_range_end = end; > > > > IIUC, Now we only add or override a part of the invalidate range in > > these fields, IOW only the range in last slot is stored when we unlock. > > Ouch. Good catch! > > > That may break mmu_invalidate_retry_gfn() cause it can never know the > > whole invalidate range. > > > > How about we extend the mmu_invalidate_range_start/end everytime so that > > it records the whole invalidate range: > > > > if (kvm->mmu_invalidate_range_start == INVALID_GPA) { > > kvm->mmu_invalidate_range_start = start; > > kvm->mmu_invalidate_range_end = end; > > } else { > > kvm->mmu_invalidate_range_start = > > min(kvm->mmu_invalidate_range_start, start); > > kvm->mmu_invalidate_range_end = > > max(kvm->mmu_invalidate_range_end, end); > > } > > Yeah, that does seem to be the easiest solution. > > I'll post a fixup patch, unless you want the honors. Please go ahead, cause at a second thought I'm wondering if this simple range extension is reasonable. When the invalidation acrosses multiple slots, I'm not sure if the contiguous HVA range must correspond to contiguous GFN range. If not, are we producing a larger range than required? And when the invalidation acrosses multiple address space, I'm almost sure it is wrong to merge GFN ranges from different address spaces. But I have no clear solution yet. Thanks, Yilun