From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 79742 invoked by alias); 3 Mar 2017 16:00:46 -0000 Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: gnu-gabi-owner@sourceware.org Received: (qmail 73583 invoked by uid 89); 3 Mar 2017 16:00:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=guideline, flexibility, 02-Mar-2017, 02-mar-2017 X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mail-qk0-f171.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=haKPwl+t5/Jfr7QM71vYAmPtgfiD8xZlKhIxt5MAb4g=; b=IYyIf/kKJQlPsQhBfHLuUjVD8SpnC8r7WpvRutefFKKYGaWGtZXXlgkaLyvYx4RF4i 37OzJps8tGxvzO8fYQ37C0b+NWNGzQdWlVNjqNEiU/0KIoljRw89jDhdhzqdV1CmUQqO n0rbnytrV4oCVzuHlWdK+Z1esDTMkCqvuyJ6oIq1PNVAK+Lz6fqoKrWq3yIoYz5svzP/ b12xtnnBC7VLCRp8bmkHT03B3ZZgyzCgSsDr/ubkoSDNmqQqCTUmFWxyNDkFnFmlPD3c xBK/jNQYjiKMUKxshyNeKyLwUB9JunNMiAMb9eYCb6glHv5YjlMcGaofCDZ+6NrRFMm8 4MmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=haKPwl+t5/Jfr7QM71vYAmPtgfiD8xZlKhIxt5MAb4g=; b=R7cg1CLyxtrdGtDWsQt4eZdRoS8Ndws8MT3DNodx9DqcD3wak70HMYEsOeun1bZqn1 sqCVKBlPvqUt/lO9Rp4SoJgWSVB9x/cLVX0rc3s9rTHazD8giZVPNV9cMEcjnbbWkelK jwKDlbH9jfEEQB/0TCf63Usoi6zhdif0437CCEVnSZiIp6OsJV22sOmJvmdWx9qf/kd1 cQ+Z3uElYVxhJiD/OW79Ap97AHlTafuFpqJ+zJNAmEySirJRI7Ko/mbSoD3WZWA/VuLI HLUaxFmNP4WWJklWsII3L6czzeRa5N9Zth9rQ3o6dFNr+FZGMtEDneeL4ctRfFZis5hL FbFQ== X-Gm-Message-State: AMke39kpYLrgDjroSQ6q8TrO4KOyyx3w3xkv6aj1fz6/SXR6ZoKbE7wGcLu1AhIWI0vjat1h2IrNeqcDHSuxFQ== X-Received: by 10.55.165.81 with SMTP id o78mr3140358qke.34.1488556839802; Fri, 03 Mar 2017 08:00:39 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <88608944-14c9-9d28-80d1-32283521683b@gmail.com> References: <88608944-14c9-9d28-80d1-32283521683b@gmail.com> From: "H.J. Lu" Date: Sun, 01 Jan 2017 00:00:00 -0000 Message-ID: Subject: Re: RFC: ABI support for special memory area To: Suprateeka R Hegde Cc: gnu-gabi@sourceware.org Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2017-q1/txt/msg00010.txt.bz2 On Fri, Mar 3, 2017 at 4:28 AM, Suprateeka R Hegde wrote: > On 02-Mar-2017 09:34 PM, H.J. Lu wrote: >> >> On Thu, Mar 2, 2017 at 7:16 AM, Suprateeka R Hegde >> wrote: >>> >>> On 23-Feb-2017 09:49 PM, H.J. Lu wrote: >>>> >>>> >>>> The default implementation of __gnu_mbind_setup is >>>> >>>> int >>>> __gnu_mbind_setup (unsigned int type, void *addr, size_t length) >>>> { >>>> return 0; >>>> } >>>> >>>> which can be overridden by a different implementation at link-time. >>>> >>> >>> Since this is a design that allows vendor specific extension and >>> implementation, would it OK if we make it more generic? >> >> >> Yes. >> >>> Instead of a fixed 3 arguments (type, addr, len), how about something >>> like a >>> pointer to a generic MBIND_CONTEXT struct (say of type >>> __gnu_mbind_context >>> defined)? And let the implementation define the actual struct. >> >> >> We can add more arguments. But they must be predefined since >> __gnu_mbind_setup is called from ld.so which must know what to >> pass to __gnu_mbind_setup. > > > > >> __gnu_mbind_setup is platform specific. We can pass as >> much as we need to __gnu_mbind_setup. But they have to be fixed. > > > I didnt understand this. Predefined/fixed where and how? As part of the ABI > support? Or part of the implementation? The interface is fixed so that it can be called from ld.so. But its implementation is platform specific. > If it is going to part of ABI, then we need to finalize and define it now. > If it is part of the implementation, then __gnu_mbind_setup must be > documented in the ABI as just a guideline to the implementer. > > What I meant by being generic is to have flexibility in number of arguments. > Here is an incomplete/pseudo code of what I am trying to tell: > > enum __gnu_mbind_instance { > GNU_MBIND_DEFAULT, > GNU_MBIND_OVERRIDDEN > }; > > typedef struct { > __gnu_mbind_instance mb_inst; // mandatory. ABI specified > #ifdef VENDOR_1 > type1 identifier1; // optional implementation defined > type2 identifier2; // optional implementation defined > ... > typeN identifierN; // optional implementation defined > #endif > // Add vendor/implementation as necessary > } __gnu_mbind_context; > > int __gnu_mbind_setup(__gnu_mbind_context*); > > Now, for MCDRAM instance, from my understanding: > > typedef struct { > __gnu_mbind_instance mb_inst; > #ifdef VENDOR_MCDARM > unsigned int type; > void *addr; > size_t length; > #endif > } __gnu_mbind_context; > > int > __gnu_mbind_setup (__gnu_mbind_context* mbind_context) > { > /* Even if real implementation exist, check and allow disabling special > memory bindings */ > if (mbind_context->mb_inst == GNU_MBIND_DEFAULT) { > return 0; > } > else { > // return real_implementation_result; > } > } > > If that is not what you are telling, I want to understand how to use it > vendor specific way. __gnu_mbind_setup is called from ld.so. Since there is only one ld.so, it needs to know what to pass to __gnu_mbind_setup. Not all arguments have to be used by all implementations nor all memory types. > >>> I would like to handle NVM/NVMe (long back I had mentioned about >>> PT_PERSISTENT) through this MBIND and my implementation of handling >>> NVM/NVMe >>> needs more data to be passed to such "setup" functions. >> >> >> I call it MBIND since a MBIND segment is inside a LOAD segment and >> my real __gnu_mbind_setup will call mbind to move a MBIND region to >> a NUMA node after it has been loaded and relocated. We can give it >> a different name if you have a better one. > > > I dont have any comment on this MBIND naming. It sounds good. > > -- > Supra -- H.J.