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 C7BF4D8030C for ; Tue, 9 Jan 2024 05:31:50 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=7FJDqGUyuIGKXvzc494qWLZk7Ca92Ql5IpoallGwax4=; c=relaxed/simple; d=groups.io; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type:Content-Disposition:Content-Transfer-Encoding; s=20140610; t=1704778309; v=1; b=bCVTurOMhvwRzuT4J3JE/WdwEuO+C0rr3U3cRBKzHSjsBuhOYj//esRX1pH5AKd87zLngpwC yWXxf4a0cjEmIpSNE04J4KdE3qQTW7nGhN1hYGkxUzpXtJow6rCLPoTaJQ51aj42MzVO/7ZD4FE +Hb49w0kTyDeUfMngGmAYuWQ= X-Received: by 127.0.0.2 with SMTP id vQdeYY7687511xejpf86q2bY; Mon, 08 Jan 2024 21:31:49 -0800 X-Received: from mail-oi1-f176.google.com (mail-oi1-f176.google.com [209.85.167.176]) by mx.groups.io with SMTP id smtpd.web10.10880.1704778308729765060 for ; Mon, 08 Jan 2024 21:31:48 -0800 X-Received: by mail-oi1-f176.google.com with SMTP id 5614622812f47-3bbbdf0b859so3050925b6e.3 for ; Mon, 08 Jan 2024 21:31:48 -0800 (PST) X-Gm-Message-State: T51Mrohyznd6qqPpDnkk2RLux7686176AA= X-Google-Smtp-Source: AGHT+IE8Jb5eN4IX1z6JY/fzSd3ur1P2LNVqUAlAOa3+lw1ZaXF8MBN0RHJGUTUh3ZPEk3gRdREoEg== X-Received: by 2002:a05:6808:158d:b0:3bd:3a12:1be4 with SMTP id t13-20020a056808158d00b003bd3a121be4mr978883oiw.119.1704778307887; Mon, 08 Jan 2024 21:31:47 -0800 (PST) X-Received: from sunil-laptop ([106.51.188.200]) by smtp.gmail.com with ESMTPSA id t14-20020aa78f8e000000b006d99f930607sm788621pfs.140.2024.01.08.21.31.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jan 2024 21:31:47 -0800 (PST) Date: Tue, 9 Jan 2024 11:01:41 +0530 From: "Sunil V L" To: Pedro Falcato Cc: devel@edk2.groups.io, dhaval@rivosinc.com, yorange , "Warkentin, Andrei" , Ard Biesheuvel , Leif Lindholm Subject: Re: [edk2-devel] [PATCH v10 4/5] MdePkg: Utilize Cache Management Operations Implementation For RISC-V Message-ID: References: <17828.1704727587183697949@groups.io> <6131.1704730982570913230@groups.io> MIME-Version: 1.0 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 Reply-To: devel@edk2.groups.io,sunilvl@ventanamicro.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=bCVTurOM; 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=none On Mon, Jan 08, 2024 at 09:53:46PM +0000, Pedro Falcato wrote: > On Mon, Jan 8, 2024 at 4:23 PM 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 = 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.. > My preference is just remove the assertion and add the debug verbose message instead of changing drivers/introduce new interfaces. It is a nop in linux as well if CMO is not present. Thanks, Sunil -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#113422): https://edk2.groups.io/g/devel/message/113422 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] -=-=-=-=-=-=-=-=-=-=-=-