From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail05.groups.io (mail05.groups.io [45.79.224.7]) by spool.mail.gandi.net (Postfix) with ESMTPS id EE70DAC16D8 for ; Thu, 5 Jun 2025 17:55:49 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=Kb+8sIaThaPTfTo1es7XP81ixVBFLU4KZtPUELDK9kM=; c=relaxed/simple; d=groups.io; h=DKIM-Filter:Message-ID:Date:MIME-Version:User-Agent:Subject:To:Cc:References:From:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Resent-Date:Resent-From:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type:Content-Transfer-Encoding; s=20240830; t=1749146149; v=1; x=1749405348; b=GLgp3u7MfPZqdA6X3DD8nP15qx3pBcUNuYGHBUrsqZb5iQvpLSxkELnKv76ExjJdi//VOE0D IIKXUkyFBboGuyzkVpLhdKFKicT9F1Q1/GUxx5vkRgnG26+O+GjHoGlOw386G61cRvz3sGypdwl fWjj0oE7eI8s76XkLwV3KrqBATCZRDiBmhGlWIVmQijIprlLH/Afn4qLYVAtyxDfbeWDlc6c5js 84nMdb1j19N4JF4aHDhURfNiEst+WOPORGwAM/dz/pfxjQTr2KzetD2vbHMnrh2ipGXl7qA3OLh xwSUoI/l8E5iWvDhjQV5XD4ihqAVZDGG3p2VziHmLV3rA== X-Received: by 127.0.0.2 with SMTP id CFvzYY7687511xaYQcH1UWEh; Thu, 05 Jun 2025 10:55:48 -0700 X-Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mx.groups.io with SMTP id smtpd.web11.14371.1749146147464009195 for ; Thu, 05 Jun 2025 10:55:47 -0700 X-Received: from [10.137.194.171] (unknown [131.107.147.171]) by linux.microsoft.com (Postfix) with ESMTPSA id D80EB203FC87; Thu, 5 Jun 2025 10:55:46 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com D80EB203FC87 Message-ID: <15878281-81e0-42fb-b58a-043999c79403@linux.microsoft.com> Date: Thu, 5 Jun 2025 10:55:46 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [edk2-devel] AARCH64 Cacheability Attributes To: devel@edk2.groups.io, ardb@kernel.org Cc: Leif Lindholm References: <7aa61f2f-f17c-438a-b676-7d80b32895ae@linux.microsoft.com> From: "Oliver Smith-Denny via groups.io" In-Reply-To: Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Resent-Date: Thu, 05 Jun 2025 10:55:47 -0700 Resent-From: osde@linux.microsoft.com Reply-To: devel@edk2.groups.io,osde@linux.microsoft.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: VbxOpO2WHDK7XfUOH6mGL8Fsx7686176AA= Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20240830 header.b=GLgp3u7M; dmarc=pass (policy=none) header.from=groups.io; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 45.79.224.7 as permitted sender) smtp.mailfrom=bounce@groups.io On 6/5/2025 10:27 AM, Ard Biesheuvel via groups.io wrote: > Hi, >=20 > Thanks for elaborating. >=20 > First of all, I would assume that the device is actually non-coherent, > or it wouldn't work at all using the non-coherent routines, given that > these perform cache invalidation on buffers used for inbound DMA, > which would nuke any data the device would have put there via its > cacheable mapping (line 1453 in the same file). Well, that's the odd thing, the device works when we have it use the coherent and the non-coherent routines :). We aren't the platform team though, so I am following up with them and the silicon vendor to get a real answer here other than "well it worked." >=20 > I think it was a mistake for ARM platforms to ever use UC|WC||WT|WB by > default for describing conventional memory. On ARM, only WC and WB > make sense for RAM, and UC should be used for MMIO (i.e., memory > ranges that are not backed any kind of RAM but by device registers > where both reads and writes may have side effects). Note that not only > misaligned accesses are problematic, also DC ZVA instructions will > fail, and these are heavily used to accelerate SetMem() I agree that it was a mistake for ARM platforms to use all the x86 cache types, definitely creates a confusing mess, but that leads me to the belief that the spec should be updated to be able to fit the architecture (which I agree, may not be another caching type, I need to think on this more). >=20 > Simply dropping UC from the code that declares the DRAM in the > platform startup code should fix the issue entirely, afaict. (Note > that ArmVirtQemu et al declare their system memory as only WB capable > and nothing else - this is needed because KVM is fundamentally > coherent, as the VMM uses cacheable mappings to access guest memory) That's a good point and we'll test with that. This would work for this case because NonDiscoverablePciDxe toggles between WC and UC and chooses WC if UC isn't supported, but there is nothing that specifies that behavior globally. It would be valid for a driver to say I need to do non-coherent DMA (or some other use case) and to say so I will set the attributes to UC. On ARM, you would have to set that to WC, but now the driver needs to know architecture level details, which is not ideal. For x86, you would want to set UC. >=20 > Adding more memory types to the spec is not going to solve anything, > I'm afraid. We already have some dubious ISA mask types that were > added without proper motivation, and I'd rather have fewer types > (e.g., on ARM, WT is also just normal non-cacheable under the hood in > most cases and I don't have a clue how it is intended to be used). > Instead, we should stop using UC for conventional memory. >=20 Yeah, I agree that already the invalid cacheability types are troubling and adding more may just make the situation worse. We'll think on this some more, I still believe this is a spec problem, that the spec does not envision the ARM64 architecture and very explicitly envisions the x86 architecture, which leads to issues like this (of course in many areas). I worry about relying on code workarounds for spec issues creates an untenable position where a driver thinks it is doing the right thing, per spec, but then the juggling under the hood to figure out how to translate it to an aarch64 concept breaks down somewhere. Thanks, Oliver -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#121400): https://edk2.groups.io/g/devel/message/121400 Mute This Topic: https://groups.io/mt/113471239/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-