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 00D31C3DA42 for ; Wed, 10 Jul 2024 09:50:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 153646B007B; Wed, 10 Jul 2024 05:50:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 103646B0082; Wed, 10 Jul 2024 05:50:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F0C3E6B0083; Wed, 10 Jul 2024 05:50:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id D39606B007B for ; Wed, 10 Jul 2024 05:50:28 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 4E456161C00 for ; Wed, 10 Jul 2024 09:50:28 +0000 (UTC) X-FDA: 82323372936.14.56FCC48 Received: from smtp-fw-80008.amazon.com (smtp-fw-80008.amazon.com [99.78.197.219]) by imf21.hostedemail.com (Postfix) with ESMTP id 1B29C1C001A for ; Wed, 10 Jul 2024 09:50:24 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=amazon.co.uk header.s=amazon201209 header.b=Km9L6yqm; spf=pass (imf21.hostedemail.com: domain of "prvs=914e10141=roypat@amazon.co.uk" designates 99.78.197.219 as permitted sender) smtp.mailfrom="prvs=914e10141=roypat@amazon.co.uk"; dmarc=pass (policy=quarantine) header.from=amazon.co.uk ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720604993; 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=wWlHFuKGYfQe+7qWn8NY5kBRpARTw54+NYGwoDXEwGY=; b=awy/FxnaVoviEY6UeD6JxAS9vWK0sTWXnO5b9y6ml6+E8aUmwP+XGtEjYF9SbLLsoIZXQd vSkXTIgA+Mwz5X5f+W45GiC4+kNkquRzO/GR78WBk2GEUgfM4qoaco870LaWaUADSilJ39 Pc+QGxn+Hntca5aI1nb2DEsklqJO/4s= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720604993; a=rsa-sha256; cv=none; b=gIrVTRIcBrrAW2zEN1mnorQ1N3R/6FEC0s3dpIy69Q+/eZUZgsEH+z9FqjFDb9OSRVbjI+ TcmUFz7WVhMi24gDyeaA3lB3pU0+3bgXkY1bV4j2m8udoyn1Xb18fGMn797lWsFeB6Nf1c 3IQ4PCcxuJruq7pMeNTrJ6Igz1qJOQI= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=amazon.co.uk header.s=amazon201209 header.b=Km9L6yqm; spf=pass (imf21.hostedemail.com: domain of "prvs=914e10141=roypat@amazon.co.uk" designates 99.78.197.219 as permitted sender) smtp.mailfrom="prvs=914e10141=roypat@amazon.co.uk"; dmarc=pass (policy=quarantine) header.from=amazon.co.uk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.co.uk; i=@amazon.co.uk; q=dns/txt; s=amazon201209; t=1720605025; x=1752141025; h=message-id:date:mime-version:to:cc:references:from: in-reply-to:content-transfer-encoding:subject; bh=wWlHFuKGYfQe+7qWn8NY5kBRpARTw54+NYGwoDXEwGY=; b=Km9L6yqmgHnBKTay0szce2z3Hp1SmCaTqCh/SnRQlapv/To3gBLOFdgy prOsbBoOafvNBzcVt+dQpsrFgmktzzm77TDVO9xF5CSYMnqHz8CVhAr0V XfrX60tx2G3IHNvQCyl5hTX79/6w15S8Wqveg3iIma5A8d7XdkltkBt+e w=; X-IronPort-AV: E=Sophos;i="6.09,197,1716249600"; d="scan'208";a="104186022" Subject: Re: [RFC PATCH 3/8] kvm: pfncache: enlighten about gmem Received: from pdx4-co-svc-p1-lb2-vlan3.amazon.com (HELO smtpout.prod.us-west-2.prod.farcaster.email.amazon.dev) ([10.25.36.214]) by smtp-border-fw-80008.pdx80.corp.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jul 2024 09:50:04 +0000 Received: from EX19MTAUWB002.ant.amazon.com [10.0.38.20:56457] by smtpin.naws.us-west-2.prod.farcaster.email.amazon.dev [10.0.38.80:2525] with esmtp (Farcaster) id 17aaa3d3-f61c-40d6-940f-1ec90393b603; Wed, 10 Jul 2024 09:50:04 +0000 (UTC) X-Farcaster-Flow-ID: 17aaa3d3-f61c-40d6-940f-1ec90393b603 Received: from EX19D020UWA004.ant.amazon.com (10.13.138.231) by EX19MTAUWB002.ant.amazon.com (10.250.64.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1258.34; Wed, 10 Jul 2024 09:50:04 +0000 Received: from EX19MTAUWB001.ant.amazon.com (10.250.64.248) by EX19D020UWA004.ant.amazon.com (10.13.138.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1258.34; Wed, 10 Jul 2024 09:50:04 +0000 Received: from [127.0.0.1] (172.19.88.180) by mail-relay.amazon.com (10.250.64.254) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1258.34 via Frontend Transport; Wed, 10 Jul 2024 09:49:58 +0000 Message-ID: Date: Wed, 10 Jul 2024 10:49:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: David Woodhouse , , , , , CC: , , , , , , , , , , , , , , , , , James Gowans References: <20240709132041.3625501-1-roypat@amazon.co.uk> <20240709132041.3625501-4-roypat@amazon.co.uk> Content-Language: en-US From: Patrick Roy Autocrypt: addr=roypat@amazon.co.uk; keydata= xjMEY0UgYhYJKwYBBAHaRw8BAQdA7lj+ADr5b96qBcdINFVJSOg8RGtKthL5x77F2ABMh4PN NVBhdHJpY2sgUm95IChHaXRodWIga2V5IGFtYXpvbikgPHJveXBhdEBhbWF6b24uY28udWs+ wpMEExYKADsWIQQ5DAcjaM+IvmZPLohVg4tqeAbEAgUCY0UgYgIbAwULCQgHAgIiAgYVCgkI CwIEFgIDAQIeBwIXgAAKCRBVg4tqeAbEAmQKAQC1jMl/KT9pQHEdALF7SA1iJ9tpA5ppl1J9 AOIP7Nr9SwD/fvIWkq0QDnq69eK7HqW14CA7AToCF6NBqZ8r7ksi+QLOOARjRSBiEgorBgEE AZdVAQUBAQdAqoMhGmiXJ3DMGeXrlaDA+v/aF/ah7ARbFV4ukHyz+CkDAQgHwngEGBYKACAW IQQ5DAcjaM+IvmZPLohVg4tqeAbEAgUCY0UgYgIbDAAKCRBVg4tqeAbEAtjHAQDkh5jZRIsZ 7JMNkPMSCd5PuSy0/Gdx8LGgsxxPMZwePgEAn5Tnh4fVbf00esnoK588bYQgJBioXtuXhtom 8hlxFQM= In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 1B29C1C001A X-Stat-Signature: h9so5nn5jh1iszhx48ozuzzpjuftnygq X-HE-Tag: 1720605024-951883 X-HE-Meta: U2FsdGVkX190Txx68oc+utlaxPLkVEOoYLQ5ANLbAhxKvm1FLt/YNw03jkCNrqflcc2MY/FqE3N6Gf3PHB4LQIeiEgfiZUQ/Rfbw3EnVbhJaiaJetBJAsmHep3rqKL8QLtzjMd8rsuY8LBsME3uCD8co6ZM2qGgRgWjOCoN9YDBXrPh1Hww4NKGNf+kg6md3jokzl5ApOCnf2V0M9TbL8mD6jvK3R1ZLB8pSCvHOfNaZTWalSCV++MHNAER0x1Y7F1Ao7pE/fApwQiblUO6I+CB0BkUW+dXZ2Da7hwvzlhVl0xDzWiyGPjUdMwjjomjEGcmWa1svKsx5pim6nJ5R4OwKjh0oyxkzcjPkuBr6BvKgDkq+RzE/s3kS+tGTgXry/ENSet3xrVC33u7ABvKjv0dvwb3M0hO7umemg4RA/nWy1b0mnAQJK0P47tLwg+CJROIA04nWXE951ryuvGgEXGe6EQ6p/5OBGTzfsHNwxVHnZWcpNKoqjsCWDIx6tAHK4AuPUHL/y1p5ZRM3MHtLQQ6C0n8PkFEQmQC40aILeJD7oQsh4slJLXEANbaFHJOsLTiIMUra+Gx6q6HTXoxZdeGZr8pU0i3nJtJfyZYH+KDhoKDUZ7Zt+LnxAK4TNiqAlOiQQNyClIYjt5YGOxP1rF0EwMpAC1Tp8pw+sxnaKAVcWlGDOSWc7A9eDrom9Mo76Q/Nhz7uPP3DfEBonjFo493BAiynZvfskvlqrUMUDYNpnmn6d6SuOYsY/Jimd0pHukkM0yaA+0jyJ8NAl5rWxG75lmha+xhDg4LweVfPFBrpyz5dEPw8dWYEZrNXgzm50yR/Gw/P/9/3nuxcIc5/BF28qcapMrTypAA2pV0z2b+jO92tG9+nEK7msd6wMckbPIP6m5cljLIXU3VFOIoMAwO0deC6tGs/e03ZaS1oh8O10DLILR0JrDrWQYWMM1qX6GR9EmzJrie4bdHU543 jmKwffOG mRy5PYihqwQGIX2kp+LL9bPPzGVdjaMDqDIIHxoZNOi/ZlH3bl+yqgTANI8O6EN25awnKoEsJgf/Rf4TUIGp/BffboNzTGCK5t9+2qf372tcerFP9CS7gmWuUoIOgyByoiyP4lhvjxrKKktjgLlBIqD2AustM1HqZvx++JySKNTxlmHipc/y9McLwmIsQ5wuwC+eQrBFTcD+vtM0zQtMXBfklHS3Nl2YaPAeOpeHcjC7dScgkSuMzubM9GFyVg9DpX30DefFd1Z759JD8xWqzjoUC5odc5m+GqRrdq+0M6tRH6xv5m/7VbSNRRqYfc0kKFREmPWb2jStbe+SQXWXCnVHRzECPR+86tGccpsBoODqMXdmY/NXMYb4hgGgmH9no8oGh970HKxnNMcHy8x2RRuC9eJc1jQhhuWY/Qm+zvr7O8Ekn6d/LDWale3p5NAk6WVpTAp9QwbJQ0y8= 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: List-Subscribe: List-Unsubscribe: On 7/9/24 15:36, David Woodhouse wrote: > On Tue, 2024-07-09 at 14:20 +0100, Patrick Roy wrote: >> KVM uses gfn_to_pfn_caches to cache translations from gfn all the way to >> the pfn (for example, kvm-clock caches the page storing the page used >> for guest/host communication this way). Unlike the gfn_to_hva_cache, >> where no equivalent caching semantics were possible to gmem-backed gfns >> (see also 858e8068a750 ("kvm: pfncache: enlighten about gmem")), here it >> is possible to simply cache the pfn returned by `kvm_gmem_get_pfn`. >> >> Additionally, gfn_to_pfn_caches now invalidate whenever a cached gfn's >> attributes are flipped from shared to private (or vice-versa). >> >> Signed-off-by: Patrick Roy > > I can't see how this is safe from race conditions. > > When the GPC is invalidated from gfn_to_pfn_cache_invalidate_start() > its *write* lock is taken and gpc->valid is set to false. > > In parallel, any code using the GPC to access guest memory will take > the *read* lock, call kvm_gpc_check(), and then go ahead and use the > pointer to its heart's content until eventually dropping the read lock. > > Since invalidation takes the write lock, it has to wait until the GPC > is no longer in active use, and the pointer cannot be being > dereferenced. > > How does this work for the kvm_mem_is_private() check. You've added a > check in kvm_gpc_check(), but what if the pfn is made private > immediately *after* that check? Unless the code path which makes the > pfn private also takes the write lock, how is it safe? Ah, you're right - I did in fact overlook this. I do think that it works out though: kvm_vm_set_mem_attributes, which is used for flipping between shared/private, registers the range which had its attributes changed for invalidation, and thus gfn_to_pfn_cache_invalidate_start should get called for it (although I have to admit I do not immediately see what the exact callstack for this looks like, so maybe I am misunderstanding something about invalidation here?).