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 5B2A3C5321D for ; Mon, 26 Aug 2024 10:03:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=S8YX+EFODVA7sRprEAND/dInr6tPpiN2jkkEKQK/ZVY=; b=3hr/p84pZNOFkBOc0DusUpX9eZ at90ktJtlMZBKA7sMLnyIK0fwZUDNUVRGLDYmYgrV9siGD2dCtTUr82sSLBt6soX/g1l6HIBZhJ2A nbDoQSvdwR+qUuimlU6prqcz36FEBjvl7DpWYc7AKKbN9OJv/L06K3N9kvEmhhetfvrFgAG1z7AMT zrdhI6jkMToWaJ3pgpXol4tfyib3DDVdhmoApR6XacgtPzcc1kj4AJ8cxL0AuoFA3eqwMNqwPmsK6 wyyGXpOi0Xs3zwhS7I9Oy/9p3/pnd5YESZgYAC+JtQIrqt3ex32gOznb2D0c4Hg+P/5+nMoWq8dGH avU0tKfg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1siWZ5-00000006pcy-2LRP; Mon, 26 Aug 2024 10:03:11 +0000 Received: from nyc.source.kernel.org ([147.75.193.91]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1siWXO-00000006p8Z-1Y7x for linux-arm-kernel@lists.infradead.org; Mon, 26 Aug 2024 10:01:28 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 6F87EA4212D; Mon, 26 Aug 2024 10:01:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B9CCEC51407; Mon, 26 Aug 2024 10:01:20 +0000 (UTC) Date: Mon, 26 Aug 2024 13:01:29 +0300 From: Catalin Marinas To: Steven Price Cc: kvm@vger.kernel.org, kvmarm@lists.linux.dev, Marc Zyngier , Will Deacon , James Morse , Oliver Upton , Suzuki K Poulose , Zenghui Yu , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Joey Gouly , Alexandru Elisei , Christoffer Dall , Fuad Tabba , linux-coco@lists.linux.dev, Ganapatrao Kulkarni , Gavin Shan , Shanker Donthineni , Alper Gun Subject: Re: [PATCH v5 02/19] arm64: mm: Add confidential computing hook to ioremap_prot() Message-ID: References: <20240819131924.372366-1-steven.price@arm.com> <20240819131924.372366-3-steven.price@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240819131924.372366-3-steven.price@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240826_030126_816041_10675B85 X-CRM114-Status: GOOD ( 24.89 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Aug 19, 2024 at 02:19:07PM +0100, Steven Price wrote: > From: Will Deacon > > Confidential Computing environments such as pKVM and Arm's CCA > distinguish between shared (i.e. emulated) and private (i.e. assigned) > MMIO regions. > > Introduce a hook into our implementation of ioremap_prot() so that MMIO > regions can be shared if necessary. > > Signed-off-by: Will Deacon > Signed-off-by: Steven Price > --- > Patch 'borrowed' from Will's series for pKVM: > https://lore.kernel.org/r/20240730151113.1497-6-will%40kernel.org > --- > arch/arm64/include/asm/io.h | 4 ++++ > arch/arm64/mm/ioremap.c | 23 ++++++++++++++++++++++- > 2 files changed, 26 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h > index 41fd90895dfc..1ada23a6ec19 100644 > --- a/arch/arm64/include/asm/io.h > +++ b/arch/arm64/include/asm/io.h > @@ -271,6 +271,10 @@ __iowrite64_copy(void __iomem *to, const void *from, size_t count) > * I/O memory mapping functions. > */ > > +typedef int (*ioremap_prot_hook_t)(phys_addr_t phys_addr, size_t size, > + pgprot_t *prot); > +int arm64_ioremap_prot_hook_register(const ioremap_prot_hook_t hook); > + > #define ioremap_prot ioremap_prot > > #define _PAGE_IOREMAP PROT_DEVICE_nGnRE > diff --git a/arch/arm64/mm/ioremap.c b/arch/arm64/mm/ioremap.c > index 269f2f63ab7d..6cc0b7e7eb03 100644 > --- a/arch/arm64/mm/ioremap.c > +++ b/arch/arm64/mm/ioremap.c > @@ -3,10 +3,22 @@ > #include > #include > > +static ioremap_prot_hook_t ioremap_prot_hook; > + > +int arm64_ioremap_prot_hook_register(ioremap_prot_hook_t hook) > +{ > + if (WARN_ON(ioremap_prot_hook)) > + return -EBUSY; > + > + ioremap_prot_hook = hook; > + return 0; > +} > + > void __iomem *ioremap_prot(phys_addr_t phys_addr, size_t size, > unsigned long prot) > { > unsigned long last_addr = phys_addr + size - 1; > + pgprot_t pgprot = __pgprot(prot); > > /* Don't allow outside PHYS_MASK */ > if (last_addr & ~PHYS_MASK) > @@ -16,7 +28,16 @@ void __iomem *ioremap_prot(phys_addr_t phys_addr, size_t size, > if (WARN_ON(pfn_is_map_memory(__phys_to_pfn(phys_addr)))) > return NULL; > > - return generic_ioremap_prot(phys_addr, size, __pgprot(prot)); > + /* > + * If a hook is registered (e.g. for confidential computing > + * purposes), call that now and barf if it fails. > + */ > + if (unlikely(ioremap_prot_hook) && > + WARN_ON(ioremap_prot_hook(phys_addr, size, &pgprot))) { > + return NULL; > + } > + > + return generic_ioremap_prot(phys_addr, size, pgprot); > } > EXPORT_SYMBOL(ioremap_prot); I should have commented on Will's original series since it's more likely to affect pKVM than CCA. Anyway, this is all good with the hook, especially if the guest needs to do some paravirtual call. However, we have other instances of mapping I/O memory without going through ioremap() - io_remap_pfn_range() which uses pgprot_decrypted(). We'll need some hooks there as well. And I think there are a few other cases of pgprot_decrypted() but we can fix them on a case by case bases (e.g. routing them through io_remap_pfn_range()). For this patch: Reviewed-by: Catalin Marinas