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 4CA3C740035 for ; Thu, 5 Jun 2025 20:21:23 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=NscILeJJqO5yH3KZHCs/QtRaV4+q42E1bOzqf9LNZp8=; 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=1749154883; v=1; x=1749414081; b=dYb/4ZKWdc15etlvoQrTuFGKBXUvjelkN01GCGAN7s+G4MTLNRHdoUaDiB4EVsPEvJh5pcRA 1ApxYbhWX5x/7V3Qt9pL/Kqtm3m2ycrretFno3BQM+HTyi23KDKdCnCOg9mWU6gpsCP6RQEyd2d 98wbMbPmpO80RLbB9+qqds50rSwcINwYbb4zd21eWw5ov19Ifjm5dhFde7NIHt87b8oVfM7i/w2 DCmPGpEhz/5lT5QAPKYhbjAarMO0fXlx8cmyLnKTHazrXsSz5/w9eCPOJyTRJn/vfblc1pIXG93 4ubte4jHVvHt/OESgG3mZ4FaiWeOAnfHwM+XcgB4PPcsA== X-Received: by 127.0.0.2 with SMTP id 0YZsYY7687511xpO5XOr405d; Thu, 05 Jun 2025 13:21:21 -0700 X-Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mx.groups.io with SMTP id smtpd.web11.18212.1749154881249769710 for ; Thu, 05 Jun 2025 13:21:21 -0700 X-Received: from [10.137.194.171] (unknown [131.107.147.171]) by linux.microsoft.com (Postfix) with ESMTPSA id B416220277DF; Thu, 5 Jun 2025 13:21:20 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com B416220277DF Message-ID: <408d3cad-9349-416a-b2d7-47aa3b55ea97@linux.microsoft.com> Date: Thu, 5 Jun 2025 13:21:20 -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> <15878281-81e0-42fb-b58a-043999c79403@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 13:21:21 -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: d7u1vUjTgkERnwBfxC2O1CuSx7686176AA= 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="dYb/4ZKW"; 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 11:19 AM, Ard Biesheuvel via groups.io wrote: > On Thu, 5 Jun 2025 at 19:55, Oliver Smith-Denny > wrote: >> 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 > No. Whether DMA is coherent or not is /not/ a property of the device, > it is a property of how that device was integrated into the system. I agree with that, I was thinking more of the PciNonDiscoverable case, but more on that below. >=20 > So a device driver should never have to reason about the difference > between coherent or non-coherent DMA, unless it is tightly coupled > with the platform, in which case this would not be an issue. >=20 > Note that the NonCoherentDmaLib in EmbeddedPkg already prefers WC over > UC. I don't remember why I didn't do the same when I wrote > NonDiscoverablePciDxe, because it is the obvious correct thing to do > on ARM (and x86 doesn't use this driver at all afaik) >=20 I think you are right here, that we should move to prefer WC over UC in NonDiscoverablePciDxe since these are host buffers and may need to be normal uncacheable but should never be device memory (so to that end, should it only set WC and not UC at all?). >=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. >>> >> >> 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. >> >=20 > The driver should not care about the difference. If there are > currently drivers that need to, we should fix the abstractions > instead. >=20 I will go through edk2 and see if anything is breaking this assumption, I agree that the platform is the only one who knows the cacheability. I still think it is unfortunate that we have to do some mapping between x86 attributes and aarch64 attributes, but if we can ensure edk2 is clean w.r.t. class drivers not setting cacheability attributes, I think we can get away with it. If you are amenable to it, I'll put up a PR for NonDiscoverablePciDxe to prefer WC over UC (or someone on my team will), though want your input on whether we allow UC at all there. 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 (#121402): https://edk2.groups.io/g/devel/message/121402 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-