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 08B6978003C for ; Mon, 30 Oct 2023 11:33:45 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=5CiuN1kGNwjhch7+XZ0KWc5YgqBf0Vb2ebuGskKsBts=; 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=1698665624; v=1; b=K9LrZ5A3yvDjWgjJ6WKABXp22CnzhWbufVfhrD0qHFN2tS5EB7CemK4JWc7HW2N3Ff6s5t0N /rD4BJI8M+vH6IJUe2uZTmWcdv/YuSOtB8WmyD3ePTbFjrMM8jxQ2l4XxbhhYSU/TZdegcZdYl1 3ZcD8zXJ59oRYkwPGbbkmp/E= X-Received: by 127.0.0.2 with SMTP id jVthYY7687511xDk3PwlWPmu; Mon, 30 Oct 2023 04:33:44 -0700 X-Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) by mx.groups.io with SMTP id smtpd.web10.146422.1698665624137262207 for ; Mon, 30 Oct 2023 04:33:44 -0700 X-Received: by mail-pl1-f179.google.com with SMTP id d9443c01a7336-1cc316ccc38so8129525ad.1 for ; Mon, 30 Oct 2023 04:33:44 -0700 (PDT) X-Gm-Message-State: iIVvqW7Io2ttK2ovRVvw8dTAx7686176AA= X-Google-Smtp-Source: AGHT+IGlWCjv+allPQ4T6gSh4oL1clx1IOCIVcD4zTtPwyQXAOnDvIS55hpW36y+Oa09lPT35gK6YA== X-Received: by 2002:a17:902:e311:b0:1cc:2151:2b36 with SMTP id q17-20020a170902e31100b001cc21512b36mr5296107plc.55.1698665623417; Mon, 30 Oct 2023 04:33:43 -0700 (PDT) X-Received: from sunil-laptop ([106.51.188.78]) by smtp.gmail.com with ESMTPSA id iz11-20020a170902ef8b00b001cc436e9806sm2559071plb.81.2023.10.30.04.33.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Oct 2023 04:33:43 -0700 (PDT) Date: Mon, 30 Oct 2023 17:03:35 +0530 From: "Sunil V L" To: Laszlo Ersek Cc: Pedro Falcato , devel@edk2.groups.io, dhaval@rivosinc.com, Michael D Kinney , Liming Gao , Zhiguang Liu , Daniel Schaefer Subject: Re: [edk2-devel] [PATCH v7 3/5] MdePkg: Implement RISC-V Cache Management Operations Message-ID: References: <20231029144613.150580-1-dhaval@rivosinc.com> <20231029144613.150580-4-dhaval@rivosinc.com> <2db1b89a-6c7f-ea3f-becb-1e942b41a3e8@redhat.com> MIME-Version: 1.0 In-Reply-To: <2db1b89a-6c7f-ea3f-becb-1e942b41a3e8@redhat.com> 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=K9LrZ5A3; 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 Mon, Oct 30, 2023 at 10:38:21AM +0100, Laszlo Ersek wrote: > On 10/29/23 20:12, Pedro Falcato wrote: > > On Sun, Oct 29, 2023 at 2:46 PM 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). > I agree. As per my knowledge, we don't have a publicly available silicon implementing these features as of today. So, we are taking the approach of how linux merged these features when the code adhered to the spec. It will be great for downstream to get these patches merged. Thanks, Sunil -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#110312): https://edk2.groups.io/g/devel/message/110312 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] -=-=-=-=-=-=-=-=-=-=-=-