[ofw] typical values for ci_umv_buf_t

[Fab Tillier]

>
>>typedef struct _umv_buf
>>{
>>       uint32_t                command;
>>       uint32_t                status;
>>       uint32_t                input_size;
>>       uint32_t                output_size;
>>       void* __ptr64   p_inout_buf;
>>} ci_umv_buf_t;
>
>More questions:
>
>Are command and status always valid, or only valid if either input_size or
>output_size are non-zero?  (I'm assuming always valid, but wanted to check.)

Yes, at least that's the intent.  Note that a command of zero isn't a reserved value, and there's also no requirement for command to be any particular value to indicate that p_inout_buf is valid.  Other than copying/marshalling the p_inout_buf in the proxy, IBAL doesn't touch/interpret the contents.

>If there's no pre-IOCTL call, do the fields need to be initialized with respect
>to the kernel HCA driver?

Are there cases where there's a pre-IOCTL call but not a post-IOCTL call?  I would expect things to go poorly if you use uninitialized memory.  Specifically, the kernel proxy code that marshals the p_inout_buf would detect a bad pointer if input_size or output_size where non-zero and p_inout_buf was non-zero too (unless you get 'lucky' and p_inout_buf is a valid pointer in the app's memory space, and input_size and output_size are valid for that buffer.)

>Also, there's the following comment in ib_ci.h:
>
>*       In the Infiniband Access Layer, it is important to know the
>*       usage of umv_buf and whether the contents of the p_inout_buf
>*       can have embedded user-mode pointers. When invoked from an
>*       arbitrary thread context, Vendor driver can NOT access user-mode
>*       pointers of a user-process.
>
>Does this imply that the HCA driver supports being called from an arbitrary
>thread context, or must it be called from the user's thread context directly?

IBAL has the requirement that all IOCTLs be done in the context of the application's thread.  This allows it to perform memory registration and other such calls where being in the app's thread context is required.  For other requests, if things get pushed to a async callback work item, you can't dereference embedded pointers in the p_inout_buf.  So whether you can be called from arbitrary context depends on the usage of the p_inout_buf.

-Fab