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 00E77D81112 for ; Wed, 24 Jan 2024 14:27:41 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=fSSNOBqwzF+b7cQM5PDA1urXR47xX3PHbTH8xvvFxOs=; 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; s=20140610; t=1706106460; v=1; b=WIQ7zPHcsEJ2nnbirSEs1hJnqq/mqQyMJt2aZJZX4cuxX4VH/4LhOuKNYMbcompI+GKAqTiq 7quNJ+LpLGGtL8NcuyOOGE3yX/pobS3zMcrsMZO3nPAf/U/wGZ26xOdyKEuO9MBZY/po0VnU+gD QEN1bZUgsFMhh0DIONVg/XfE= X-Received: by 127.0.0.2 with SMTP id AomBYY7687511xdFVpvigyxa; Wed, 24 Jan 2024 06:27:40 -0800 X-Received: from mail-qv1-f50.google.com (mail-qv1-f50.google.com [209.85.219.50]) by mx.groups.io with SMTP id smtpd.web11.23885.1706106459416881821 for ; Wed, 24 Jan 2024 06:27:39 -0800 X-Received: by mail-qv1-f50.google.com with SMTP id 6a1803df08f44-6869233d472so13383336d6.2 for ; Wed, 24 Jan 2024 06:27:39 -0800 (PST) X-Gm-Message-State: 7vaQ1zuXeO1trmrYUISlPKfyx7686176AA= X-Google-Smtp-Source: AGHT+IGVrcMELCItvzVLjqOqOx49i/eY8Uji9KJo9ON37p6TIzAr/lsznJ9jU0HXyypLH23NCsS4fFfj48WZ/PyhhVg= X-Received: by 2002:a05:6214:ca2:b0:686:3fe8:2797 with SMTP id s2-20020a0562140ca200b006863fe82797mr3158297qvs.128.1706106458337; Wed, 24 Jan 2024 06:27:38 -0800 (PST) MIME-Version: 1.0 References: <20240118095018.509362-1-dhaval@rivosinc.com> <20240118095018.509362-2-dhaval@rivosinc.com> In-Reply-To: From: "Dhaval Sharma" Date: Wed, 24 Jan 2024 19:57:27 +0530 Message-ID: Subject: Re: [edk2-devel] [PATCH v1 1/1] MdePkg/BaseCacheMaintenanceLib: RV64 replace asserts with logs To: Sunil V L Cc: devel@edk2.groups.io, Liming Gao , Michael D Kinney , Zhiguang Liu , Andrei Warkentin , Laszlo Ersek , Pedro Falcato , Yang Cheng 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,dhaval@rivosinc.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: Content-Type: multipart/alternative; boundary="00000000000066070e060fb1ddae" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=WIQ7zPHc; 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 --00000000000066070e060fb1ddae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable "The CpuDxe interface will be the wrapper." Yes, of course. It needs to be added. I was just saying that maybe any CMO checking is not required there as cmo library will take care of it. On Tue, Jan 23, 2024 at 10:24=E2=80=AFPM Sunil V L wrote: > On Tue, Jan 23, 2024 at 11:42:57AM +0530, Dhaval Sharma wrote: > > Sunil, > > I thought "WriteBackDataCacheRange not supported" is more explicit over > > "CMO not available". > > > Okay. > > > @Pedro Falcato For the example you mentioned, > is > > your concern more about someone not being able to notice the problem > (that > > the system is non-coherent) at the time of development and later ending > up > > with corrupted data during production? And you are suggesting that an > > Assert helps address that problem by making that problem more visible t= o > > the developer and a verbose warning does not? > > > > I can create a patch for CpuFlushCpuDataCache but I think we should avo= id > > CMO based return in there. Because in case of InvalidateDataCacheRange = we > > have an alternate implementation of fence in the absence of CMO. So it = is > > better to let riscvcache decide the right implementation. > > > The CpuDxe interface will be the wrapper. See Arm's implementation. > Since CMO support is added now, the CpuDxe interface should be updated. > > Thanks, > Sunil > --=20 Thanks! =3DD -=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 (#114302): https://edk2.groups.io/g/devel/message/114302 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] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- --00000000000066070e060fb1ddae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
"The CpuDxe interface will be the wrapper." Yes,= of course. It needs to be added. I was just saying that maybe any CMO chec= king is not required there as cmo library will take care=C2=A0of it.
<= br>
On Tue,= Jan 23, 2024 at 10:24=E2=80=AFPM Sunil V L <sunilvl@ventanamicro.com> wrote:
On Tue, Jan 23, 2024 at 11:42:57AM= +0530, Dhaval Sharma wrote:
> Sunil,
> I thought "WriteBackDataCacheRange not supported" is more ex= plicit over
> "CMO not available".
>
Okay.

> @Pedro Falcato <pedro.falcato@gmail.com> For the example you mentioned, = is
> your concern more about someone not being able to notice the problem (= that
> the system is non-coherent) at the time of development and later endin= g up
> with corrupted data during production? And you are suggesting that an<= br> > Assert helps address that problem by making that problem more visible = to
> the developer and a verbose warning does not?
>
> I can create a patch for CpuFlushCpuDataCache but I think we should av= oid
> CMO based return in there. Because in case of InvalidateDataCacheRange= we
> have an alternate implementation of fence in the absence of CMO. So it= is
> better to let riscvcache decide the right implementation.
>
The CpuDxe interface will be the wrapper. See Arm's implementation.
Since CMO support is added now, the CpuDxe interface should be updated.

Thanks,
Sunil


--
Thanks!
=3DD
_._,_._,_
Groups.io Links:

=20 You receive all messages sent to this group. =20 =20

View/Reply Online (#114302) | =20 | Mute= This Topic | New Topic
Your Subscriptio= n | Contact Group Owner | Unsubscribe [rebecca@openfw.io]

_._,_._,_
--00000000000066070e060fb1ddae--