[ofw] typical values for ci_umv_buf_t

[Sean Hefty]

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

I'm trying to understand the requirements of the userspace verbs library and the
kernel HCA driver, not IBALs requirements.  For example, how the ci_umv_buf_t
data is conveyed to or from the kernel is an implementation issue.  Command is
only passed to the kernel, and status is only returned from the kernel.  I would
expect the verbs library to ignore command in a post() call, and the kernel
driver to ignore status.

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

Again, I'm asking about the requirements from the perspective of the HCA driver.

- Sean