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 E96BAD8018D for ; Mon, 30 Oct 2023 16:37:55 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=GIEMlUh5yJr7f8rqQAxVu7EfY0vf+qbKM/q8GSkn0WA=; 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=1698683874; v=1; b=h4bCVpRL0VNdPfxS3MQ7EUFm4waONzEqbRKRuMcLjiZYU72CSbr000feIbDLhJ7dzaKhNG7n 9OIaupxTQme2lmX290mMb4qkXgbaGNQOhOShRdZ5Y35Uj35gCiMGAlt/C2X9QlvkZ69KaxKJ4zl EI5zkm6sNYliFddHWsigmMaI= X-Received: by 127.0.0.2 with SMTP id 4aS8YY7687511xTQHuGJqv8p; Mon, 30 Oct 2023 09:37:54 -0700 X-Received: from mail-ua1-f53.google.com (mail-ua1-f53.google.com [209.85.222.53]) by mx.groups.io with SMTP id smtpd.web11.154089.1698683868944809654 for ; Mon, 30 Oct 2023 09:37:49 -0700 X-Received: by mail-ua1-f53.google.com with SMTP id a1e0cc1a2514c-7b9d894be6fso1268664241.2 for ; Mon, 30 Oct 2023 09:37:48 -0700 (PDT) X-Gm-Message-State: RfErnTB6eVL1QkNqdpFikdZZx7686176AA= X-Google-Smtp-Source: AGHT+IHT44jP1YzVhvsBNjmK9iIgleN8eAb3POSm0sSCyRgXNp7PO6XUg442pYMzNJmUnTRrO2a41jm7aTc+OSwxiCA= X-Received: by 2002:a67:f44e:0:b0:452:db93:1ee3 with SMTP id r14-20020a67f44e000000b00452db931ee3mr5893657vsn.30.1698683867466; Mon, 30 Oct 2023 09:37:47 -0700 (PDT) MIME-Version: 1.0 References: <20231029144613.150580-1-dhaval@rivosinc.com> <20231029144613.150580-4-dhaval@rivosinc.com> <2db1b89a-6c7f-ea3f-becb-1e942b41a3e8@redhat.com> In-Reply-To: <2db1b89a-6c7f-ea3f-becb-1e942b41a3e8@redhat.com> From: "Pedro Falcato" Date: Mon, 30 Oct 2023 16:37:36 +0000 Message-ID: Subject: Re: [edk2-devel] [PATCH v7 3/5] MdePkg: Implement RISC-V Cache Management Operations To: Laszlo Ersek Cc: devel@edk2.groups.io, dhaval@rivosinc.com, Michael D Kinney , Liming Gao , Zhiguang Liu , Sunil V L , Daniel Schaefer 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=h4bCVpRL; 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, Oct 30, 2023 at 9:38=E2=80=AFAM Laszlo Ersek wr= ote: > > On 10/29/23 20:12, Pedro Falcato wrote: > > On Sun, Oct 29, 2023 at 2:46=E2=80=AFPM Dhaval Sharma wrote: > >> > >> Implement Cache Management Operations (CMO) defined by > >> RISC-V spec https://github.com/riscv/riscv-CMOs. > >> > >> Notes: > >> 1. CMO only supports block based Operations. Meaning cache > >> flush/invd/clean Operations are not available for the entire > >> range. In that case we fallback on fence.i instructions. > >> 2. Operations are implemented using Opcodes to make them compiler > >> independent. binutils 2.39+ compilers support CMO instructions. > >> > >> Test: > >> 1. Ensured correct instructions are refelecting in asm > > > > nit: reflecting > > > >> 2. Not able to verify actual instruction in HW as Qemu ignores > >> any actual cache operations. > > > > Do you have no way to test this in hardware? Since Rivos is a RISCV > > vendor and all ;) > > I don't like inviting the idea of merging CPU architectural changes > > without actually testing them in something resembling real silicon > > (i.e QEMU KVM is _fine_, QEMU TCG really isn't). > > > > Hopefully I'm not drawing an incorrect parallel here, but, as I recall > arm64 enablement in 2014, nearly all initial enablement in RHEL occurred > on software emulators (ARM Foundation Model, ARM FVP, then QEMU TCG). > You need to start somewhere. In particular, qemu-system-aarch64 was a > huge step forward (performance-wise) once it *existed*, relative to the > Foundation Model / FVP, even though qemu-system-aarch64 wouldn't emulate > CPU caches (IIRC). Right. I don't know how faithful those early ARM simulators were, but QEMU TCG is not very faithful and uarch details *can* slip through the cracks. In arm64 it's easy to miss a dsb or a isb if you're not extra careful (or read the ARM ARM wrong). RISCV has a bunch of fun gotchas too. For instance, did you know you need to flush the TLB using sfence.vma even when only mapping a page? This "small" detail results in boot failures on real hardware (such as the visionfive 2), but is completely silent in QEMU TCG. So this is why I would much prefer a test on real silicon. It's hard to prove correctness when all you have is QEMU's spotty simulation (rightfully so, it's not a simulator). -- 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 (#110322): https://edk2.groups.io/g/devel/message/110322 Mute This Topic: https://groups.io/mt/102256466/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-