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 BC263C3DA4A for ; Mon, 19 Aug 2024 15:25: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:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID: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=B5i+0gdsnEEGhT1WaweDh8IgWcZhjaBL07AYF4/JgrI=; b=KxnUG2SanaIHIfg3aDl/3q57g5 jneWp1zGlRNLpdZR/bLNxzyxVarx2/IIuGeOzJ0RvlICBZ5JkKqlngS1Ukb8xJhqlBAzLEruTIx70 IVQiI0zue5V6ao+VszQOr+q2qFCN2eIYlnVhFa+F4MiAIp0SIvzKR7AoluAgVY8cnEa2oJNNofdDO Q9L6D4QwvcD38ruotbyT2w9oc48ACfEzv1DMmitKnM39CU9Lsb39Wqwbo6z8YbpUFSLaCpekHRuWB C2EPSfwgC3xl0PZhwWHmQjDPQO4chLetitohoCoxqOcTJKnLa7NwyzqJC4c+xVKMiMe0197VK1p35 jxvxgqsg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sg4Fy-00000001vpS-1qPW; Mon, 19 Aug 2024 15:25:18 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sg4FI-00000001vgB-14ZD for linux-arm-kernel@lists.infradead.org; Mon, 19 Aug 2024 15:24:37 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 94BDF6068F; Mon, 19 Aug 2024 15:24:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 452CDC32782; Mon, 19 Aug 2024 15:24:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724081075; bh=9SrzYFYWu8XTyOkpWU8KfwdY1kOQ4PufChUBufGqjQE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=S1r/cj+i/j/Y2h9GHVksnTVsgr0Hom/4Ghqr8HlW9/MjECmiL9CrjkDqewI30ufe4 zqOEXKMR3jOOliR7XDYljdxoAvJaP4GAEzSr8vwSUyTKI8xwLag5JS6DS37NEUZ49h 60Q5L8hpFVCnRUenuNnyBHgV3bRvbWdh2qmN9XAuC3mE5WI8DvvGXiDlkNwHeQENUb YYYaTKgl5jF0zwwJYSyhqDubEcElzPSYGJt9FS0BoaBxWzeLabsXM3DpOllyyFYRVN lvHlppSzmYo+tsiaYVRRvpMvJVKZdSwibA8GGoprSXEOC6Kn4f67pKfiSAGKKPoBhJ jdkJpuBp1a6Sg== 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 1sg4FE-004y1j-OU; Mon, 19 Aug 2024 16:24:32 +0100 Date: Mon, 19 Aug 2024 16:24:31 +0100 Message-ID: <86y14sy1qo.wl-maz@kernel.org> From: Marc Zyngier To: Suzuki K Poulose Cc: Steven Price , kvm@vger.kernel.org, kvmarm@lists.linux.dev, Catalin Marinas , Will Deacon , James Morse , Oliver Upton , 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 17/19] irqchip/gic-v3-its: Share ITS tables with a non-trusted hypervisor In-Reply-To: References: <20240819131924.372366-1-steven.price@arm.com> <20240819131924.372366-18-steven.price@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/29.4 (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: suzuki.poulose@arm.com, steven.price@arm.com, kvm@vger.kernel.org, kvmarm@lists.linux.dev, catalin.marinas@arm.com, will@kernel.org, james.morse@arm.com, oliver.upton@linux.dev, yuzenghui@huawei.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, joey.gouly@arm.com, alexandru.elisei@arm.com, christoffer.dall@arm.com, tabba@google.com, linux-coco@lists.linux.dev, gankulkarni@os.amperecomputing.com, gshan@redhat.com, sdonthineni@nvidia.com, alpergun@google.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-20240819_082436_425255_6A4D71A5 X-CRM114-Status: GOOD ( 36.40 ) 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, 19 Aug 2024 15:51:00 +0100, Suzuki K Poulose wrote: > > Hi Steven, > > On 19/08/2024 14:19, Steven Price wrote: > > Within a realm guest the ITS is emulated by the host. This means the > > allocations must have been made available to the host by a call to > > set_memory_decrypted(). Introduce an allocation function which performs > > this extra call. > > > > For the ITT use a custom genpool-based allocator that calls > > set_memory_decrypted() for each page allocated, but then suballocates > > the size needed for each ITT. Note that there is no mechanism > > implemented to return pages from the genpool, but it is unlikely the > > peak number of devices will so much larger than the normal level - so > > this isn't expected to be an issue. > > > > This may not be sufficient to make it future proof. We need to detect if > the GIC is private vs shared, before we make the allocation > choice. Please see below : What do you mean by that? Do you foresee a *GICv3* implementation on the realm side? [...] > How about something like this folded into this patch ? Or if this > patch goes in independently, we could carry the following as part of > the CCA > series. > > diff --git a/drivers/irqchip/irq-gic-v3-its.c > b/drivers/irqchip/irq-gic-v3-its.c > index 6f4ddf7faed1..f1a779b52210 100644 > --- a/drivers/irqchip/irq-gic-v3-its.c > +++ b/drivers/irqchip/irq-gic-v3-its.c > @@ -209,7 +209,7 @@ static struct page *its_alloc_pages_node(int node, > gfp_t gfp, > > page = alloc_pages_node(node, gfp, order); > > - if (page) > + if (gic_rdists->is_shared && page) > set_memory_decrypted((unsigned long)page_address(page), > BIT(order)); > return page; > @@ -222,7 +222,8 @@ static struct page *its_alloc_pages(gfp_t gfp, > unsigned int order) > > static void its_free_pages(void *addr, unsigned int order) > { > - set_memory_encrypted((unsigned long)addr, BIT(order)); > + if (gic_rdists->is_shared) > + set_memory_encrypted((unsigned long)addr, BIT(order)); > free_pages((unsigned long)addr, order); > } > > diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c > index 6fb276504bcc..48c6b2c8dd8c 100644 > --- a/drivers/irqchip/irq-gic-v3.c > +++ b/drivers/irqchip/irq-gic-v3.c > @@ -2015,6 +2015,8 @@ static int __init gic_init_bases(phys_addr_t > dist_phys_base, > typer = readl_relaxed(gic_data.dist_base + GICD_TYPER); > gic_data.rdists.gicd_typer = typer; > > + gic_data.rdists.is_shared = > !arm64_is_iomem_private(gic_data.dist_phys_base, > + PAGE_SIZE); Why would you base the status of the RDs on that of the distributor? > gic_enable_quirks(readl_relaxed(gic_data.dist_base + GICD_IIDR), > gic_quirks, &gic_data); > > diff --git a/include/linux/irqchip/arm-gic-v3.h > b/include/linux/irqchip/arm-gic-v3.h > index 728691365464..1edc33608d52 100644 > --- a/include/linux/irqchip/arm-gic-v3.h > +++ b/include/linux/irqchip/arm-gic-v3.h > @@ -631,6 +631,7 @@ struct rdists { > bool has_rvpeid; > bool has_direct_lpi; > bool has_vpend_valid_dirty; > + bool is_shared; > }; > > struct irq_domain; > I really don't like this. If we have to go down the route of identifying whether the GIC needs encryption or not based on the platform, then maybe we should bite the bullet and treat it as a first class device, given that we expect devices to be either realm or non-secure. Thanks, M. -- Without deviation from the norm, progress is not possible.