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 A15EBC04A6A for ; Wed, 16 Aug 2023 13:39:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 25D778D0038; Wed, 16 Aug 2023 09:39:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1E5E98D0001; Wed, 16 Aug 2023 09:39:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0D5BC8D0038; Wed, 16 Aug 2023 09:39:26 -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 EB8918D0001 for ; Wed, 16 Aug 2023 09:39:25 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 79574140F10 for ; Wed, 16 Aug 2023 13:39:25 +0000 (UTC) X-FDA: 81130074690.22.3B00737 Received: from mail-yb1-f202.google.com (mail-yb1-f202.google.com [209.85.219.202]) by imf26.hostedemail.com (Postfix) with ESMTP id AE48214001D for ; Wed, 16 Aug 2023 13:39:23 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=KPi+rGDg; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf26.hostedemail.com: domain of 3itHcZAYKCM0Bxt62vz77z4x.v75416DG-553Etv3.7Az@flex--seanjc.bounces.google.com designates 209.85.219.202 as permitted sender) smtp.mailfrom=3itHcZAYKCM0Bxt62vz77z4x.v75416DG-553Etv3.7Az@flex--seanjc.bounces.google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692193163; a=rsa-sha256; cv=none; b=vPex4cLoAy9qj6ZNPJanANlMQTQ1WwJ+nu3VvuyhlL6ejT8EZSv+GyoX2uNbH2mAfc0iu/ d8MmB7g/kGXP2pg+k3LsNSZHCY8uOIQ5q0P3q5g7b6SM6eO+8AGWw4RDhEKJPXQ3bMUFoH pjNY9aMo4kigkHdNc7r/ZwRIYErwKXc= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=KPi+rGDg; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf26.hostedemail.com: domain of 3itHcZAYKCM0Bxt62vz77z4x.v75416DG-553Etv3.7Az@flex--seanjc.bounces.google.com designates 209.85.219.202 as permitted sender) smtp.mailfrom=3itHcZAYKCM0Bxt62vz77z4x.v75416DG-553Etv3.7Az@flex--seanjc.bounces.google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692193163; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=qjBB+Xzq/GvNmpPnRskR0EICzJkdM/dxZettTvi4CjI=; b=ZP35WMZXgH962IBeJmLx+JqdN5Q8b4HjoFAtetruvA1qMhUBvIKaCEg7Rlwq7CfDO3K4G+ UTdWwoNTt2oUFa1c4PWpib+2TTZ5NtPRuzOn9vngxkMKrd57zsxaabOtwurA5oHc47Iq+w LFlmUAzFNyH34wuM0cXnQAbt0HT0KYc= Received: by mail-yb1-f202.google.com with SMTP id 3f1490d57ef6-d6ac5db336eso3510242276.2 for ; Wed, 16 Aug 2023 06:39:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1692193162; x=1692797962; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=qjBB+Xzq/GvNmpPnRskR0EICzJkdM/dxZettTvi4CjI=; b=KPi+rGDgk7mm/LRgr7mpbcZNwO0VRb7nYCLi6YAi1zdHi4Pw0oJ/Yj9cNQQ07vCa7+ JNoovGqbU/K55F4LpOZfbQxjr1dCh3er3Bg0crdnLJf98/ObYmXVCbrb+f2xaArtk7cv dZtfKJecmqXFAQuDFesYQ1RnJmvQJJIr08sHL159ypOBtRD+hz/CGp2wS2P6GhvcY8EQ B3rcTPGVO7sgKEt3W1busYHPSMT8/UCYjziVJnCNe4enF9y8lO7guNtHNhUETXzDjH+1 4PsLf0kU27CEzxQpioUGimNwK5Y8oeHU3eE9fexD8UP1i1Oj4fSdDwn4VVhK20FBrNLd xHHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692193162; x=1692797962; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=qjBB+Xzq/GvNmpPnRskR0EICzJkdM/dxZettTvi4CjI=; b=Kc9xJYZpngt8NGvb/GgTflkKd4eC6QO+hpZdZ3lT0kH8fIvCLcli5ou9Nv8/CZqQNr G4UvUn6PwqNknm8CqitZtwny8uH54SFgn1OLMxBpCd8s5IT6EntzAq0xYOwZCX110yZv rRy9PoSDf4UDIjOw15DJb7aLhr8ly+5anS2XEPBKk06QKehioqavtozqqUEATFTJgTBt KBRilPWVBnLDHWSAOL+PM+OSvwaIBVwM6VrxHQPYpydzAqBvKfloZa1Q0MSdA3v6mcOm ml/9+Revn+SSb552vJZGebA892b3NH8ez32ST7fuU/1T9JsofBOS1CSFwF6lm8/jcfcb PXxA== X-Gm-Message-State: AOJu0Yx4JWqUIqNM9S+1EBG0hrEZa9oLncJRufXo35FnF0Y3ZO5v2rpF Qw9AZAqgI7Y3kUvlzcV0n6Glupr8sDw= X-Google-Smtp-Source: AGHT+IFWP0NUlvjkvht2jsW+fNJwVcLRVJBmUBKb7IbXE8/dRg9cj8UwboYpVeRqZUfyteoqaz0cmifLHbw= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:e6d2:0:b0:d72:8661:ee25 with SMTP id d201-20020a25e6d2000000b00d728661ee25mr8108ybh.2.1692193162535; Wed, 16 Aug 2023 06:39:22 -0700 (PDT) Date: Wed, 16 Aug 2023 06:39:20 -0700 In-Reply-To: <624efb22-8723-d813-0943-edab2870b51d@loongson.cn> Mime-Version: 1.0 References: <107cdaaf-237f-16b9-ebe2-7eefd2b21f8f@loongson.cn> <42ff33c7-ec50-1310-3e57-37e8283b9b16@loongson.cn> <624efb22-8723-d813-0943-edab2870b51d@loongson.cn> Message-ID: Subject: Re: [RFC PATCH v2 5/5] KVM: Unmap pages only when it's indeed protected for NUMA migration From: Sean Christopherson To: bibo mao Cc: Yan Zhao , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, pbonzini@redhat.com, mike.kravetz@oracle.com, apopple@nvidia.com, jgg@nvidia.com, rppt@kernel.org, akpm@linux-foundation.org, kevin.tian@intel.com, david@redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: AE48214001D X-Stat-Signature: rbfdmibta1bmcunsb5r9wdaneicbguwj X-HE-Tag: 1692193163-601190 X-HE-Meta: U2FsdGVkX1/YWmsJbb5yViTxxbdWlfgz8e86nfVUKK41MoTRHrB/F72TKdwEKTOjnU76/ulapPFUL/Hu66UVhbkGXYHTvS/XcQSsGvLB1YR6ftt4mA/X+JAjL+Us40BM2seER6Uu94q9+EnR1iElS93SdZjHUqA6i/91HTshw/jfu4LVjlwRA9gQulBTuX6/d1gci7ywT0V9hltkVEUAssMpU41JZOEcqePDwj0TYWVtBqRV0dHEn896rBK3aJABaqhpXMHTp4dzJPZEVjDNaWN5tnJH0Lmz1VVwE7gY2qETvdxiDgfDLH6nf6nYKFZ4cD0bxuZ0DpwfdvI8mj+YlY4Q7VgAO7s7x4sEQjlN2n5Q8HQQBU3OfTSVa0g2OfXbMe6OuQkdbdIiwodROHX20VugkpCuqx5ySnKlE7pTQncvx06d0COSpAebutJ+Tv0HTWLZc+2M6Qehh0O58FsrjCK4TTg1+EkHh1fxyDWBjKeztY6URxq5MCebmugqGTRw6vFufs674AWnyF9g2MC+T0vgcaH2Ym5ybITOTXFTLEOMOyQIuS8OSfqvgWQ8y5U0FrS5UL1XDznuUBkHBB8c7FNpFFp/9+Lw6VHbSVk1r2Uu2zirLzfMefnbJBSF9AX1LxEuraCOCTO8MPMKXuoKmdv5IQ8m/IPg867mf/ZFEe4sfnPUY0eh0bQ8UeiPz2vsqqnlI3lP8G1Z6hlOAHbAnMcPEqQbCCj9YOIsSK2hKAk5DuIqieX83L1BALDwMOouZPbleBSXd0FLpQeTGYiY6M2PHzTun7p3QasXPTwaMkutde/P3I3I1TYVywnTvV+HoXpCRMT4xl3X8mpBv4CPR5ShkZ79L0L+rTadnlL8PYkFv1kop+gucfE+iokZ3gVdSUae/4eT366zducKXZyJvKaEjOqoJs5Z9ul96/Jt5aurlfuG9DU7uEilIhzmKLycWSSlZE7lWVE3rnZ3/yM 1Ye0aRnC hZkLVlzEKy9MgabNoP0whB4XXC/LlhCS1OCGQXNRQVfy5Zp6jPtxkxRb6JHNtng11Xknafv6qrqV57ZZnW1to97XDBkfqI0AVoNcHrFxKY7Mi2snELP0ygQGbj55RDDAmoIR/GeihAj+rfLJXEBhc0YL+Wlwc1Id7GH+jMxUIIwm9PNLJ3BYjXRp5lV1pN4odYEeHeKWZMgBgP+KlEBK8ABhTxovKld0TAXVF1+SeKOaOam3i7c+YCiPYUuBSCTMnEXHbg6lhetjVzDztZvld/3tH1GOIQ94k2oJeH2CFUHIkOAaevd2pbbZfhAzHwTadPJYZfzv81d1b1gU2BDCrngxLKYuhThm2neCitsLplQRlzFeISU5Em6lss9CBecTOojsZuh9DukkE+uqAdXE8BQhdOeH5iEB8g+m3CRYt/CPgnMowooUgljo3baXa/n6Q2eIQk7LPFt6EEqVjYu2DRJQp5XluW7xdwZqnJRcO6dLzDWwGb4T7erXeBXbU8VvMa2Qr4o17O+AIgc7QjA/hm/0wXH0ZP880vwFSdtuPU+3iJVUgAZxNoHWdswhVh3hiCvPeSr9R2jQCyOhO4Pwewu1Aty9o0UbpzzBm2cSBrcIR8j0= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000003, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Aug 16, 2023, bibo mao wrote: >=20 >=20 > =E5=9C=A8 2023/8/16 15:18, Yan Zhao =E5=86=99=E9=81=93: > > On Wed, Aug 16, 2023 at 03:29:22PM +0800, bibo mao wrote: > >>> Flush must be done before kvm->mmu_lock is unlocked, otherwise, > >>> confusion will be caused when multiple threads trying to update the > >>> secondary MMU. > >> Since tlb flush is delayed after all pte entries are cleared, and curr= ently > >> there is no tlb flush range supported for secondary mmu. I do know why= there > >> is confusion before or after kvm->mmu_lock. > >=20 > > Oh, do you mean only do kvm_unmap_gfn_range() in .invalidate_range_end(= )? > yes, it is just sketchy thought for numa balance scenery,=20 > do kvm_unmap_gfn_range() in invalidate_range_end rather than > invalidate_range_start. That is not an option, it's a direction violation of the mmu_notifier contr= act. Secondary MMUs must drop all references before returning from invalidate_ra= nge_start().