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 X-Spam-Level: X-Spam-Status: No, score=-15.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AE02FC433E1 for ; Mon, 29 Mar 2021 15:56:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5F54961976 for ; Mon, 29 Mar 2021 15:56:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230482AbhC2P4K (ORCPT ); Mon, 29 Mar 2021 11:56:10 -0400 Received: from foss.arm.com ([217.140.110.172]:56112 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230323AbhC2Pzc (ORCPT ); Mon, 29 Mar 2021 11:55:32 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E0F36142F; Mon, 29 Mar 2021 08:55:30 -0700 (PDT) Received: from [192.168.1.179] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BAA313F719; Mon, 29 Mar 2021 08:55:27 -0700 (PDT) Subject: Re: [PATCH v10 1/6] arm64: mte: Sync tags for pages where PTE is untagged To: Catalin Marinas Cc: Marc Zyngier , Will Deacon , James Morse , Julien Thierry , Suzuki K Poulose , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Dave Martin , Mark Rutland , Thomas Gleixner , qemu-devel@nongnu.org, Juan Quintela , "Dr. David Alan Gilbert" , Richard Henderson , Peter Maydell , Haibo Xu , Andrew Jones References: <20210312151902.17853-1-steven.price@arm.com> <20210312151902.17853-2-steven.price@arm.com> <20210326185653.GG5126@arm.com> From: Steven Price Message-ID: <21842e4d-7935-077c-3d6f-fced89b7f2bb@arm.com> Date: Mon, 29 Mar 2021 16:55:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <20210326185653.GG5126@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 26/03/2021 18:56, Catalin Marinas wrote: > Hi Steven, > > On Fri, Mar 12, 2021 at 03:18:57PM +0000, Steven Price wrote: >> A KVM guest could store tags in a page even if the VMM hasn't mapped >> the page with PROT_MTE. So when restoring pages from swap we will >> need to check to see if there are any saved tags even if !pte_tagged(). >> >> However don't check pages which are !pte_valid_user() as these will >> not have been swapped out. >> >> Signed-off-by: Steven Price >> --- >> arch/arm64/include/asm/pgtable.h | 2 +- >> arch/arm64/kernel/mte.c | 16 ++++++++++++---- >> 2 files changed, 13 insertions(+), 5 deletions(-) >> >> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h >> index e17b96d0e4b5..84166625c989 100644 >> --- a/arch/arm64/include/asm/pgtable.h >> +++ b/arch/arm64/include/asm/pgtable.h >> @@ -312,7 +312,7 @@ static inline void set_pte_at(struct mm_struct *mm, unsigned long addr, >> __sync_icache_dcache(pte); >> >> if (system_supports_mte() && >> - pte_present(pte) && pte_tagged(pte) && !pte_special(pte)) >> + pte_present(pte) && pte_valid_user(pte) && !pte_special(pte)) >> mte_sync_tags(ptep, pte); > > With the EPAN patches queued in for-next/epan, pte_valid_user() > disappeared as its semantics weren't very clear. Thanks for pointing that out. > So this relies on the set_pte_at() being done on the VMM address space. > I wonder, if the VMM did an mprotect(PROT_NONE), can the VM still access > it via stage 2? If yes, the pte_valid_user() test wouldn't work. We need > something like pte_present() && addr <= user_addr_max(). AFAIUI the stage 2 matches the VMM's address space (for the subset that has memslots). So mprotect(PROT_NONE) would cause the stage 2 mapping to be invalidated and a subsequent fault would exit to the VMM to sort out. This sort of thing is done for the lazy migration use case (i.e. pages are fetched as the VM tries to access them). > BTW, ignoring virtualisation, can we ever bring a page in from swap on a > PROT_NONE mapping (say fault-around)? It's not too bad if we keep the > metadata around for when the pte becomes accessible but I suspect we > remove it if the page is removed from swap. There are two stages of bringing data from swap. First is populating the swap cache by doing the physical read from swap. The second is actually restoring the page table entries. Clearly the first part can happen even with PROT_NONE (the simple case is there's another mapping which is !PROT_NONE). For the second I'm a little hazy on exactly what happens when you do a 'swapoff' - that may cause a page to be re-inserted into a page table without a fault. If you follow the chain down from try_to_unuse() you end up at a call to set_pte_at(). So we need set_pte_at() to handle a PROT_NONE mapping. So I guess the test we really want here is just (pte_val() & PTE_USER). Steve 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 X-Spam-Level: X-Spam-Status: No, score=-15.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F2BBEC433DB for ; Mon, 29 Mar 2021 15:56:28 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6A8A761964 for ; Mon, 29 Mar 2021 15:56:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6A8A761964 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:36664 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lQuFf-0004tu-2n for qemu-devel@archiver.kernel.org; Mon, 29 Mar 2021 11:56:27 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36896) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lQuEz-0004Cn-9s for qemu-devel@nongnu.org; Mon, 29 Mar 2021 11:55:45 -0400 Received: from foss.arm.com ([217.140.110.172]:48770) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lQuEo-0004rX-LO for qemu-devel@nongnu.org; Mon, 29 Mar 2021 11:55:44 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E0F36142F; Mon, 29 Mar 2021 08:55:30 -0700 (PDT) Received: from [192.168.1.179] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BAA313F719; Mon, 29 Mar 2021 08:55:27 -0700 (PDT) Subject: Re: [PATCH v10 1/6] arm64: mte: Sync tags for pages where PTE is untagged To: Catalin Marinas References: <20210312151902.17853-1-steven.price@arm.com> <20210312151902.17853-2-steven.price@arm.com> <20210326185653.GG5126@arm.com> From: Steven Price Message-ID: <21842e4d-7935-077c-3d6f-fced89b7f2bb@arm.com> Date: Mon, 29 Mar 2021 16:55:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <20210326185653.GG5126@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=217.140.110.172; envelope-from=steven.price@arm.com; helo=foss.arm.com X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Peter Maydell , "Dr. David Alan Gilbert" , Andrew Jones , Haibo Xu , Suzuki K Poulose , qemu-devel@nongnu.org, Marc Zyngier , Juan Quintela , Richard Henderson , linux-kernel@vger.kernel.org, Dave Martin , James Morse , linux-arm-kernel@lists.infradead.org, Thomas Gleixner , Will Deacon , kvmarm@lists.cs.columbia.edu, Julien Thierry Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On 26/03/2021 18:56, Catalin Marinas wrote: > Hi Steven, > > On Fri, Mar 12, 2021 at 03:18:57PM +0000, Steven Price wrote: >> A KVM guest could store tags in a page even if the VMM hasn't mapped >> the page with PROT_MTE. So when restoring pages from swap we will >> need to check to see if there are any saved tags even if !pte_tagged(). >> >> However don't check pages which are !pte_valid_user() as these will >> not have been swapped out. >> >> Signed-off-by: Steven Price >> --- >> arch/arm64/include/asm/pgtable.h | 2 +- >> arch/arm64/kernel/mte.c | 16 ++++++++++++---- >> 2 files changed, 13 insertions(+), 5 deletions(-) >> >> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h >> index e17b96d0e4b5..84166625c989 100644 >> --- a/arch/arm64/include/asm/pgtable.h >> +++ b/arch/arm64/include/asm/pgtable.h >> @@ -312,7 +312,7 @@ static inline void set_pte_at(struct mm_struct *mm, unsigned long addr, >> __sync_icache_dcache(pte); >> >> if (system_supports_mte() && >> - pte_present(pte) && pte_tagged(pte) && !pte_special(pte)) >> + pte_present(pte) && pte_valid_user(pte) && !pte_special(pte)) >> mte_sync_tags(ptep, pte); > > With the EPAN patches queued in for-next/epan, pte_valid_user() > disappeared as its semantics weren't very clear. Thanks for pointing that out. > So this relies on the set_pte_at() being done on the VMM address space. > I wonder, if the VMM did an mprotect(PROT_NONE), can the VM still access > it via stage 2? If yes, the pte_valid_user() test wouldn't work. We need > something like pte_present() && addr <= user_addr_max(). AFAIUI the stage 2 matches the VMM's address space (for the subset that has memslots). So mprotect(PROT_NONE) would cause the stage 2 mapping to be invalidated and a subsequent fault would exit to the VMM to sort out. This sort of thing is done for the lazy migration use case (i.e. pages are fetched as the VM tries to access them). > BTW, ignoring virtualisation, can we ever bring a page in from swap on a > PROT_NONE mapping (say fault-around)? It's not too bad if we keep the > metadata around for when the pte becomes accessible but I suspect we > remove it if the page is removed from swap. There are two stages of bringing data from swap. First is populating the swap cache by doing the physical read from swap. The second is actually restoring the page table entries. Clearly the first part can happen even with PROT_NONE (the simple case is there's another mapping which is !PROT_NONE). For the second I'm a little hazy on exactly what happens when you do a 'swapoff' - that may cause a page to be re-inserted into a page table without a fault. If you follow the chain down from try_to_unuse() you end up at a call to set_pte_at(). So we need set_pte_at() to handle a PROT_NONE mapping. So I guess the test we really want here is just (pte_val() & PTE_USER). Steve 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 X-Spam-Level: X-Spam-Status: No, score=-15.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 40AEEC433C1 for ; Mon, 29 Mar 2021 15:55:36 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 784F66195B for ; Mon, 29 Mar 2021 15:55:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 784F66195B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id CF6A74B23E; Mon, 29 Mar 2021 11:55:34 -0400 (EDT) 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 Ujf6CnRwYZXv; Mon, 29 Mar 2021 11:55:33 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 78E894B241; Mon, 29 Mar 2021 11:55:33 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id B7BED4B16D for ; Mon, 29 Mar 2021 11:55:32 -0400 (EDT) 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 S-cEhJ2sPAOh for ; Mon, 29 Mar 2021 11:55:31 -0400 (EDT) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 653B84B241 for ; Mon, 29 Mar 2021 11:55:31 -0400 (EDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E0F36142F; Mon, 29 Mar 2021 08:55:30 -0700 (PDT) Received: from [192.168.1.179] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BAA313F719; Mon, 29 Mar 2021 08:55:27 -0700 (PDT) Subject: Re: [PATCH v10 1/6] arm64: mte: Sync tags for pages where PTE is untagged To: Catalin Marinas References: <20210312151902.17853-1-steven.price@arm.com> <20210312151902.17853-2-steven.price@arm.com> <20210326185653.GG5126@arm.com> From: Steven Price Message-ID: <21842e4d-7935-077c-3d6f-fced89b7f2bb@arm.com> Date: Mon, 29 Mar 2021 16:55:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <20210326185653.GG5126@arm.com> Content-Language: en-GB Cc: "Dr. David Alan Gilbert" , qemu-devel@nongnu.org, Marc Zyngier , Juan Quintela , Richard Henderson , linux-kernel@vger.kernel.org, Dave Martin , linux-arm-kernel@lists.infradead.org, Thomas Gleixner , Will Deacon , kvmarm@lists.cs.columbia.edu 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On 26/03/2021 18:56, Catalin Marinas wrote: > Hi Steven, > > On Fri, Mar 12, 2021 at 03:18:57PM +0000, Steven Price wrote: >> A KVM guest could store tags in a page even if the VMM hasn't mapped >> the page with PROT_MTE. So when restoring pages from swap we will >> need to check to see if there are any saved tags even if !pte_tagged(). >> >> However don't check pages which are !pte_valid_user() as these will >> not have been swapped out. >> >> Signed-off-by: Steven Price >> --- >> arch/arm64/include/asm/pgtable.h | 2 +- >> arch/arm64/kernel/mte.c | 16 ++++++++++++---- >> 2 files changed, 13 insertions(+), 5 deletions(-) >> >> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h >> index e17b96d0e4b5..84166625c989 100644 >> --- a/arch/arm64/include/asm/pgtable.h >> +++ b/arch/arm64/include/asm/pgtable.h >> @@ -312,7 +312,7 @@ static inline void set_pte_at(struct mm_struct *mm, unsigned long addr, >> __sync_icache_dcache(pte); >> >> if (system_supports_mte() && >> - pte_present(pte) && pte_tagged(pte) && !pte_special(pte)) >> + pte_present(pte) && pte_valid_user(pte) && !pte_special(pte)) >> mte_sync_tags(ptep, pte); > > With the EPAN patches queued in for-next/epan, pte_valid_user() > disappeared as its semantics weren't very clear. Thanks for pointing that out. > So this relies on the set_pte_at() being done on the VMM address space. > I wonder, if the VMM did an mprotect(PROT_NONE), can the VM still access > it via stage 2? If yes, the pte_valid_user() test wouldn't work. We need > something like pte_present() && addr <= user_addr_max(). AFAIUI the stage 2 matches the VMM's address space (for the subset that has memslots). So mprotect(PROT_NONE) would cause the stage 2 mapping to be invalidated and a subsequent fault would exit to the VMM to sort out. This sort of thing is done for the lazy migration use case (i.e. pages are fetched as the VM tries to access them). > BTW, ignoring virtualisation, can we ever bring a page in from swap on a > PROT_NONE mapping (say fault-around)? It's not too bad if we keep the > metadata around for when the pte becomes accessible but I suspect we > remove it if the page is removed from swap. There are two stages of bringing data from swap. First is populating the swap cache by doing the physical read from swap. The second is actually restoring the page table entries. Clearly the first part can happen even with PROT_NONE (the simple case is there's another mapping which is !PROT_NONE). For the second I'm a little hazy on exactly what happens when you do a 'swapoff' - that may cause a page to be re-inserted into a page table without a fault. If you follow the chain down from try_to_unuse() you end up at a call to set_pte_at(). So we need set_pte_at() to handle a PROT_NONE mapping. So I guess the test we really want here is just (pte_val() & PTE_USER). Steve _______________________________________________ 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 X-Spam-Level: X-Spam-Status: No, score=-15.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 27537C433C1 for ; Mon, 29 Mar 2021 23:14:19 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 812296198A for ; Mon, 29 Mar 2021 23:14:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 812296198A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=RWeeZlVLR2899SKn4qUxX6yqoH09UHelEeN0O/9seXE=; b=XD1JKiprO0pz6lyreiuqf3n98 Ugi1UAHlr58Hsc8iPThTTB0LEktoDshoVGylSUyIC6tMvWwetqqbF4MTHCeTXmZoxWImcsCuXUD4j Q8k9pkiyiZZQO1j3Fw6Gxh4JqqiSw0Qq8GQ2PASo13VGs0QvHCq0HPs0PlUyRvu9Uceho8YR3XwH3 Ggmncwq56UlQ0TGU7J7rVAlZZrpoMTrPIimxirU1TZainkbnfPG3Zk0DHoJQnKjbcAvVse3BK8FTD KhIv3dx4uKNh6n3i1iwh2c7S6NJZeq4adkOyviaCP8FI2uw3YAu2kgF2whg6X6vEu0XWMWPceWacV ynICHcviA==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lR13Q-001rM8-2g; Mon, 29 Mar 2021 23:12:16 +0000 Received: from foss.arm.com ([217.140.110.172]) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lQuF2-000kO5-15 for linux-arm-kernel@lists.infradead.org; Mon, 29 Mar 2021 15:55:53 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E0F36142F; Mon, 29 Mar 2021 08:55:30 -0700 (PDT) Received: from [192.168.1.179] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BAA313F719; Mon, 29 Mar 2021 08:55:27 -0700 (PDT) Subject: Re: [PATCH v10 1/6] arm64: mte: Sync tags for pages where PTE is untagged To: Catalin Marinas Cc: Marc Zyngier , Will Deacon , James Morse , Julien Thierry , Suzuki K Poulose , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Dave Martin , Mark Rutland , Thomas Gleixner , qemu-devel@nongnu.org, Juan Quintela , "Dr. David Alan Gilbert" , Richard Henderson , Peter Maydell , Haibo Xu , Andrew Jones References: <20210312151902.17853-1-steven.price@arm.com> <20210312151902.17853-2-steven.price@arm.com> <20210326185653.GG5126@arm.com> From: Steven Price Message-ID: <21842e4d-7935-077c-3d6f-fced89b7f2bb@arm.com> Date: Mon, 29 Mar 2021 16:55:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <20210326185653.GG5126@arm.com> Content-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210329_165551_505711_FE9F2A51 X-CRM114-Status: GOOD ( 30.45 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 26/03/2021 18:56, Catalin Marinas wrote: > Hi Steven, > > On Fri, Mar 12, 2021 at 03:18:57PM +0000, Steven Price wrote: >> A KVM guest could store tags in a page even if the VMM hasn't mapped >> the page with PROT_MTE. So when restoring pages from swap we will >> need to check to see if there are any saved tags even if !pte_tagged(). >> >> However don't check pages which are !pte_valid_user() as these will >> not have been swapped out. >> >> Signed-off-by: Steven Price >> --- >> arch/arm64/include/asm/pgtable.h | 2 +- >> arch/arm64/kernel/mte.c | 16 ++++++++++++---- >> 2 files changed, 13 insertions(+), 5 deletions(-) >> >> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h >> index e17b96d0e4b5..84166625c989 100644 >> --- a/arch/arm64/include/asm/pgtable.h >> +++ b/arch/arm64/include/asm/pgtable.h >> @@ -312,7 +312,7 @@ static inline void set_pte_at(struct mm_struct *mm, unsigned long addr, >> __sync_icache_dcache(pte); >> >> if (system_supports_mte() && >> - pte_present(pte) && pte_tagged(pte) && !pte_special(pte)) >> + pte_present(pte) && pte_valid_user(pte) && !pte_special(pte)) >> mte_sync_tags(ptep, pte); > > With the EPAN patches queued in for-next/epan, pte_valid_user() > disappeared as its semantics weren't very clear. Thanks for pointing that out. > So this relies on the set_pte_at() being done on the VMM address space. > I wonder, if the VMM did an mprotect(PROT_NONE), can the VM still access > it via stage 2? If yes, the pte_valid_user() test wouldn't work. We need > something like pte_present() && addr <= user_addr_max(). AFAIUI the stage 2 matches the VMM's address space (for the subset that has memslots). So mprotect(PROT_NONE) would cause the stage 2 mapping to be invalidated and a subsequent fault would exit to the VMM to sort out. This sort of thing is done for the lazy migration use case (i.e. pages are fetched as the VM tries to access them). > BTW, ignoring virtualisation, can we ever bring a page in from swap on a > PROT_NONE mapping (say fault-around)? It's not too bad if we keep the > metadata around for when the pte becomes accessible but I suspect we > remove it if the page is removed from swap. There are two stages of bringing data from swap. First is populating the swap cache by doing the physical read from swap. The second is actually restoring the page table entries. Clearly the first part can happen even with PROT_NONE (the simple case is there's another mapping which is !PROT_NONE). For the second I'm a little hazy on exactly what happens when you do a 'swapoff' - that may cause a page to be re-inserted into a page table without a fault. If you follow the chain down from try_to_unuse() you end up at a call to set_pte_at(). So we need set_pte_at() to handle a PROT_NONE mapping. So I guess the test we really want here is just (pte_val() & PTE_USER). Steve _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel