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 mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id 30193C433FE for ; Thu, 24 Nov 2022 10:39:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 91D4D40439; Thu, 24 Nov 2022 05:39:19 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@kernel.org Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1TSceZO59e9; Thu, 24 Nov 2022 05:39:18 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 40FEE40443; Thu, 24 Nov 2022 05:39:18 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 8E16A40417 for ; Thu, 24 Nov 2022 05:39:16 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jpHe8AppR7f for ; Thu, 24 Nov 2022 05:39:15 -0500 (EST) Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 128D540171 for ; Thu, 24 Nov 2022 05:39:15 -0500 (EST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id A1FF6B826C8; Thu, 24 Nov 2022 10:39:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 531F3C433C1; Thu, 24 Nov 2022 10:39:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1669286352; bh=L1+jBgistF0AFANuNIFVPs/iK+/oLopvwHGSP0X0ATQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=jJqBTlJKSqMBMarfbumGPWbm5RAFoYbgOYpXbaMrbhhXCfvbmCoXnGpivtFpeZwjJ paJN86JEL53PgITILBqempYlp77s6xcao2H+IgVbvWt8ynBxXve0WO7WJMZZbw3vXu jZhcf7BQZVV/jhynfB8n6TA/FYb/aoAXWKWQXhN+NnC3RstRmFaPoOlP/FHKnZ9TC6 eCaHxLU5TN2axuBcwQYGwOXLu9dgPEzKppV9yuSpUEt4C1NVjCFwB0HXSwwpGM3KfD PCOcTdolEMfynHrQm5VDM8dT8IyfdgUvN/5vK5sAT1k5m/FAgEs5k4N9qsKRcFzMBl OEHk3OuPNs6Jg== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1oy9dO-008LQm-31; Thu, 24 Nov 2022 10:39:10 +0000 Date: Thu, 24 Nov 2022 10:39:09 +0000 Message-ID: <86a64gocvm.wl-maz@kernel.org> From: Marc Zyngier To: Peter Collingbourne , linux-mm , Andrew Morton Subject: Re: [PATCH v5 0/8] KVM: arm64: permit MAP_SHARED mappings with MTE enabled In-Reply-To: References: <20221104011041.290951-1-pcc@google.com> <86a656r8nh.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: pcc@google.com, linux-mm@kvack.org, akpm@linux-foundation.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, cohuck@redhat.com, catalin.marinas@arm.com, will@kernel.org, eugenis@google.com, kvm@vger.kernel.org, steven.price@arm.com, vincenzo.frascino@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Cc: kvm@vger.kernel.org, Catalin Marinas , Cornelia Huck , Steven Price , linux-arm-kernel@lists.infradead.org, Vincenzo Frascino , Will Deacon , kvmarm@lists.cs.columbia.edu, Evgenii Stepanov X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Fri, 04 Nov 2022 17:42:27 +0000, Peter Collingbourne wrote: > > On Fri, Nov 4, 2022 at 9:23 AM Marc Zyngier wrote: > > > > On Fri, 04 Nov 2022 01:10:33 +0000, > > Peter Collingbourne wrote: > > > > > > Hi, > > > > > > This patch series allows VMMs to use shared mappings in MTE enabled > > > guests. The first five patches were taken from Catalin's tree [1] which > > > addressed some review feedback from when they were previously sent out > > > as v3 of this series. The first patch from Catalin's tree makes room > > > for an additional PG_arch_3 flag by making the newer PG_arch_* flags > > > arch-dependent. The next four patches are based on a series that > > > Catalin sent out prior to v3, whose cover letter [2] I quote from below: > > > > > > > This series aims to fix the races between initialising the tags on a > > > > page and setting the PG_mte_tagged flag. Currently the flag is set > > > > either before or after that tag initialisation and this can lead to CoW > > > > copying stale tags. The first patch moves the flag setting after the > > > > tags have been initialised, solving the CoW issue. However, concurrent > > > > mprotect() on a shared mapping may (very rarely) lead to valid tags > > > > being zeroed. > > > > > > > > The second skips the sanitise_mte_tags() call in kvm_set_spte_gfn(), > > > > deferring it to user_mem_abort(). The outcome is that no > > > > sanitise_mte_tags() can be simplified to skip the pfn_to_online_page() > > > > check and only rely on VM_MTE_ALLOWED vma flag that can be checked in > > > > user_mem_abort(). > > > > > > > > The third and fourth patches use PG_arch_3 as a lock for page tagging, > > > > based on Peter Collingbourne's idea of a two-bit lock. > > > > > > > > I think the first patch can be queued but the rest needs some in depth > > > > review and test. With this series (if correct) we could allos MAP_SHARED > > > > on KVM guest memory but this is to be discussed separately as there are > > > > some KVM ABI implications. > > > > > > In this v5 I rebased Catalin's tree onto -next again. Please double check > > > > Please don't do use -next as a base. In-flight series should be based > > on a *stable* tag, either 6.0 or one of the early -RCs. If there is a > > known conflict with -next, do mention it in the cover letter and > > provide a resolution. > > Okay, I will keep that in mind. > > > > my rebase, which resolved the conflict with commit a8e5e5146ad0 ("arm64: > > > mte: Avoid setting PG_mte_tagged if no tags cleared or restored"). > > > > This commit seems part of -rc1, so I guess the patches directly apply > > on top of that tag? > > Yes, sorry, this also applies cleanly to -rc1. > > > > I now have Reviewed-by for all patches except for the last one, which adds > > > the documentation. Thanks for the reviews so far, and please take a look! > > > > I'd really like the MM folks (list now cc'd) to look at the relevant > > patches (1 and 5) and ack them before I take this. > > Okay, here are the lore links for the convenience of the MM folks: > https://lore.kernel.org/all/20221104011041.290951-2-pcc@google.com/ > https://lore.kernel.org/all/20221104011041.290951-6-pcc@google.com/ I have not seen any Ack from the MM folks so far, and we're really running out of runway for this merge window. Short of someone shouting now, I'll take the series into the kvmarm tree early next week. Thanks, -- Without deviation from the norm, progress is not possible. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1A22CC43219 for ; Thu, 24 Nov 2022 10:40:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=MuGQMunOp/GpLcoNYjNRNCraXcG5NhpStVNxg2Rih10=; b=eYWQOYJHDBUYhA Q2eJoqG3ueMOm/qn6XvW/PU7FfSvFIIszqhOMb1080Q0ihQpSKmFHopsM+OCAq4ziPFKBTsnFsgXj 1GZUWYQvQ8d0OomI5fJ+NS1KTDIkij2CbPmiAlwakucCPXnqQN/tw1yNfh6c28uYFHBvGKY8BC2LD KE6OOE+43DtdRxt2SxhIxVZLJqztmmp9XHT/8AxPbtCkX8E/cJKUbphJZ+ZhZ4/f8cuLQBYb7grDq bN1zkh41WOG42bHYqrQ3H+mj/skUOhogCBADouCKHKAEmF5pPyWN7kS96jdNQlhw+lgpRB32lLBZU CAm+FaofQruz4czGeRLA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oy9da-007kik-EZ; Thu, 24 Nov 2022 10:39:22 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oy9dV-007kfg-Px for linux-arm-kernel@lists.infradead.org; Thu, 24 Nov 2022 10:39:19 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id A1FF6B826C8; Thu, 24 Nov 2022 10:39:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 531F3C433C1; Thu, 24 Nov 2022 10:39:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1669286352; bh=L1+jBgistF0AFANuNIFVPs/iK+/oLopvwHGSP0X0ATQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=jJqBTlJKSqMBMarfbumGPWbm5RAFoYbgOYpXbaMrbhhXCfvbmCoXnGpivtFpeZwjJ paJN86JEL53PgITILBqempYlp77s6xcao2H+IgVbvWt8ynBxXve0WO7WJMZZbw3vXu jZhcf7BQZVV/jhynfB8n6TA/FYb/aoAXWKWQXhN+NnC3RstRmFaPoOlP/FHKnZ9TC6 eCaHxLU5TN2axuBcwQYGwOXLu9dgPEzKppV9yuSpUEt4C1NVjCFwB0HXSwwpGM3KfD PCOcTdolEMfynHrQm5VDM8dT8IyfdgUvN/5vK5sAT1k5m/FAgEs5k4N9qsKRcFzMBl OEHk3OuPNs6Jg== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1oy9dO-008LQm-31; Thu, 24 Nov 2022 10:39:10 +0000 Date: Thu, 24 Nov 2022 10:39:09 +0000 Message-ID: <86a64gocvm.wl-maz@kernel.org> From: Marc Zyngier To: Peter Collingbourne , linux-mm , Andrew Morton Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, Cornelia Huck , Catalin Marinas , Will Deacon , Evgenii Stepanov , kvm@vger.kernel.org, Steven Price , Vincenzo Frascino Subject: Re: [PATCH v5 0/8] KVM: arm64: permit MAP_SHARED mappings with MTE enabled In-Reply-To: References: <20221104011041.290951-1-pcc@google.com> <86a656r8nh.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: pcc@google.com, linux-mm@kvack.org, akpm@linux-foundation.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, cohuck@redhat.com, catalin.marinas@arm.com, will@kernel.org, eugenis@google.com, kvm@vger.kernel.org, steven.price@arm.com, vincenzo.frascino@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221124_023918_159889_B22EB39D X-CRM114-Status: GOOD ( 42.74 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, 04 Nov 2022 17:42:27 +0000, Peter Collingbourne wrote: > > On Fri, Nov 4, 2022 at 9:23 AM Marc Zyngier wrote: > > > > On Fri, 04 Nov 2022 01:10:33 +0000, > > Peter Collingbourne wrote: > > > > > > Hi, > > > > > > This patch series allows VMMs to use shared mappings in MTE enabled > > > guests. The first five patches were taken from Catalin's tree [1] which > > > addressed some review feedback from when they were previously sent out > > > as v3 of this series. The first patch from Catalin's tree makes room > > > for an additional PG_arch_3 flag by making the newer PG_arch_* flags > > > arch-dependent. The next four patches are based on a series that > > > Catalin sent out prior to v3, whose cover letter [2] I quote from below: > > > > > > > This series aims to fix the races between initialising the tags on a > > > > page and setting the PG_mte_tagged flag. Currently the flag is set > > > > either before or after that tag initialisation and this can lead to CoW > > > > copying stale tags. The first patch moves the flag setting after the > > > > tags have been initialised, solving the CoW issue. However, concurrent > > > > mprotect() on a shared mapping may (very rarely) lead to valid tags > > > > being zeroed. > > > > > > > > The second skips the sanitise_mte_tags() call in kvm_set_spte_gfn(), > > > > deferring it to user_mem_abort(). The outcome is that no > > > > sanitise_mte_tags() can be simplified to skip the pfn_to_online_page() > > > > check and only rely on VM_MTE_ALLOWED vma flag that can be checked in > > > > user_mem_abort(). > > > > > > > > The third and fourth patches use PG_arch_3 as a lock for page tagging, > > > > based on Peter Collingbourne's idea of a two-bit lock. > > > > > > > > I think the first patch can be queued but the rest needs some in depth > > > > review and test. With this series (if correct) we could allos MAP_SHARED > > > > on KVM guest memory but this is to be discussed separately as there are > > > > some KVM ABI implications. > > > > > > In this v5 I rebased Catalin's tree onto -next again. Please double check > > > > Please don't do use -next as a base. In-flight series should be based > > on a *stable* tag, either 6.0 or one of the early -RCs. If there is a > > known conflict with -next, do mention it in the cover letter and > > provide a resolution. > > Okay, I will keep that in mind. > > > > my rebase, which resolved the conflict with commit a8e5e5146ad0 ("arm64: > > > mte: Avoid setting PG_mte_tagged if no tags cleared or restored"). > > > > This commit seems part of -rc1, so I guess the patches directly apply > > on top of that tag? > > Yes, sorry, this also applies cleanly to -rc1. > > > > I now have Reviewed-by for all patches except for the last one, which adds > > > the documentation. Thanks for the reviews so far, and please take a look! > > > > I'd really like the MM folks (list now cc'd) to look at the relevant > > patches (1 and 5) and ack them before I take this. > > Okay, here are the lore links for the convenience of the MM folks: > https://lore.kernel.org/all/20221104011041.290951-2-pcc@google.com/ > https://lore.kernel.org/all/20221104011041.290951-6-pcc@google.com/ I have not seen any Ack from the MM folks so far, and we're really running out of runway for this merge window. Short of someone shouting now, I'll take the series into the kvmarm tree early next week. Thanks, -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D5308C433FE for ; Thu, 24 Nov 2022 10:39:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229726AbiKXKjR (ORCPT ); Thu, 24 Nov 2022 05:39:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33110 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229704AbiKXKjP (ORCPT ); Thu, 24 Nov 2022 05:39:15 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 749B214D86E for ; Thu, 24 Nov 2022 02:39:13 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 0F500620A1 for ; Thu, 24 Nov 2022 10:39:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 531F3C433C1; Thu, 24 Nov 2022 10:39:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1669286352; bh=L1+jBgistF0AFANuNIFVPs/iK+/oLopvwHGSP0X0ATQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=jJqBTlJKSqMBMarfbumGPWbm5RAFoYbgOYpXbaMrbhhXCfvbmCoXnGpivtFpeZwjJ paJN86JEL53PgITILBqempYlp77s6xcao2H+IgVbvWt8ynBxXve0WO7WJMZZbw3vXu jZhcf7BQZVV/jhynfB8n6TA/FYb/aoAXWKWQXhN+NnC3RstRmFaPoOlP/FHKnZ9TC6 eCaHxLU5TN2axuBcwQYGwOXLu9dgPEzKppV9yuSpUEt4C1NVjCFwB0HXSwwpGM3KfD PCOcTdolEMfynHrQm5VDM8dT8IyfdgUvN/5vK5sAT1k5m/FAgEs5k4N9qsKRcFzMBl OEHk3OuPNs6Jg== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1oy9dO-008LQm-31; Thu, 24 Nov 2022 10:39:10 +0000 Date: Thu, 24 Nov 2022 10:39:09 +0000 Message-ID: <86a64gocvm.wl-maz@kernel.org> From: Marc Zyngier To: Peter Collingbourne , linux-mm , Andrew Morton Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, Cornelia Huck , Catalin Marinas , Will Deacon , Evgenii Stepanov , kvm@vger.kernel.org, Steven Price , Vincenzo Frascino Subject: Re: [PATCH v5 0/8] KVM: arm64: permit MAP_SHARED mappings with MTE enabled In-Reply-To: References: <20221104011041.290951-1-pcc@google.com> <86a656r8nh.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: pcc@google.com, linux-mm@kvack.org, akpm@linux-foundation.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, cohuck@redhat.com, catalin.marinas@arm.com, will@kernel.org, eugenis@google.com, kvm@vger.kernel.org, steven.price@arm.com, vincenzo.frascino@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Fri, 04 Nov 2022 17:42:27 +0000, Peter Collingbourne wrote: > > On Fri, Nov 4, 2022 at 9:23 AM Marc Zyngier wrote: > > > > On Fri, 04 Nov 2022 01:10:33 +0000, > > Peter Collingbourne wrote: > > > > > > Hi, > > > > > > This patch series allows VMMs to use shared mappings in MTE enabled > > > guests. The first five patches were taken from Catalin's tree [1] which > > > addressed some review feedback from when they were previously sent out > > > as v3 of this series. The first patch from Catalin's tree makes room > > > for an additional PG_arch_3 flag by making the newer PG_arch_* flags > > > arch-dependent. The next four patches are based on a series that > > > Catalin sent out prior to v3, whose cover letter [2] I quote from below: > > > > > > > This series aims to fix the races between initialising the tags on a > > > > page and setting the PG_mte_tagged flag. Currently the flag is set > > > > either before or after that tag initialisation and this can lead to CoW > > > > copying stale tags. The first patch moves the flag setting after the > > > > tags have been initialised, solving the CoW issue. However, concurrent > > > > mprotect() on a shared mapping may (very rarely) lead to valid tags > > > > being zeroed. > > > > > > > > The second skips the sanitise_mte_tags() call in kvm_set_spte_gfn(), > > > > deferring it to user_mem_abort(). The outcome is that no > > > > sanitise_mte_tags() can be simplified to skip the pfn_to_online_page() > > > > check and only rely on VM_MTE_ALLOWED vma flag that can be checked in > > > > user_mem_abort(). > > > > > > > > The third and fourth patches use PG_arch_3 as a lock for page tagging, > > > > based on Peter Collingbourne's idea of a two-bit lock. > > > > > > > > I think the first patch can be queued but the rest needs some in depth > > > > review and test. With this series (if correct) we could allos MAP_SHARED > > > > on KVM guest memory but this is to be discussed separately as there are > > > > some KVM ABI implications. > > > > > > In this v5 I rebased Catalin's tree onto -next again. Please double check > > > > Please don't do use -next as a base. In-flight series should be based > > on a *stable* tag, either 6.0 or one of the early -RCs. If there is a > > known conflict with -next, do mention it in the cover letter and > > provide a resolution. > > Okay, I will keep that in mind. > > > > my rebase, which resolved the conflict with commit a8e5e5146ad0 ("arm64: > > > mte: Avoid setting PG_mte_tagged if no tags cleared or restored"). > > > > This commit seems part of -rc1, so I guess the patches directly apply > > on top of that tag? > > Yes, sorry, this also applies cleanly to -rc1. > > > > I now have Reviewed-by for all patches except for the last one, which adds > > > the documentation. Thanks for the reviews so far, and please take a look! > > > > I'd really like the MM folks (list now cc'd) to look at the relevant > > patches (1 and 5) and ack them before I take this. > > Okay, here are the lore links for the convenience of the MM folks: > https://lore.kernel.org/all/20221104011041.290951-2-pcc@google.com/ > https://lore.kernel.org/all/20221104011041.290951-6-pcc@google.com/ I have not seen any Ack from the MM folks so far, and we're really running out of runway for this merge window. Short of someone shouting now, I'll take the series into the kvmarm tree early next week. Thanks, -- Without deviation from the norm, progress is not possible.