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=-7.5 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 B9D86C4338F for ; Wed, 25 Aug 2021 14:34:37 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 8B3B1610C8 for ; Wed, 25 Aug 2021 14:34:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8B3B1610C8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id B391F6E247; Wed, 25 Aug 2021 14:34:36 +0000 (UTC) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by gabe.freedesktop.org (Postfix) with ESMTP id 805B36E247 for ; Wed, 25 Aug 2021 14:34:35 +0000 (UTC) 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 13A58106F; Wed, 25 Aug 2021 07:34:35 -0700 (PDT) Received: from [192.168.1.179] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C7F533F5A1; Wed, 25 Aug 2021 07:34:33 -0700 (PDT) Subject: Re: [PATCH v2 4/4] drm/panfrost: Handle non-aligned lock addresses To: Alyssa Rosenzweig Cc: Alyssa Rosenzweig , dri-devel@lists.freedesktop.org, Rob Herring , Tomeu Vizoso , David Airlie , Daniel Vetter , linux-kernel@vger.kernel.org References: <20210824173028.7528-1-alyssa.rosenzweig@collabora.com> <20210824173028.7528-5-alyssa.rosenzweig@collabora.com> <6fe675c4-d22b-22da-ba3c-f6d33419b9ed@arm.com> From: Steven Price Message-ID: <8db73065-e8e8-7894-7eac-befd082a25e1@arm.com> Date: Wed, 25 Aug 2021 15:34:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On 25/08/2021 15:07, Alyssa Rosenzweig wrote: >>> In practice, the current callers pass PAGE_SIZE aligned inputs, avoiding >>> the bug. Therefore this doesn't need to be backported. Still, that's a >>> happy accident and not a precondition of lock_region, so we let's do the >>> right thing to future proof. >> >> Actually it's worse than that due to the hardware behaviour, the spec >> states (for LOCKADDR_BASE): >> >>> Only the upper bits of the address are used. The address is aligned to a >>> multiple of the region size, so a variable number of low-order bits are >>> ignored, depending on the selected region size. It is recommended that software >>> ensures that these low bits in the address are cleared, to avoid confusion. >> >> It appears that indeed this has caused confusion ;) >> >> So for a simple request like locking from 0xCAFE0000 - 0xCB010000 (size >> = 0x30000) the region width gets rounded up (to 0x40000) which causes >> the start address to be effectively rounded down (by the hardware) to >> 0xCAFC0000 and we fail to lock 0xCB000000-0xCB010000. >> >> Interestingly (unless my reading of this is wrong) that means to lock >> 0xFFFF0000-0x100010000 (i.e. crossing the 4GB boundary) requires locking >> *at least* 0x00000000-0x200000000 (i.e. locking the first 8GB). >> >> This appears to be broken in kbase (which actually does zero out the low >> bits of the address) - I've raised a bug internally so hopefully someone >> will tell me if I've read the spec completely wrong here. > > Horrifying, and not what I wanted to read my last day before 2 weeks of > leave. Let's drop this patch, hopefully by the time I'm back, your > friends in GPU can confirm that's a spec bug and not an actual > hardware/driver one... > > Can you apply the other 3 patches in the mean time? Thanks :-) > Yeah, sure. I'll push the first 3 to drm-misc-next-fixes (should land in v5.15). It's interesting that if my (new) reading of the spec is correct then kbase has been horribly broken in this respect forever. So clearly it can't be something that crops up very often. It would have been good if the spec could have included wording such as "naturally aligned" if that's what was intended. Enjoy your holiday! Thanks, Steve