From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id E9A09D8030C for ; Mon, 8 Jan 2024 21:54:01 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=ppz1N7blhi/gkuiQfCeDUYJt8H6WxRkaKmN/kZ2Fe54=; c=relaxed/simple; d=groups.io; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:To:Cc:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type:Content-Transfer-Encoding; s=20140610; t=1704750840; v=1; b=smOBBS2M8eSbgX0TII2KCW5FmnwbM19rkuWmfwKcTSjNBVgIbx7pTYkkhUCX5yZLgT6kMv2D 22nli7mx8c+IJMLA9uLJUQr4s6bmncZypLM0PHMR0E7cNp8pgmh5YYbiYQCGtaFaxqF0ClfiOpe MBrwlpfUh0OflaD7fL+8ApbU= X-Received: by 127.0.0.2 with SMTP id U4mpYY7687511xVpqng8xza5; Mon, 08 Jan 2024 13:54:00 -0800 X-Received: from mail-vk1-f174.google.com (mail-vk1-f174.google.com [209.85.221.174]) by mx.groups.io with SMTP id smtpd.web11.2190.1704750839863142904 for ; Mon, 08 Jan 2024 13:54:00 -0800 X-Received: by mail-vk1-f174.google.com with SMTP id 71dfb90a1353d-4b739b49349so383510e0c.1 for ; Mon, 08 Jan 2024 13:53:59 -0800 (PST) X-Gm-Message-State: tfgBdxZBasaYuXJijyeru0y6x7686176AA= X-Google-Smtp-Source: AGHT+IELtf972KWQ3LUskduFqPYIRAD/Eh/4CfXy5OD5llRM+PRazKTqCzd/bQ9A+9Sdi+UuQDGBdnsMKFl1m+bkRHY= X-Received: by 2002:a05:6122:122:b0:4b6:e096:806 with SMTP id a2-20020a056122012200b004b6e0960806mr1573016vko.12.1704750838671; Mon, 08 Jan 2024 13:53:58 -0800 (PST) MIME-Version: 1.0 References: <17828.1704727587183697949@groups.io> <6131.1704730982570913230@groups.io> In-Reply-To: <6131.1704730982570913230@groups.io> From: "Pedro Falcato" Date: Mon, 8 Jan 2024 21:53:46 +0000 Message-ID: Subject: Re: [edk2-devel] [PATCH v10 4/5] MdePkg: Utilize Cache Management Operations Implementation For RISC-V To: devel@edk2.groups.io, dhaval@rivosinc.com Cc: yorange , Sunil V L , "Warkentin, Andrei" , Ard Biesheuvel , Leif Lindholm 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 Reply-To: devel@edk2.groups.io,pedro.falcato@gmail.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=smOBBS2M; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=gmail.com (policy=none) On Mon, Jan 8, 2024 at 4:23=E2=80=AFPM Dhaval Sharma = wrote: > > Hi yangcheng/Pedro, +CC a bunch of relevant people Hi, (FYI you did not CC me) Looking at yangcheng's example: Status =3D PrepareDmaData (gpIdmacDesc, Length, Buffer); <-- We write to the IDMAC desc if (EFI_ERROR (Status)) { goto out; } WriteBackDataCacheRange (gpIdmacDesc, DescPages * EFI_PAGE_SIZE); <-- Make sure it's DMA-coherent StartDma (Length); <-- We've flushed the cache, everything is now in DRAM and DMA-coherent, start DMA which screams of "bad abstractions" because you don't actually need to write data back, if the device and platform are DMA coherent. So what we want here really depends. My local "Volume I: RISC-V Unprivileged ISA V20191213" says, section A.5: "Table A.5 provides a mapping of Linux memory ordering macros onto RISC-V memory instructions. The Linux fences dma rmb() and dma wmb() map onto FENCE R,R and FENCE W,W, respectively, since the RISC-V Unix Platform requires coherent DMA, but would be mapped onto FENCE RI,RI and FENCE WO,WO, respectively, on a platform with non-coherent DMA. Platforms with non- coherent DMA may also require a mechanism by which cache lines can be flushed and/or invalidated. Such mechanisms will be device-specific and/or standardized in a future extension to the ISA." The (current date) RISCV Platform Spec also says: "Memory accesses by I/O masters can be coherent or non-coherent with respect to all hart-related caches." which is brilliantly useless. so I think the best solution here is to: 1) Add a new PCD for platform DMA coherency, and test that on WriteBackDataCacheRange's ASSERT (if (!Coherent) ASSERT() else return;) 2) Add a more abstracting API that doesn't necessarily map to WriteBackDataCache when all we wanted was to assert DMA coherency but, alas, I've seen a lot less funky platforms than many of you, and DMA/cache-coherency is not really my thing, so I'll defer to others.. --=20 Pedro -=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 (#113412): https://edk2.groups.io/g/devel/message/113412 Mute This Topic: https://groups.io/mt/103150435/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-