RFC: ABI support for special memory area

[Suprateeka R Hegde]

On 02-Mar-2017 09:34 PM, H.J. Lu wrote:
> On Thu, Mar 2, 2017 at 7:16 AM, Suprateeka R Hegde
> <hegdesmailbox@gmail.com> 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.

<snip>

> __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?

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.


>> 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