From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751744AbdF0AHc convert rfc822-to-8bit (ORCPT ); Mon, 26 Jun 2017 20:07:32 -0400 Received: from hqemgate14.nvidia.com ([216.228.121.143]:8542 "EHLO hqemgate14.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751551AbdF0AHX (ORCPT ); Mon, 26 Jun 2017 20:07:23 -0400 X-PGP-Universal: processed; by hqpgpgate102.nvidia.com on Mon, 26 Jun 2017 17:07:22 -0700 From: Daniel Lustig To: Palmer Dabbelt , "will.deacon@arm.com" CC: "peterz@infradead.org" , "linux-arch@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Arnd Bergmann , Olof Johansson , "albert@sifive.com" , "patches@groups.riscv.org" Subject: RE: [PATCH 13/17] RISC-V: Add include subdirectory Thread-Topic: [PATCH 13/17] RISC-V: Add include subdirectory Thread-Index: AQHS7rf3+2R6Zx188kypapDqCt5uNqI3t7JQ Date: Tue, 27 Jun 2017 00:07:20 +0000 Message-ID: <8709419e3d964b86b025bb35a6b55440@HQMAIL105.nvidia.com> References: <20170607131611.GF30263@arm.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.17.171.11] MIME-Version: 1.0 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > https://github.com/riscv/riscv-isa-manual/releases/download/riscv-user > > -2.2/riscv-spec-v2.2.pdf > > That's the most up to date spec. Yes, that's the most up to date public spec. Internally, the RISC-V memory model task group has been working on fixing the memory model spec for the past couple of months now. We're aiming to release it for public review well before the end of the year. Hopefully in the coming weeks even. > > which, on the one hand is reassuring (because ignoring dependency > > ordering is plain broken), but on the other it doesn't go quite far > > enough in defining exactly what constitutes a "syntactic data > > dependency". The cumulativity of your fences also needs defining, > > because I think this was up in the air at some point and the document > > above doesn't seem to tackle it (it doesn't seem to describe what > > constitutes being a memory of the predecessor or successor sets) That will all covered in the new spec. > > P.S. You should also totally get your architects to write a formal > > model ;) Also in progress :) Were there any more specific questions I can answer in the meantime? Or any specific concern you'd like to point me to? Dan