From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 790A8C001DE for ; Fri, 4 Aug 2023 18:05:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=8kLVJ/6D7SEbsNhXRSSGuayUWwbEZOMA4pLoLithg+c=; b=ULrHoSskI+3uiJ mxMlQk4Xz8uc2mGEVei2JKZtdqYMXwNG9Hb2SW6bEs7ueBC3yW6CEAc58PSrTooFDrZvpqxXT1BZu 3XzHYK7sUmInWTurxNyzxKa+SYXnpUwlUYnj7C/QCE/781yfsNY/hTDQMP/UyLOyea6020R7eqBPw ZIJO8NBcEQ1aqE9tsIyrBwQbSSbu0tOIRZt9N2CfRhhd+HvCSFR6DV0Z0H+kBqeUxTO32jx2kgcAW 4vFO/3k+uX598hKsswG7IYbxLnI+crAudbHvOYvwBfROkZTqKDg32gp1pRS6wGALzkBJEDZIFX6gL ul2HtTxHx+egOMocmWWg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qRzAt-00Cx1r-0c; Fri, 04 Aug 2023 18:05:19 +0000 Received: from smtpout.efficios.com ([167.114.26.122]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qRzAo-00Cx0c-1T for linux-riscv@lists.infradead.org; Fri, 04 Aug 2023 18:05:16 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=efficios.com; s=smtpout1; t=1691172302; bh=VHBir7999qQ/5qjfN/1N+4Xr5C/fghWazsI01lj3bq0=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=BKXCI30TCLRoc/dHYnRk74jGhjC6o38c8FfkDKAy1H3oGeXMy27XEAJX+8DuR+njg rc+VAc5q3KOZl2r30ifupkrhSo7Bhx25Kzj3nfmpz/QypRQmuEBMA9+0GQGukJzqFQ vVlRxa+xlYibD5ulDqy9s1BITu/WbGJXe+CK7VqVPBDdTh228Bwwu5/eKLTg4ZwwlC NNrUC7URVx4TdAbSQ8cvb/Ql8CCOWug718ZJmTN0ewzB/uNoHorjecrBR2mh0+k+aY 4XEn2MzI+Uq/AihSfDR4Cqylyr3mFZs3bXjAFeSQh0X5prrS1R47dthyJZKgYIOFRN Qr12Vkl7M147A== Received: from [IPV6:2605:59c8:2711:c800::c66] (unknown [IPv6:2605:59c8:2711:c800::c66]) by smtpout.efficios.com (Postfix) with ESMTPSA id 4RHYXG1Cx3z1KW8; Fri, 4 Aug 2023 14:05:02 -0400 (EDT) Message-ID: Date: Fri, 4 Aug 2023 14:05:55 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [RFC PATCH] membarrier: riscv: Provide core serializing command Content-Language: en-US To: Andrea Parri Cc: paulmck@kernel.org, paul.walmsley@sifive.com, palmer@dabbelt.com, aou@eecs.berkeley.edu, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, mmaas@google.com, hboehm@google.com, striker@us.ibm.com References: <20230803040111.5101-1-parri.andrea@gmail.com> <4bf79f06-4593-134a-04dd-b8f89e96a1b8@efficios.com> <65350c17-3fcf-a057-a280-f6a5d36dcb21@efficios.com> From: Mathieu Desnoyers In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230804_110514_563661_3819A7FD X-CRM114-Status: GOOD ( 22.09 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org T24gOC80LzIzIDEwOjU5LCBBbmRyZWEgUGFycmkgd3JvdGU6Cj4+IFdoYXQgaXMgdGhlIHJlbGF0 aW9uc2hpcCBiZXR3ZWVuIEZFTkNFLkkgYW5kIGluc3RydWN0aW9uIGNhY2hlIGZsdXNoIG9uCj4+ IFJJU0MtViA/Cj4gCj4gVGhlIGV4YWN0IG5hdHVyZSBvZiB0aGlzIHJlbGF0aW9uc2hpcCBpcyBp bXBsZW1lbnRhdGlvbi1kZXBlbmRlbnQuICBGcm9tCj4gY29tbWVudGFyeSBpbmNsdWRlZCBpbiB0 aGUgSVNBIHBvcnRpb24gcmVmZXJyZWQgdG8gaW4gdGhlIGNoYW5nZWxvZzoKPiAKPiAgICBBIHNp bXBsZSBpbXBsZW1lbnRhdGlvbiBjYW4gZmx1c2ggdGhlIGxvY2FsIGluc3RydWN0aW9uIGNhY2hl IGFuZAo+ICAgIHRoZSBpbnN0cnVjdGlvbiBwaXBlbGluZSB3aGVuIHRoZSBGRU5DRS5JIGlzIGV4 ZWN1dGVkLiAgQSBtb3JlCj4gICAgY29tcGxleCBpbXBsZW1lbnRhdGlvbiBtaWdodCBzbm9vcCB0 aGUgaW5zdHJ1Y3Rpb24gKGRhdGEpIGNhY2hlIG9uCj4gICAgZXZlcnkgZGF0YSAoaW5zdHJ1Y3Rp b24pIGNhY2hlIG1pc3MsIG9yIHVzZSBhbiBpbmNsdXNpdmUgdW5pZmllZAo+ICAgIHByaXZhdGUg TDIgY2FjaGUgdG8gaW52YWxpZGF0ZSBsaW5lcyBmcm9tIHRoZSBwcmltYXJ5IGluc3RydWN0aW9u Cj4gICAgY2FjaGUgd2hlbiB0aGV5IGFyZSBiZWluZyB3cml0dGVuIGJ5IGEgbG9jYWwgc3RvcmUg aW5zdHJ1Y3Rpb24uICBJZgo+ICAgIGluc3RydWN0aW9uIGFuZCBkYXRhIGNhY2hlcyBhcmUga2Vw dCBjb2hlcmVudCBpbiB0aGlzIHdheSwgb3IgaWYKPiAgICB0aGUgbWVtb3J5IHN5c3RlbSBjb25z aXN0cyBvZiBvbmx5IHVuY2FjaGVkIFJBTXMsIHRoZW4ganVzdCB0aGUKPiAgICBmZXRjaCBwaXBl bGluZSBuZWVkcyB0byBiZSBmbHVzaGVkIGF0IGEgRkVOQ0UuSS4gIFsuLl0KPiAKPiBNbWgsIGRv ZXMgdGhpcyBoZWxwPwoKUXVvdGluZwoKaHR0cHM6Ly9naXRodWIuY29tL3Jpc2N2L3Jpc2N2LWlz YS1tYW51YWwvcmVsZWFzZXMvZG93bmxvYWQvUmF0aWZpZWQtSU1BRkRRQy9yaXNjdi1zcGVjLTIw MTkxMjEzLnBkZgoKQ2hhcHRlciAzICLigJxaaWZlbmNlaeKAnSBJbnN0cnVjdGlvbi1GZXRjaCBG ZW5jZSwgVmVyc2lvbiAyLjAiCgoiRmlyc3QsIGl0IGhhcyBiZWVuIHJlY29nbml6ZWQgdGhhdCBv biBzb21lIHN5c3RlbXMsIEZFTkNFLkkgd2lsbCBiZSBleHBlbnNpdmUgdG8gaW1wbGVtZW50CmFu ZCBhbHRlcm5hdGUgbWVjaGFuaXNtcyBhcmUgYmVpbmcgZGlzY3Vzc2VkIGluIHRoZSBtZW1vcnkg bW9kZWwgdGFzayBncm91cC4gSW4gcGFydGljdWxhciwKZm9yIGRlc2lnbnMgdGhhdCBoYXZlIGFu IGluY29oZXJlbnQgaW5zdHJ1Y3Rpb24gY2FjaGUgYW5kIGFuIGluY29oZXJlbnQgZGF0YSBjYWNo ZSwgb3Igd2hlcmUKdGhlIGluc3RydWN0aW9uIGNhY2hlIHJlZmlsbCBkb2VzIG5vdCBzbm9vcCBh IGNvaGVyZW50IGRhdGEgY2FjaGUsIGJvdGggY2FjaGVzIG11c3QgYmUgY29tcGxldGVseQpmbHVz aGVkIHdoZW4gYSBGRU5DRS5JIGluc3RydWN0aW9uIGlzIGVuY291bnRlcmVkLiBUaGlzIHByb2Js ZW0gaXMgZXhhY2VyYmF0ZWQgd2hlbiB0aGVyZSBhcmUKbXVsdGlwbGUgbGV2ZWxzIG9mIEkgYW5k IEQgY2FjaGUgaW4gZnJvbnQgb2YgYSB1bmlmaWVkIGNhY2hlIG9yIG91dGVyIG1lbW9yeSBzeXN0 ZW0uCgpTZWNvbmQsIHRoZSBpbnN0cnVjdGlvbiBpcyBub3QgcG93ZXJmdWwgZW5vdWdoIHRvIG1h a2UgYXZhaWxhYmxlIGF0IHVzZXIgbGV2ZWwgaW4gYSBVbml4LWxpa2UKb3BlcmF0aW5nIHN5c3Rl bSBlbnZpcm9ubWVudC4gVGhlIEZFTkNFLkkgb25seSBzeW5jaHJvbml6ZXMgdGhlIGxvY2FsIGhh cnQsIGFuZCB0aGUgT1MgY2FuCnJlc2NoZWR1bGUgdGhlIHVzZXIgaGFydCB0byBhIGRpZmZlcmVu dCBwaHlzaWNhbCBoYXJ0IGFmdGVyIHRoZSBGRU5DRS5JLiBUaGlzIHdvdWxkIHJlcXVpcmUgdGhl Ck9TIHRvIGV4ZWN1dGUgYW4gYWRkaXRpb25hbCBGRU5DRS5JIGFzIHBhcnQgb2YgZXZlcnkgY29u dGV4dCBtaWdyYXRpb24uIEZvciB0aGlzIHJlYXNvbiwgdGhlCnN0YW5kYXJkIExpbnV4IEFCSSBo YXMgcmVtb3ZlZCBGRU5DRS5JIGZyb20gdXNlci1sZXZlbCBhbmQgbm93IHJlcXVpcmVzIGEgc3lz dGVtIGNhbGwgdG8KbWFpbnRhaW4gaW5zdHJ1Y3Rpb24tZmV0Y2ggY29oZXJlbmNlLCB3aGljaCBh bGxvd3MgdGhlIE9TIHRvIG1pbmltaXplIHRoZSBudW1iZXIgb2YgRkVOQ0UuSQpleGVjdXRpb25z IHJlcXVpcmVkIG9uIGN1cnJlbnQgc3lzdGVtcyBhbmQgcHJvdmlkZXMgZm9yd2FyZC1jb21wYXRp YmlsaXR5IHdpdGggZnV0dXJlIGltcHJvdmVkCmluc3RydWN0aW9uLWZldGNoIGNvaGVyZW5jZSBt ZWNoYW5pc21zLgoKRnV0dXJlIGFwcHJvYWNoZXMgdG8gaW5zdHJ1Y3Rpb24tZmV0Y2ggY29oZXJl bmNlIHVuZGVyIGRpc2N1c3Npb24gaW5jbHVkZSBwcm92aWRpbmcgbW9yZQpyZXN0cmljdGVkIHZl cnNpb25zIG9mIEZFTkNFLkkgdGhhdCBvbmx5IHRhcmdldCBhIGdpdmVuIGFkZHJlc3Mgc3BlY2lm aWVkIGluIHJzMSwgYW5kL29yIGFsbG93aW5nCnNvZnR3YXJlIHRvIHVzZSBhbiBBQkkgdGhhdCBy ZWxpZXMgb24gbWFjaGluZS1tb2RlIGNhY2hlLW1haW50ZW5hbmNlIG9wZXJhdGlvbnMuIgoKSSBz dGFydCB0byBzdXNwZWN0IHRoYXQgZXZlbiB0aGUgcGVvcGxlIHdvcmtpbmcgb24gdGhlIHJpc2N2 IG1lbW9yeSBtb2RlbCBoYXZlIG5vdGljZWQKdGhhdCBsZXR0aW5nIGEgc2luZ2xlIGluc3RydWN0 aW9uIHN1Y2ggYXMgRkVOQ0UuSSB0YWtlIGNhcmUgb2YgYm90aCBjYWNoZSBjb2hlcmVuY3kKKmFu ZCogZmx1c2ggdGhlIGluc3RydWN0aW9uIHBpcGVsaW5lIHdpbGwgYmUgYSBwZXJmb3JtYW5jZSBi b3R0bGVuZWNrLCBiZWNhdXNlIGl0CmNhbiBvbmx5IGNsZWFyIHRoZSB3aG9sZSBpbnN0cnVjdGlv biBjYWNoZS4KCk90aGVyIGFyY2hpdGVjdHVyZXMgYXJlIGVpdGhlciBjYWNoZS1jb2hlcmVudCwg b3IgaGF2ZSBjYWNoZSBmbHVzaGluZyB3aGljaCBjYW4gYmUKcGVyZm9ybWVkIG9uIGEgcmFuZ2Ug b2YgYWRkcmVzc2VzLiBUaGlzIGlzIGtlcHQgYXBhcnQgZnJvbSB3aGF0ZXZlciBpbnN0cnVjdGlv bgpmbHVzaGVzIHRoZSBpbnN0cnVjdGlvbiBwaXBlbGluZSBvZiB0aGUgcHJvY2Vzc29yLgoKQnkg a2VlcGluZyBpbnN0cnVjdGlvbiBjYWNoZSBmbHVzaGluZyBzZXBhcmF0ZSBmcm9tIGluc3RydWN0 aW9uIHBpcGVsaW5lIGZsdXNoLCB3ZSBjYW4KbGV0IG1lbWJhcnJpZXIgKGFuZCBjb250ZXh0IHN3 aXRjaGVzLCBpbmNsdWRpbmcgdGhyZWFkIG1pZ3JhdGlvbikgb25seSBjYXJlIGFib3V0IHRoZQpp bnN0cnVjdGlvbiBwaXBlbGluZSBwYXJ0LCBhbmQgbGVhdmUgaW5zdHJ1Y3Rpb24gY2FjaGUgZmx1 c2ggdG8gZWl0aGVyIGEgZGVkaWNhdGVkCnN5c3RlbSBjYWxsLCBvciB0byBzcGVjaWFsaXplZCBp bnN0cnVjdGlvbnMgd2hpY2ggYXJlIGF2YWlsYWJsZSBmcm9tIHVzZXItbW9kZS4KCkNvbnNpZGVy aW5nIHRoYXQgRkVOQ0UuSSBpcyBmb3JjZWQgdG8gaW52YWxpZGF0ZSB0aGUgd2hvbGUgaS1jYWNo ZSwgSSBkb24ndCB0aGluayB5b3UKd2lsbCBnZXQgYXdheSB3aXRoIGV4ZWN1dGluZyBpdCBmcm9t IHN3aXRjaF9tbSB3aXRob3V0IG1ha2luZyBwZXJmb3JtYW5jZSBnbyBkb3duIHRoZQpkcmFpbiBv biBjYWNoZSBpbmNvaGVyZW50IGltcGxlbWVudGF0aW9ucy4KCkluIG15IG9waW5pb24sIHdoYXQg d2Ugd291bGQgbmVlZCBmcm9tIFJJU0MtViBmb3IgbWVtYmFycmllciAoYW5kIGNvbnRleHQgc3dp dGNoKSBpcyBhCmxpZ2h0d2VpZ2h0IHZlcnNpb24gb2YgRkVOQ0UuSSB3aGljaCBvbmx5IGZsdXNo ZXMgdGhlIGluc3RydWN0aW9uIHBpcGVsaW5lIG9mIHRoZSBsb2NhbApwcm9jZXNzb3IuIFRoaXMg c2hvdWxkIGlkZWFsbHkgY29tZSB3aXRoIGEgd2F5IGZvciBhcmNoaXRlY3R1cmVzIHdpdGggaW5j b2hlcmVudCBjYWNoZXMKdG8gZmx1c2ggdGhlIHJlbGV2YW50IGFkZHJlc3MgcmFuZ2VzIG9mIHRo ZSBpLWNhY2hlIHdoaWNoIGFyZSBtb2RpZmllZCBieSBhIEpJVC4gVGhpcwppLWNhY2hlIGZsdXNo IHdvdWxkIG5vdCBiZSByZXF1aXJlZCB0byBmbHVzaCB0aGUgaW5zdHJ1Y3Rpb24gcGlwZWxpbmUs IGFzIGl0IGlzIHR5cGljYWwKdG8gYmF0Y2ggaW52YWxpZGF0aW9uIG9mIHZhcmlvdXMgYWRkcmVz cyByYW5nZXMgdG9nZXRoZXIgYW5kIGlzc3VlIGEgc2luZ2xlIGluc3RydWN0aW9uCnBpcGVsaW5l IGZsdXNoIG9uIGVhY2ggQ1BVIGF0IHRoZSBlbmQuIFRoZSBpLWNhY2hlIGZsdXNoIGNvdWxkIGVp dGhlciBiZSBkb25lIGJ5IG5ldwppbnN0cnVjdGlvbnMgYXZhaWxhYmxlIGZyb20gdXNlci1zcGFj ZSAoc2ltaWxhciB0byBhYXJjaDY0KSwgb3IgdGhyb3VnaCBwcml2aWxlZ2VkCmluc3RydWN0aW9u cyBhdmFpbGFibGUgdGhyb3VnaCBzeXN0ZW0gY2FsbHMgKHNpbWlsYXIgdG8gYXJtIGNhY2hlZmx1 c2gpLgoKVGhhbmtzLAoKTWF0aGlldQoKCj4gCj4gICAgQW5kcmVhCgotLSAKTWF0aGlldSBEZXNu b3llcnMKRWZmaWNpT1MgSW5jLgpodHRwczovL3d3dy5lZmZpY2lvcy5jb20KCgpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1yaXNjdiBtYWlsaW5n IGxpc3QKbGludXgtcmlzY3ZAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFk ZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LXJpc2N2Cg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2AA0DC001DE for ; Fri, 4 Aug 2023 18:05:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229838AbjHDSFH (ORCPT ); Fri, 4 Aug 2023 14:05:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41830 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229570AbjHDSFF (ORCPT ); Fri, 4 Aug 2023 14:05:05 -0400 Received: from smtpout.efficios.com (smtpout.efficios.com [167.114.26.122]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 106AC46A3 for ; Fri, 4 Aug 2023 11:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=efficios.com; s=smtpout1; t=1691172302; bh=VHBir7999qQ/5qjfN/1N+4Xr5C/fghWazsI01lj3bq0=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=BKXCI30TCLRoc/dHYnRk74jGhjC6o38c8FfkDKAy1H3oGeXMy27XEAJX+8DuR+njg rc+VAc5q3KOZl2r30ifupkrhSo7Bhx25Kzj3nfmpz/QypRQmuEBMA9+0GQGukJzqFQ vVlRxa+xlYibD5ulDqy9s1BITu/WbGJXe+CK7VqVPBDdTh228Bwwu5/eKLTg4ZwwlC NNrUC7URVx4TdAbSQ8cvb/Ql8CCOWug718ZJmTN0ewzB/uNoHorjecrBR2mh0+k+aY 4XEn2MzI+Uq/AihSfDR4Cqylyr3mFZs3bXjAFeSQh0X5prrS1R47dthyJZKgYIOFRN Qr12Vkl7M147A== Received: from [IPV6:2605:59c8:2711:c800::c66] (unknown [IPv6:2605:59c8:2711:c800::c66]) by smtpout.efficios.com (Postfix) with ESMTPSA id 4RHYXG1Cx3z1KW8; Fri, 4 Aug 2023 14:05:02 -0400 (EDT) Message-ID: Date: Fri, 4 Aug 2023 14:05:55 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [RFC PATCH] membarrier: riscv: Provide core serializing command Content-Language: en-US To: Andrea Parri Cc: paulmck@kernel.org, paul.walmsley@sifive.com, palmer@dabbelt.com, aou@eecs.berkeley.edu, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, mmaas@google.com, hboehm@google.com, striker@us.ibm.com References: <20230803040111.5101-1-parri.andrea@gmail.com> <4bf79f06-4593-134a-04dd-b8f89e96a1b8@efficios.com> <65350c17-3fcf-a057-a280-f6a5d36dcb21@efficios.com> From: Mathieu Desnoyers In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/4/23 10:59, Andrea Parri wrote: >> What is the relationship between FENCE.I and instruction cache flush on >> RISC-V ? > > The exact nature of this relationship is implementation-dependent. From > commentary included in the ISA portion referred to in the changelog: > > A simple implementation can flush the local instruction cache and > the instruction pipeline when the FENCE.I is executed. A more > complex implementation might snoop the instruction (data) cache on > every data (instruction) cache miss, or use an inclusive unified > private L2 cache to invalidate lines from the primary instruction > cache when they are being written by a local store instruction. If > instruction and data caches are kept coherent in this way, or if > the memory system consists of only uncached RAMs, then just the > fetch pipeline needs to be flushed at a FENCE.I. [..] > > Mmh, does this help? Quoting https://github.com/riscv/riscv-isa-manual/releases/download/Ratified-IMAFDQC/riscv-spec-20191213.pdf Chapter 3 "“Zifencei” Instruction-Fetch Fence, Version 2.0" "First, it has been recognized that on some systems, FENCE.I will be expensive to implement and alternate mechanisms are being discussed in the memory model task group. In particular, for designs that have an incoherent instruction cache and an incoherent data cache, or where the instruction cache refill does not snoop a coherent data cache, both caches must be completely flushed when a FENCE.I instruction is encountered. This problem is exacerbated when there are multiple levels of I and D cache in front of a unified cache or outer memory system. Second, the instruction is not powerful enough to make available at user level in a Unix-like operating system environment. The FENCE.I only synchronizes the local hart, and the OS can reschedule the user hart to a different physical hart after the FENCE.I. This would require the OS to execute an additional FENCE.I as part of every context migration. For this reason, the standard Linux ABI has removed FENCE.I from user-level and now requires a system call to maintain instruction-fetch coherence, which allows the OS to minimize the number of FENCE.I executions required on current systems and provides forward-compatibility with future improved instruction-fetch coherence mechanisms. Future approaches to instruction-fetch coherence under discussion include providing more restricted versions of FENCE.I that only target a given address specified in rs1, and/or allowing software to use an ABI that relies on machine-mode cache-maintenance operations." I start to suspect that even the people working on the riscv memory model have noticed that letting a single instruction such as FENCE.I take care of both cache coherency *and* flush the instruction pipeline will be a performance bottleneck, because it can only clear the whole instruction cache. Other architectures are either cache-coherent, or have cache flushing which can be performed on a range of addresses. This is kept apart from whatever instruction flushes the instruction pipeline of the processor. By keeping instruction cache flushing separate from instruction pipeline flush, we can let membarrier (and context switches, including thread migration) only care about the instruction pipeline part, and leave instruction cache flush to either a dedicated system call, or to specialized instructions which are available from user-mode. Considering that FENCE.I is forced to invalidate the whole i-cache, I don't think you will get away with executing it from switch_mm without making performance go down the drain on cache incoherent implementations. In my opinion, what we would need from RISC-V for membarrier (and context switch) is a lightweight version of FENCE.I which only flushes the instruction pipeline of the local processor. This should ideally come with a way for architectures with incoherent caches to flush the relevant address ranges of the i-cache which are modified by a JIT. This i-cache flush would not be required to flush the instruction pipeline, as it is typical to batch invalidation of various address ranges together and issue a single instruction pipeline flush on each CPU at the end. The i-cache flush could either be done by new instructions available from user-space (similar to aarch64), or through privileged instructions available through system calls (similar to arm cacheflush). Thanks, Mathieu > > Andrea -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com