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 AC42B74003C for ; Fri, 19 Jan 2024 05:08:49 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=13RNGkxKVQuCjpPAdkl19Y0ZJaMWIYDThUG9tsLGgso=; 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=1705640928; v=1; b=nLjoJM5ZQNOMEXoy3e54gDaxl87Td8X2CS0gZNVcKJSAYYk82VbJQx0vXDrO1whRPdvxGtdn fmD8nZmkIgEV4iNN+UUw36T7MWrUSjWhIH60VaGKK31GGt9Id5SfypgUntXDERLyAl2t8bTRP7n bSXEh3b8AP1bPsPRYdghRnzg= X-Received: by 127.0.0.2 with SMTP id w0N2YY7687511xFhmhpD9kF5; Thu, 18 Jan 2024 21:08:48 -0800 X-Received: from mail-io1-f44.google.com (mail-io1-f44.google.com [209.85.166.44]) by mx.groups.io with SMTP id smtpd.web10.15155.1705640927636012657 for ; Thu, 18 Jan 2024 21:08:47 -0800 X-Received: by mail-io1-f44.google.com with SMTP id ca18e2360f4ac-7bc32b0fdadso18137639f.2 for ; Thu, 18 Jan 2024 21:08:47 -0800 (PST) X-Gm-Message-State: bzYQwP49j8YHhMlawVSEdSPCx7686176AA= X-Google-Smtp-Source: AGHT+IE+cMhQg3yRhW2ZwUfib0As/k8jUrPI21bSnm2wnYGbS7YDE9O4m+uUN0c5WVvPz24m0aaTSQ== X-Received: by 2002:a5e:8344:0:b0:7bf:5458:51a3 with SMTP id y4-20020a5e8344000000b007bf545851a3mr2404291iom.6.1705640924778; Thu, 18 Jan 2024 21:08:44 -0800 (PST) X-Received: from sunil-laptop ([106.51.188.200]) by smtp.gmail.com with ESMTPSA id a13-20020a056638004d00b0046e6a6482d2sm1383971jap.97.2024.01.18.21.08.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Jan 2024 21:08:44 -0800 (PST) Date: Fri, 19 Jan 2024 10:38:37 +0530 From: "Sunil V L" To: Pedro Falcato Cc: Dhaval , devel@edk2.groups.io, Liming Gao , Michael D Kinney , Zhiguang Liu , Andrei Warkentin , Laszlo Ersek , Yang Cheng Subject: Re: [edk2-devel] [PATCH v1 1/1] MdePkg/BaseCacheMaintenanceLib: RV64 replace asserts with logs Message-ID: References: <20240118095018.509362-1-dhaval@rivosinc.com> <20240118095018.509362-2-dhaval@rivosinc.com> 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=nLjoJM5Z; dmarc=none; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io On Thu, Jan 18, 2024 at 03:58:04PM +0000, Pedro Falcato wrote: > On Thu, Jan 18, 2024 at 9:50 AM Dhaval wrote: > > > > Some platforms do not implement cache management operations. Especially > > for DMA drivers have code to manage data cache. The code seem to depend > > on the underlying CPU/cache drivers to enact functionality and simply > > return if such functionality is not implemented. However this causes > > issue with CMO implementation which has an assert causing flow to > > hang within debug environment. While it is not an issue in production > > environment there is a recommendation to conver this assert in to > > I don't agree with this patch. As I see it, the library has a simple > contract: Do cache operation X and return. We cannot safely return if > we don't know how to do cache operation X. Say, with a Thead core and > Xtheadcmo. > Any other concerns wrt DMA are, in my view, somewhat separate. > > One can easily theorize a way this change can come to bite us, say, a > storage controller writes bogus data to storage (because the platform > needs explicit cache coherency, and we don't know how to do that) and > causes data corruption. > I understand your point. It is an issue for sure if the device is non cache coherent but there is no way to flush the cache. However, if CMO is not there, the driver should use NonCacheCoherent library which uses UC memory. These interfaces will be called for UC memory in that case which should be NO-OP instead of assertion. For custom CMO extension, the silicon vendor needs to implement different cache management library in edk2-platforms. Having said that, I notice that the interface in CpuDxe needs to be updated now. Dhaval, would you be able to add that patch also? Thanks, Sunil > > a harmless logger message. Eventually platform/drivers need to have > > better guard for such functionality. > > Like an ASSERT? :) > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#114026): https://edk2.groups.io/g/devel/message/114026 Mute This Topic: https://groups.io/mt/103805230/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=-