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=-9.0 required=3.0 tests=BAYES_00,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 8A6D7C2B9F4 for ; Thu, 17 Jun 2021 13:15:34 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 0F8ED6109D for ; Thu, 17 Jun 2021 13:15:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0F8ED6109D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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 829724A4A0; Thu, 17 Jun 2021 09:15:33 -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 8loyRWg6XEz8; Thu, 17 Jun 2021 09:15:31 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 10E674A4BE; Thu, 17 Jun 2021 09:15:31 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 8DD014A418 for ; Thu, 17 Jun 2021 09:15:29 -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 FHqlfQW+hB4e for ; Thu, 17 Jun 2021 09:15:27 -0400 (EDT) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 90E6A407B0 for ; Thu, 17 Jun 2021 09:15:27 -0400 (EDT) Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7B4F76100B; Thu, 17 Jun 2021 13:15:26 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ltrrg-008BNM-Kj; Thu, 17 Jun 2021 14:15:24 +0100 Date: Thu, 17 Jun 2021 14:15:24 +0100 Message-ID: <87im2cd443.wl-maz@kernel.org> From: Marc Zyngier To: Catalin Marinas Subject: Re: [PATCH v15 0/7] MTE support for KVM guest In-Reply-To: <20210617121322.GC6314@arm.com> References: <20210614090525.4338-1-steven.price@arm.com> <20210617121322.GC6314@arm.com> 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 (x86_64-pc-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: catalin.marinas@arm.com, steven.price@arm.com, will@kernel.org, james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Dave.Martin@arm.com, mark.rutland@arm.com, tglx@linutronix.de, qemu-devel@nongnu.org, quintela@redhat.com, dgilbert@redhat.com, richard.henderson@linaro.org, peter.maydell@linaro.org, Haibo.Xu@arm.com, drjones@redhat.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Cc: "Dr. David Alan Gilbert" , qemu-devel@nongnu.org, Dave Martin , Juan Quintela , Richard Henderson , linux-kernel@vger.kernel.org, Steven Price , 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-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 Thu, 17 Jun 2021 13:13:22 +0100, Catalin Marinas wrote: > > On Mon, Jun 14, 2021 at 10:05:18AM +0100, Steven Price wrote: > > I realise there are still open questions[1] around the performance of > > this series (the 'big lock', tag_sync_lock, introduced in the first > > patch). But there should be no impact on non-MTE workloads and until we > > get real MTE-enabled hardware it's hard to know whether there is a need > > for something more sophisticated or not. Peter Collingbourne's patch[3] > > to clear the tags at page allocation time should hide more of the impact > > for non-VM cases. So the remaining concern is around VM startup which > > could be effectively serialised through the lock. > [...] > > [1]: https://lore.kernel.org/r/874ke7z3ng.wl-maz%40kernel.org > > Start-up, VM resume, migration could be affected by this lock, basically > any time you fault a page into the guest. As you said, for now it should > be fine as long as the hardware doesn't support MTE or qemu doesn't > enable MTE in guests. But the problem won't go away. Indeed. And I find it odd to say "it's not a problem, we don't have any HW available". By this token, why should we merge this work the first place, or any of the MTE work that has gone into the kernel over the past years? > We have a partial solution with an array of locks to mitigate against > this but there's still the question of whether we should actually bother > for something that's unlikely to happen in practice: MAP_SHARED memory > in guests (ignoring the stage 1 case for now). > > If MAP_SHARED in guests is not a realistic use-case, we have the vma in > user_mem_abort() and if the VM_SHARED flag is set together with MTE > enabled for guests, we can reject the mapping. That's a reasonable approach. I wonder whether we could do that right at the point where the memslot is associated with the VM, like this: diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c index a36a2e3082d8..ebd3b3224386 100644 --- a/arch/arm64/kvm/mmu.c +++ b/arch/arm64/kvm/mmu.c @@ -1376,6 +1376,9 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm, if (!vma) break; + if (kvm_has_mte(kvm) && vma->vm_flags & VM_SHARED) + return -EINVAL; + /* * Take the intersection of this VMA with the memory region */ which takes the problem out of the fault path altogether? We document the restriction and move on. With that, we can use a non-locking version of mte_sync_page_tags(). > We can discuss the stage 1 case separately from this series. Works for me. Thanks, M. -- 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 X-Spam-Level: X-Spam-Status: No, score=-9.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 99A97C2B9F4 for ; Thu, 17 Jun 2021 13:16:57 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 4CDCB6100B for ; Thu, 17 Jun 2021 13:16:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4CDCB6100B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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=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=PZO/aqLGWj/5IkRhKRm+eaEtcEjSq7Qk+Zlk1lIdRwI=; b=VQa+sz1AWjgZ27 Lw9ubfQWyW8vkUq5WVRf/pn+70JgpBGP9oQhKiGYDtyrcut3VDao4CeBjPsQ/x/46SUPa9BI0v9nF Bh3ke3IlTwchV2M25FYJdOhpDlntfrZr3PTbTi/AQ9TBsKJQOh1vLMC9QI69VVyXin7/3pzm66LaC ZF375gqs+zDTmtpB9W/3sa3RxxZmXeFtehPa6kCMp59biZ+TY/pR97KGxMMGqs2NJGZavaOVfSBBC rjO7h29lTBWoyV6eJW7qbsOnPiVYE+4bCaBzfUysYjvKLrsCYCKsIXjhx4Ka75Pt+Aatmx4+1hSB6 /Q+8w9Ynutc6xF5SYQeg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ltrrp-00AQMq-9I; Thu, 17 Jun 2021 13:15:33 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ltrri-00AQLG-QK for linux-arm-kernel@lists.infradead.org; Thu, 17 Jun 2021 13:15:31 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7B4F76100B; Thu, 17 Jun 2021 13:15:26 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ltrrg-008BNM-Kj; Thu, 17 Jun 2021 14:15:24 +0100 Date: Thu, 17 Jun 2021 14:15:24 +0100 Message-ID: <87im2cd443.wl-maz@kernel.org> From: Marc Zyngier To: Catalin Marinas Cc: Steven Price , 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 Subject: Re: [PATCH v15 0/7] MTE support for KVM guest In-Reply-To: <20210617121322.GC6314@arm.com> References: <20210614090525.4338-1-steven.price@arm.com> <20210617121322.GC6314@arm.com> 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 (x86_64-pc-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: catalin.marinas@arm.com, steven.price@arm.com, will@kernel.org, james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Dave.Martin@arm.com, mark.rutland@arm.com, tglx@linutronix.de, qemu-devel@nongnu.org, quintela@redhat.com, dgilbert@redhat.com, richard.henderson@linaro.org, peter.maydell@linaro.org, Haibo.Xu@arm.com, drjones@redhat.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-20210617_061526_927913_5E2CF85B X-CRM114-Status: GOOD ( 34.30 ) 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 Thu, 17 Jun 2021 13:13:22 +0100, Catalin Marinas wrote: > > On Mon, Jun 14, 2021 at 10:05:18AM +0100, Steven Price wrote: > > I realise there are still open questions[1] around the performance of > > this series (the 'big lock', tag_sync_lock, introduced in the first > > patch). But there should be no impact on non-MTE workloads and until we > > get real MTE-enabled hardware it's hard to know whether there is a need > > for something more sophisticated or not. Peter Collingbourne's patch[3] > > to clear the tags at page allocation time should hide more of the impact > > for non-VM cases. So the remaining concern is around VM startup which > > could be effectively serialised through the lock. > [...] > > [1]: https://lore.kernel.org/r/874ke7z3ng.wl-maz%40kernel.org > > Start-up, VM resume, migration could be affected by this lock, basically > any time you fault a page into the guest. As you said, for now it should > be fine as long as the hardware doesn't support MTE or qemu doesn't > enable MTE in guests. But the problem won't go away. Indeed. And I find it odd to say "it's not a problem, we don't have any HW available". By this token, why should we merge this work the first place, or any of the MTE work that has gone into the kernel over the past years? > We have a partial solution with an array of locks to mitigate against > this but there's still the question of whether we should actually bother > for something that's unlikely to happen in practice: MAP_SHARED memory > in guests (ignoring the stage 1 case for now). > > If MAP_SHARED in guests is not a realistic use-case, we have the vma in > user_mem_abort() and if the VM_SHARED flag is set together with MTE > enabled for guests, we can reject the mapping. That's a reasonable approach. I wonder whether we could do that right at the point where the memslot is associated with the VM, like this: diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c index a36a2e3082d8..ebd3b3224386 100644 --- a/arch/arm64/kvm/mmu.c +++ b/arch/arm64/kvm/mmu.c @@ -1376,6 +1376,9 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm, if (!vma) break; + if (kvm_has_mte(kvm) && vma->vm_flags & VM_SHARED) + return -EINVAL; + /* * Take the intersection of this VMA with the memory region */ which takes the problem out of the fault path altogether? We document the restriction and move on. With that, we can use a non-locking version of mte_sync_page_tags(). > We can discuss the stage 1 case separately from this series. Works for me. Thanks, M. -- 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 X-Spam-Level: X-Spam-Status: No, score=-9.0 required=3.0 tests=BAYES_00,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 7109DC49361 for ; Thu, 17 Jun 2021 13:15:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4E992613BA for ; Thu, 17 Jun 2021 13:15:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232200AbhFQNRe (ORCPT ); Thu, 17 Jun 2021 09:17:34 -0400 Received: from mail.kernel.org ([198.145.29.99]:56256 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231224AbhFQNRe (ORCPT ); Thu, 17 Jun 2021 09:17:34 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7B4F76100B; Thu, 17 Jun 2021 13:15:26 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ltrrg-008BNM-Kj; Thu, 17 Jun 2021 14:15:24 +0100 Date: Thu, 17 Jun 2021 14:15:24 +0100 Message-ID: <87im2cd443.wl-maz@kernel.org> From: Marc Zyngier To: Catalin Marinas Cc: Steven Price , 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 Subject: Re: [PATCH v15 0/7] MTE support for KVM guest In-Reply-To: <20210617121322.GC6314@arm.com> References: <20210614090525.4338-1-steven.price@arm.com> <20210617121322.GC6314@arm.com> 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 (x86_64-pc-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: catalin.marinas@arm.com, steven.price@arm.com, will@kernel.org, james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Dave.Martin@arm.com, mark.rutland@arm.com, tglx@linutronix.de, qemu-devel@nongnu.org, quintela@redhat.com, dgilbert@redhat.com, richard.henderson@linaro.org, peter.maydell@linaro.org, Haibo.Xu@arm.com, drjones@redhat.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: linux-kernel@vger.kernel.org On Thu, 17 Jun 2021 13:13:22 +0100, Catalin Marinas wrote: > > On Mon, Jun 14, 2021 at 10:05:18AM +0100, Steven Price wrote: > > I realise there are still open questions[1] around the performance of > > this series (the 'big lock', tag_sync_lock, introduced in the first > > patch). But there should be no impact on non-MTE workloads and until we > > get real MTE-enabled hardware it's hard to know whether there is a need > > for something more sophisticated or not. Peter Collingbourne's patch[3] > > to clear the tags at page allocation time should hide more of the impact > > for non-VM cases. So the remaining concern is around VM startup which > > could be effectively serialised through the lock. > [...] > > [1]: https://lore.kernel.org/r/874ke7z3ng.wl-maz%40kernel.org > > Start-up, VM resume, migration could be affected by this lock, basically > any time you fault a page into the guest. As you said, for now it should > be fine as long as the hardware doesn't support MTE or qemu doesn't > enable MTE in guests. But the problem won't go away. Indeed. And I find it odd to say "it's not a problem, we don't have any HW available". By this token, why should we merge this work the first place, or any of the MTE work that has gone into the kernel over the past years? > We have a partial solution with an array of locks to mitigate against > this but there's still the question of whether we should actually bother > for something that's unlikely to happen in practice: MAP_SHARED memory > in guests (ignoring the stage 1 case for now). > > If MAP_SHARED in guests is not a realistic use-case, we have the vma in > user_mem_abort() and if the VM_SHARED flag is set together with MTE > enabled for guests, we can reject the mapping. That's a reasonable approach. I wonder whether we could do that right at the point where the memslot is associated with the VM, like this: diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c index a36a2e3082d8..ebd3b3224386 100644 --- a/arch/arm64/kvm/mmu.c +++ b/arch/arm64/kvm/mmu.c @@ -1376,6 +1376,9 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm, if (!vma) break; + if (kvm_has_mte(kvm) && vma->vm_flags & VM_SHARED) + return -EINVAL; + /* * Take the intersection of this VMA with the memory region */ which takes the problem out of the fault path altogether? We document the restriction and move on. With that, we can use a non-locking version of mte_sync_page_tags(). > We can discuss the stage 1 case separately from this series. Works for me. Thanks, M. -- Without deviation from the norm, progress is not possible. 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=-9.0 required=3.0 tests=BAYES_00,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 E9BFCC2B9F4 for ; Thu, 17 Jun 2021 13:25:52 +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 A66A06112D for ; Thu, 17 Jun 2021 13:25:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A66A06112D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:43656 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lts1n-0003ZD-Qd for qemu-devel@archiver.kernel.org; Thu, 17 Jun 2021 09:25:51 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45936) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ltrrn-0006Jh-TH for qemu-devel@nongnu.org; Thu, 17 Jun 2021 09:15:31 -0400 Received: from mail.kernel.org ([198.145.29.99]:44958) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ltrrk-0002pw-SQ for qemu-devel@nongnu.org; Thu, 17 Jun 2021 09:15:31 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7B4F76100B; Thu, 17 Jun 2021 13:15:26 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ltrrg-008BNM-Kj; Thu, 17 Jun 2021 14:15:24 +0100 Date: Thu, 17 Jun 2021 14:15:24 +0100 Message-ID: <87im2cd443.wl-maz@kernel.org> From: Marc Zyngier To: Catalin Marinas Subject: Re: [PATCH v15 0/7] MTE support for KVM guest In-Reply-To: <20210617121322.GC6314@arm.com> References: <20210614090525.4338-1-steven.price@arm.com> <20210617121322.GC6314@arm.com> 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 (x86_64-pc-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: catalin.marinas@arm.com, steven.price@arm.com, will@kernel.org, james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Dave.Martin@arm.com, mark.rutland@arm.com, tglx@linutronix.de, qemu-devel@nongnu.org, quintela@redhat.com, dgilbert@redhat.com, richard.henderson@linaro.org, peter.maydell@linaro.org, Haibo.Xu@arm.com, drjones@redhat.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Received-SPF: pass client-ip=198.145.29.99; envelope-from=maz@kernel.org; helo=mail.kernel.org X-Spam_score_int: -68 X-Spam_score: -6.9 X-Spam_bar: ------ X-Spam_report: (-6.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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, Dave Martin , Juan Quintela , Richard Henderson , linux-kernel@vger.kernel.org, Steven Price , 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 Thu, 17 Jun 2021 13:13:22 +0100, Catalin Marinas wrote: > > On Mon, Jun 14, 2021 at 10:05:18AM +0100, Steven Price wrote: > > I realise there are still open questions[1] around the performance of > > this series (the 'big lock', tag_sync_lock, introduced in the first > > patch). But there should be no impact on non-MTE workloads and until we > > get real MTE-enabled hardware it's hard to know whether there is a need > > for something more sophisticated or not. Peter Collingbourne's patch[3] > > to clear the tags at page allocation time should hide more of the impact > > for non-VM cases. So the remaining concern is around VM startup which > > could be effectively serialised through the lock. > [...] > > [1]: https://lore.kernel.org/r/874ke7z3ng.wl-maz%40kernel.org > > Start-up, VM resume, migration could be affected by this lock, basically > any time you fault a page into the guest. As you said, for now it should > be fine as long as the hardware doesn't support MTE or qemu doesn't > enable MTE in guests. But the problem won't go away. Indeed. And I find it odd to say "it's not a problem, we don't have any HW available". By this token, why should we merge this work the first place, or any of the MTE work that has gone into the kernel over the past years? > We have a partial solution with an array of locks to mitigate against > this but there's still the question of whether we should actually bother > for something that's unlikely to happen in practice: MAP_SHARED memory > in guests (ignoring the stage 1 case for now). > > If MAP_SHARED in guests is not a realistic use-case, we have the vma in > user_mem_abort() and if the VM_SHARED flag is set together with MTE > enabled for guests, we can reject the mapping. That's a reasonable approach. I wonder whether we could do that right at the point where the memslot is associated with the VM, like this: diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c index a36a2e3082d8..ebd3b3224386 100644 --- a/arch/arm64/kvm/mmu.c +++ b/arch/arm64/kvm/mmu.c @@ -1376,6 +1376,9 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm, if (!vma) break; + if (kvm_has_mte(kvm) && vma->vm_flags & VM_SHARED) + return -EINVAL; + /* * Take the intersection of this VMA with the memory region */ which takes the problem out of the fault path altogether? We document the restriction and move on. With that, we can use a non-locking version of mte_sync_page_tags(). > We can discuss the stage 1 case separately from this series. Works for me. Thanks, M. -- Without deviation from the norm, progress is not possible.