Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754626AbdFWXGt (ORCPT ); Fri, 23 Jun 2017 19:06:49 -0400 Received: from ale.deltatee.com ([207.54.116.67]:58884 "EHLO ale.deltatee.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753942AbdFWXGs (ORCPT ); Fri, 23 Jun 2017 19:06:48 -0400 To: Allen Hubbe , "'Jon Mason'" References: <20170615203729.9009-1-logang@deltatee.com> <20170619200659.GA20437@kudzu.us> <9615f074-5b81-210b-eb88-218a59d65198@deltatee.com> <000001d2eb85$daecdea0$90c69be0$@dell.com> <8a1ff94c-8689-0d4c-cc33-7b495daa065a@deltatee.com> <000101d2eba4$b45b1e40$1d115ac0$@dell.com> <000201d2eba8$dade4ac0$909ae040$@dell.com> <4d932597-3592-2ce1-5a5f-cb5ba36a3a93@deltatee.com> <000001d2ec23$2bd9f300$838dd900$@dell.com> <5aa9c438-e152-4caa-2c6d-cbbd130a0eb2@deltatee.com> <000101d2ec53$f2830840$d78918c0$@dell.com> <000301d2ec6c$ffe3d4b0$ffab7e10$@dell.com> Cc: linux-ntb@googlegroups.com, linux-kernel@vger.kernel.org, "'Dave Jiang'" , "'Serge Semin'" , "'Kurt Schwemmer'" , "'Stephen Bates'" , "'Greg Kroah-Hartman'" From: Logan Gunthorpe Message-ID: Date: Fri, 23 Jun 2017 17:06:40 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <000301d2ec6c$ffe3d4b0$ffab7e10$@dell.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 172.16.1.111 X-SA-Exim-Rcpt-To: gregkh@linuxfoundation.org, sbates@raithlin.com, kurt.schwemmer@microsemi.com, fancer.lancer@gmail.com, dave.jiang@intel.com, linux-kernel@vger.kernel.org, linux-ntb@googlegroups.com, jdmason@kudzu.us, Allen.Hubbe@dell.com X-SA-Exim-Mail-From: logang@deltatee.com Subject: Re: New NTB API Issue X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on ale.deltatee.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 893 Lines: 21 On 23/06/17 04:06 PM, Allen Hubbe wrote: > From: Logan Gunthorpe >> But any translation can be >> programmed by any peer. > > That doesn't seem safe. Even though it can be done as you say, would it not be better to have each specific translation under the control of exactly one driver? > > If drivers can reach across and set the translation of any peer bar, they would still need to negotiate among N peers which one sets which other's translation. Yup. In a dual host setup its not a problem seeing only the one peer will ever set any of the memory windows. In the multi-host setup, there has to be implicit or explicit negotiation as to which memory window connects to which peer. The hardware also implements locking so if two peers try to mess with the same translation, the worst that can happen is the last peer's settings will take effect or one peer will see an error. Logan