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 E3716C52D7C for ; Mon, 19 Aug 2024 22:20:52 +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-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=F5qppWnolOwARZ++xR7NgWexyLgbdJXoUlszvMvWY7U=; b=0W1owlc2KwD3oSg2mXML4FhTqh G7kVIqbTJj/hU0PT7NmOru/H5pdyS3IgbTVK8z5vEnBXMGTwUla8tOI2LOtvPz1vwwIn03sd464Wy lYP/5eW2oY/zr/zrPF11rWyZjv6uEqgHEW37yWrD7oVlKAsPrsUrzAE3PSKsf4cVoxQvSRO2x0EyD 4b05djfMrXuCWa+PG22v+gNbSP/83d/nWY0wKj0xdmvOrtRQIZq0aeUjWFgawqLopKOqzmX/r465P hQKrHrRO1oDdFkO78/Dt8UCsqYFQWz+glwYxymwXCh+OrTVDXzLuikCN6Vz2BIUT/9faDHFQ1f3St cD3UOJ3A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sgAjw-000000035nL-1kEQ; Mon, 19 Aug 2024 22:20:40 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sgAjF-000000035ge-2F2Q for linux-arm-kernel@lists.infradead.org; Mon, 19 Aug 2024 22:19:59 +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 1B1A6339; Mon, 19 Aug 2024 15:20:22 -0700 (PDT) Received: from [10.57.70.210] (unknown [10.57.70.210]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 02B683F58B; Mon, 19 Aug 2024 15:19:52 -0700 (PDT) Message-ID: Date: Mon, 19 Aug 2024 23:19:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 17/19] irqchip/gic-v3-its: Share ITS tables with a non-trusted hypervisor Content-Language: en-GB To: Marc Zyngier 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 References: <20240819131924.372366-1-steven.price@arm.com> <20240819131924.372366-18-steven.price@arm.com> <86y14sy1qo.wl-maz@kernel.org> From: Suzuki K Poulose In-Reply-To: <86y14sy1qo.wl-maz@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240819_151957_849235_027D6FF2 X-CRM114-Status: GOOD ( 31.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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Marc On 19/08/2024 16:24, Marc Zyngier wrote: > 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? No, but it may be emulated in the Realm World (by a higher privileged component, with future RMM versions with Planes - Plane0) and this "Realm guest" may run in a lesser privileged plane and must use "protected" accesses to make sure the accesses are seen by the "Realm world" emulator. > > [...] > >> 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? We expect that, the GIC as a whole is either Realm or non-secure, but not split (like most of the devices). The only reason for using rdists is because thats shared and available with the ITS driver code. (and was an easy hack). Happy to change this to something better. > >> 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. Agreed and that is exactly we would like. i.e., treat the GIC as either Realm or NS (as a whole). Now, how do we make that decision is based on whether GIC Distributor area is private or not. Like I mentioned above, we need a cleaner way of making this available in the ITS driver. Thoughts ? Is that what you were hinting at ? Suzuki > Thanks, > > M. >