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 0109FC43458 for ; Mon, 6 Jul 2026 13:42:35 +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: Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From: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=gXQkycuyZrdfubY+a8etURqHKk4IqlvevFVov045YPE=; b=eUG4WUordarABfH/xIhCiWRl+k 9N3X10A1jqXkDJYBDPr4jErFW2GDDQmTKb4Agw1cqXyVS4rjYzM+V+nfV72LDI2ndR/bSDSESm5GL TKImZjZWvrv/sWBjdyZkOjALMHvsmMzGY50Vym6K2mHok1bgd56hXg+xcqlqKo9ZBRV6wdJHKDruG VjIQKJOtnxK9L2oC6F3kutsEtxuRrM6SFlzLLjm2S+hx9Ft1ZykBoStU+gSNYJOGVB6TJTDCC+JYT pS28ZWney9iFDTWleEN4V285MQ6Y/OuwwAvLWSGl9cyTs900fl0OZcwhx1kH6rlBoC3RMjh1eH3MT 8McaqlFQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wgjaf-0000000Cd86-3O0J; Mon, 06 Jul 2026 13:42:29 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wgjaf-0000000Cd7x-0xdm for linux-arm-kernel@lists.infradead.org; Mon, 06 Jul 2026 13:42:29 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 7FAE442E4D; Mon, 6 Jul 2026 13:42:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 37CE11F000E9; Mon, 6 Jul 2026 13:42:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783345348; bh=gXQkycuyZrdfubY+a8etURqHKk4IqlvevFVov045YPE=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=MyTUEFo+V8Urr2g/vi7rndXCyW+0VLn2hck1DNdkKhva7mSObnt3GYs6H3d1v3hK2 1TEFyhfmmbXArlLTvIQhrsqFCwqyADwS+LVYNQ6G2RN7xDV96Hgd1pKXP/BOR0qEY6 YIVYXs3JBwYYR5wjRxTrhFGO6SlfmE/XW880EnxFSxulA3EzvwnoyGuQS4G7OwJlmU tE3cwfhh4IxggHX4IMOWUIWlcOf/88vGjd6IlfgFYkaD8pYIBT3VuvHANC8OLDoHIA k0BAKkE0+1fxXVDXVUMFu0kRSY3YlZ4x0Ca+73lDkNDaDGsrE54C4a3ECtbhgV9uen Bzo4jyQVdJExA== X-Mailer: emacs 30.2 (via feedmail 11-beta-1 I) From: Aneesh Kumar K.V To: Marc Zyngier Cc: linux-coco@lists.linux.dev, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, iommu@lists.linux.dev, Catalin Marinas , Jason Gunthorpe , Marek Szyprowski , Robin Murphy , Steven Price , Suzuki K Poulose , Thomas Gleixner , Will Deacon Subject: Re: [PATCH v5 02/10] irqchip/gic-v3-its: Align shared ITS allocations to the CoCo shared granule size In-Reply-To: <86ik6sp7fc.wl-maz@kernel.org> References: <20260706060432.1375570-1-aneesh.kumar@kernel.org> <20260706060432.1375570-3-aneesh.kumar@kernel.org> <86ik6sp7fc.wl-maz@kernel.org> Date: Mon, 06 Jul 2026 19:12:17 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain 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 Marc Zyngier writes: > On Mon, 06 Jul 2026 07:04:24 +0100, > "Aneesh Kumar K.V (Arm)" wrote: >> >> ITS tables allocated by the coco guest are shared with the hypervisor. >> These allocations must satisfy the host shared-buffer granule size so that >> the full converted range is safe for host access. >> >> Allocate ITS pages using a size rounded up to the shared granule size and >> use the same allocation order when encrypting, decrypting and freeing the >> memory. Also grow the ITT cache in shared-granule sized chunks instead of >> assuming PAGE_SIZE is sufficient. >> >> Signed-off-by: Aneesh Kumar K.V (Arm) >> --- >> drivers/irqchip/irq-gic-v3-its.c | 17 +++++++++++------ >> 1 file changed, 11 insertions(+), 6 deletions(-) >> >> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c >> index b57d81ad33a0..5d6d38aa0dae 100644 >> --- a/drivers/irqchip/irq-gic-v3-its.c >> +++ b/drivers/irqchip/irq-gic-v3-its.c >> @@ -213,16 +213,17 @@ static gfp_t gfp_flags_quirk; >> static struct page *its_alloc_pages_node(int node, gfp_t gfp, >> unsigned int order) >> { >> + unsigned int alloc_order; >> struct page *page; >> int ret = 0; >> >> - page = alloc_pages_node(node, gfp | gfp_flags_quirk, order); >> - >> + alloc_order = get_order(mem_cc_align_to_shared_granule(PAGE_SIZE << order)); >> + page = alloc_pages_node(node, gfp | gfp_flags_quirk, alloc_order); >> if (!page) >> return NULL; >> >> ret = set_memory_decrypted((unsigned long)page_address(page), >> - 1 << order); >> + 1 << alloc_order); >> /* >> * If set_memory_decrypted() fails then we don't know what state the >> * page is in, so we can't free it. Instead we leak it. >> @@ -241,13 +242,16 @@ static struct page *its_alloc_pages(gfp_t gfp, unsigned int order) >> >> static void its_free_pages(void *addr, unsigned int order) >> { >> + int alloc_order; >> + >> + alloc_order = get_order(mem_cc_align_to_shared_granule(PAGE_SIZE << order)); >> /* >> * If the memory cannot be encrypted again then we must leak the pages. >> * set_memory_encrypted() will already have WARNed. >> */ >> - if (set_memory_encrypted((unsigned long)addr, 1 << order)) >> + if (set_memory_encrypted((unsigned long)addr, 1 << alloc_order)) >> return; >> - free_pages((unsigned long)addr, order); >> + free_pages((unsigned long)addr, alloc_order); > > The comments I had in [1] are still applicable. > > M. > > [1] https://lore.kernel.org/all/86zf2ozrb8.wl-maz@kernel.org/ > I renamed it to alloc_order to make it clear that it refers to the allocation order rather than the requested order. If you feel strongly about not introducing another variable, I'll drop the new variable. -aneesh