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=-14.0 required=3.0 tests=BAYES_00,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 AD5A4C4338F for ; Wed, 28 Jul 2021 11:02:01 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 22FE060FEB for ; Wed, 28 Jul 2021 11:02:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 22FE060FEB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 9CF6E4B099; Wed, 28 Jul 2021 07:02:00 -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 yvGMrLsyzmOk; Wed, 28 Jul 2021 07:01:59 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 6EF194A524; Wed, 28 Jul 2021 07:01:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id CF19A4A319 for ; Wed, 28 Jul 2021 07:01:57 -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 cNuYOisJhNIa for ; Wed, 28 Jul 2021 07:01:56 -0400 (EDT) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id A8B614A195 for ; Wed, 28 Jul 2021 07:01:56 -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 AEBEA60F46; Wed, 28 Jul 2021 11:01:55 +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 1m8hJx-001Vuk-R3; Wed, 28 Jul 2021 12:01:53 +0100 Date: Wed, 28 Jul 2021 12:01:53 +0100 Message-ID: <87tuked7mm.wl-maz@kernel.org> From: Marc Zyngier To: Will Deacon Subject: Re: [PATCH 12/16] mm/ioremap: Add arch-specific callbacks on ioremap/iounmap calls In-Reply-To: <20210727181203.GG19173@willie-the-truck> References: <20210715163159.1480168-1-maz@kernel.org> <20210715163159.1480168-13-maz@kernel.org> <20210727181203.GG19173@willie-the-truck> 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: will@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, qperret@google.com, dbrazdil@google.com, vatsa@codeaurora.org, sdonthineni@nvidia.com, james.morse@arm.com, suzuki.poulose@arm.com, alexandru.elisei@arm.com, kernel-team@android.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, kernel-team@android.com, Srivatsa Vaddagiri , linux-kernel@vger.kernel.org, Shanker R Donthineni , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org 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 Tue, 27 Jul 2021 19:12:04 +0100, Will Deacon wrote: > > On Thu, Jul 15, 2021 at 05:31:55PM +0100, Marc Zyngier wrote: > > Add a pair of hooks (ioremap_page_range_hook/iounmap_page_range_hook) > > that can be implemented by an architecture. > > > > Signed-off-by: Marc Zyngier > > --- > > include/linux/io.h | 3 +++ > > mm/ioremap.c | 13 ++++++++++++- > > mm/vmalloc.c | 8 ++++++++ > > 3 files changed, 23 insertions(+), 1 deletion(-) > > > > diff --git a/include/linux/io.h b/include/linux/io.h > > index 9595151d800d..0ffc265f114c 100644 > > --- a/include/linux/io.h > > +++ b/include/linux/io.h > > @@ -21,6 +21,9 @@ void __ioread32_copy(void *to, const void __iomem *from, size_t count); > > void __iowrite64_copy(void __iomem *to, const void *from, size_t count); > > > > #ifdef CONFIG_MMU > > +void ioremap_page_range_hook(unsigned long addr, unsigned long end, > > + phys_addr_t phys_addr, pgprot_t prot); > > +void iounmap_page_range_hook(phys_addr_t phys_addr, size_t size); > > int ioremap_page_range(unsigned long addr, unsigned long end, > > phys_addr_t phys_addr, pgprot_t prot); > > #else > > Can we avoid these hooks by instead not registering the regions proactively > in the guest and moving that logic to a fault handler which runs off the > back of the injected data abort? From there, we could check if the faulting > IPA is a memory address and register it as MMIO if not. > > Dunno, you've spent more time than me thinking about this, but just > wondering if you'd had a crack at doing it that way, as it _seems_ simpler > to my naive brain. I thought about it, but couldn't work out whether it was always possible for the guest to handle these faults (first access in an interrupt context, for example?). Also, this changes the semantics of the protection this is supposed to offer: any access out of the RAM space will generate an abort, and the fault handler will grant MMIO forwarding for this page. Stray accesses that would normally be properly handled as fatal would now succeed and be forwarded to userspace, even if there was no emulated devices there. For this to work, we'd need to work out whether there is any existing device mapping that actually points to this page. And whether it actually is supposed to be forwarded to userspace. Do we have a rmap for device mappings? 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=-14.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 B2AC3C4338F for ; Wed, 28 Jul 2021 11:03: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 77C6B60F00 for ; Wed, 28 Jul 2021 11:03:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 77C6B60F00 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=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=pj3yRpNSC5/Z2j8l2aIIM3ANE8X9YIOqEt4qvLptWYo=; b=Wdvmkqhgg3pxs2 2lYQbdOY+2scaCcL5xYggwGv3NkPuAQftctv/3CPmx3yZiOgmxxeWYqtKaJbbdYGxAGxanIoPnEGO mRoGdvjvv7jiK7YKq5UKT37WEulmyCQRZZMxOY5tqCBJokEPKIZntLiHATgwfzsbIG3GmvrcH/lVv ZAkLzZIVW/D2+5Yl9HXFk+gfi+zRllg2kY9/JuxZ0UcLtbaOf/lVo6HXdxG/S2KKEOMg26RUTpWNx jQvgq2elsQQnW3tJYTlC6+5MtfxXrQZgms7XwB0hwsJvtM+05nmgXKM1kpMVH+u5Ii7e+krptsMJY DtV7GVxHxWUiHKpoF3Iw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m8hK4-000Uh0-12; Wed, 28 Jul 2021 11:02:00 +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 1m8hJz-000Uft-Tf for linux-arm-kernel@lists.infradead.org; Wed, 28 Jul 2021 11:01:57 +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 AEBEA60F46; Wed, 28 Jul 2021 11:01:55 +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 1m8hJx-001Vuk-R3; Wed, 28 Jul 2021 12:01:53 +0100 Date: Wed, 28 Jul 2021 12:01:53 +0100 Message-ID: <87tuked7mm.wl-maz@kernel.org> From: Marc Zyngier To: Will Deacon Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, qperret@google.com, dbrazdil@google.com, Srivatsa Vaddagiri , Shanker R Donthineni , James Morse , Suzuki K Poulose , Alexandru Elisei , kernel-team@android.com Subject: Re: [PATCH 12/16] mm/ioremap: Add arch-specific callbacks on ioremap/iounmap calls In-Reply-To: <20210727181203.GG19173@willie-the-truck> References: <20210715163159.1480168-1-maz@kernel.org> <20210715163159.1480168-13-maz@kernel.org> <20210727181203.GG19173@willie-the-truck> 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: will@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, qperret@google.com, dbrazdil@google.com, vatsa@codeaurora.org, sdonthineni@nvidia.com, james.morse@arm.com, suzuki.poulose@arm.com, alexandru.elisei@arm.com, kernel-team@android.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-20210728_040156_042714_7D48A3B8 X-CRM114-Status: GOOD ( 31.64 ) 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 Tue, 27 Jul 2021 19:12:04 +0100, Will Deacon wrote: > > On Thu, Jul 15, 2021 at 05:31:55PM +0100, Marc Zyngier wrote: > > Add a pair of hooks (ioremap_page_range_hook/iounmap_page_range_hook) > > that can be implemented by an architecture. > > > > Signed-off-by: Marc Zyngier > > --- > > include/linux/io.h | 3 +++ > > mm/ioremap.c | 13 ++++++++++++- > > mm/vmalloc.c | 8 ++++++++ > > 3 files changed, 23 insertions(+), 1 deletion(-) > > > > diff --git a/include/linux/io.h b/include/linux/io.h > > index 9595151d800d..0ffc265f114c 100644 > > --- a/include/linux/io.h > > +++ b/include/linux/io.h > > @@ -21,6 +21,9 @@ void __ioread32_copy(void *to, const void __iomem *from, size_t count); > > void __iowrite64_copy(void __iomem *to, const void *from, size_t count); > > > > #ifdef CONFIG_MMU > > +void ioremap_page_range_hook(unsigned long addr, unsigned long end, > > + phys_addr_t phys_addr, pgprot_t prot); > > +void iounmap_page_range_hook(phys_addr_t phys_addr, size_t size); > > int ioremap_page_range(unsigned long addr, unsigned long end, > > phys_addr_t phys_addr, pgprot_t prot); > > #else > > Can we avoid these hooks by instead not registering the regions proactively > in the guest and moving that logic to a fault handler which runs off the > back of the injected data abort? From there, we could check if the faulting > IPA is a memory address and register it as MMIO if not. > > Dunno, you've spent more time than me thinking about this, but just > wondering if you'd had a crack at doing it that way, as it _seems_ simpler > to my naive brain. I thought about it, but couldn't work out whether it was always possible for the guest to handle these faults (first access in an interrupt context, for example?). Also, this changes the semantics of the protection this is supposed to offer: any access out of the RAM space will generate an abort, and the fault handler will grant MMIO forwarding for this page. Stray accesses that would normally be properly handled as fatal would now succeed and be forwarded to userspace, even if there was no emulated devices there. For this to work, we'd need to work out whether there is any existing device mapping that actually points to this page. And whether it actually is supposed to be forwarded to userspace. Do we have a rmap for device mappings? 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=-14.0 required=3.0 tests=BAYES_00,INCLUDES_CR_TRAILER, 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 5D694C4338F for ; Wed, 28 Jul 2021 11:01:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3743860F00 for ; Wed, 28 Jul 2021 11:01:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235781AbhG1LB6 (ORCPT ); Wed, 28 Jul 2021 07:01:58 -0400 Received: from mail.kernel.org ([198.145.29.99]:57230 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234181AbhG1LB4 (ORCPT ); Wed, 28 Jul 2021 07:01:56 -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 AEBEA60F46; Wed, 28 Jul 2021 11:01:55 +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 1m8hJx-001Vuk-R3; Wed, 28 Jul 2021 12:01:53 +0100 Date: Wed, 28 Jul 2021 12:01:53 +0100 Message-ID: <87tuked7mm.wl-maz@kernel.org> From: Marc Zyngier To: Will Deacon Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, qperret@google.com, dbrazdil@google.com, Srivatsa Vaddagiri , Shanker R Donthineni , James Morse , Suzuki K Poulose , Alexandru Elisei , kernel-team@android.com Subject: Re: [PATCH 12/16] mm/ioremap: Add arch-specific callbacks on ioremap/iounmap calls In-Reply-To: <20210727181203.GG19173@willie-the-truck> References: <20210715163159.1480168-1-maz@kernel.org> <20210715163159.1480168-13-maz@kernel.org> <20210727181203.GG19173@willie-the-truck> 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: will@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, qperret@google.com, dbrazdil@google.com, vatsa@codeaurora.org, sdonthineni@nvidia.com, james.morse@arm.com, suzuki.poulose@arm.com, alexandru.elisei@arm.com, kernel-team@android.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 Tue, 27 Jul 2021 19:12:04 +0100, Will Deacon wrote: > > On Thu, Jul 15, 2021 at 05:31:55PM +0100, Marc Zyngier wrote: > > Add a pair of hooks (ioremap_page_range_hook/iounmap_page_range_hook) > > that can be implemented by an architecture. > > > > Signed-off-by: Marc Zyngier > > --- > > include/linux/io.h | 3 +++ > > mm/ioremap.c | 13 ++++++++++++- > > mm/vmalloc.c | 8 ++++++++ > > 3 files changed, 23 insertions(+), 1 deletion(-) > > > > diff --git a/include/linux/io.h b/include/linux/io.h > > index 9595151d800d..0ffc265f114c 100644 > > --- a/include/linux/io.h > > +++ b/include/linux/io.h > > @@ -21,6 +21,9 @@ void __ioread32_copy(void *to, const void __iomem *from, size_t count); > > void __iowrite64_copy(void __iomem *to, const void *from, size_t count); > > > > #ifdef CONFIG_MMU > > +void ioremap_page_range_hook(unsigned long addr, unsigned long end, > > + phys_addr_t phys_addr, pgprot_t prot); > > +void iounmap_page_range_hook(phys_addr_t phys_addr, size_t size); > > int ioremap_page_range(unsigned long addr, unsigned long end, > > phys_addr_t phys_addr, pgprot_t prot); > > #else > > Can we avoid these hooks by instead not registering the regions proactively > in the guest and moving that logic to a fault handler which runs off the > back of the injected data abort? From there, we could check if the faulting > IPA is a memory address and register it as MMIO if not. > > Dunno, you've spent more time than me thinking about this, but just > wondering if you'd had a crack at doing it that way, as it _seems_ simpler > to my naive brain. I thought about it, but couldn't work out whether it was always possible for the guest to handle these faults (first access in an interrupt context, for example?). Also, this changes the semantics of the protection this is supposed to offer: any access out of the RAM space will generate an abort, and the fault handler will grant MMIO forwarding for this page. Stray accesses that would normally be properly handled as fatal would now succeed and be forwarded to userspace, even if there was no emulated devices there. For this to work, we'd need to work out whether there is any existing device mapping that actually points to this page. And whether it actually is supposed to be forwarded to userspace. Do we have a rmap for device mappings? M. -- Without deviation from the norm, progress is not possible.