Re: [PATCH v7 2/5] sysctl: Add sysctl interface for querying PCI topology

[Ian Campbell <ian.campbell@citrix.com>]

On Fri, 2015-04-24 at 13:42 -0400, Boris Ostrovsky wrote:
> On 04/24/2015 10:09 AM, Boris Ostrovsky wrote:
> >
> > On 04/24/2015 03:19 AM, Jan Beulich wrote:
> >>>>> On 24.04.15 at 00:20, <boris.ostrovsky@oracle.com> wrote:
> >>> On 04/21/2015 03:01 AM, Jan Beulich wrote:
> >>>>> +                 ((++dev_cnt > 0x3f) && hypercall_preempt_check()) )
> >>>>> +                break;
> >>>>> +        }
> >>>>> +
> >>>>> +        if ( (!ret || (ret == -ENODEV)) &&
> >>>>> +             __copy_field_to_guest(u_sysctl, op, 
> >>>>> u.pcitopoinfo.first_dev) )
> >>>>> +            ret = -EFAULT;
> >>>>> +    }
> >>>>> +    break;
> >>>>> +#endif
> >>>> With the continuation-less model now used I don't think it makes
> >>>> sense to have first_dev and num_devs - for re-invocation all the
> >>>> caller needs to do is increment the buffer pointer suitably. I.e.
> >>>> you can get away with just a count of devices afaict.
> >>>>
> >>> This would require walking xc_hypercall_buffer_t->hbuf. Would 
> >>> something like
> >>>
> >>>       set_xen_guest_handle_raw(sysctl..., (void 
> >>> *)HYPERCALL_BUFFER_AS_ARG(foo) + offset)
> >>>
> >>> be acceptable? I don't think I see anything better.
> >>>
> >>> I thought of adding set_xen_guest_handle_offset() that would look
> >>> similar to set_xen_guest_handle() but then I felt that having this in
> >>> API may not be a good idea since xc_hypercall_buffer_t->hbuf would end
> >>> up pointing to memory that is not allocated for full
> >>> xc_hypercall_buffer_t->sz.
> >> There ought to be a way to create a guest handle from other than
> >> the start of an allocated hypercall buffer, but that's really more a
> >> question for the tool stack folks.
> >
> > Yes, this was question for toolstack people.
> 
> (Adjusted TO/CC to reflect this).

Not sure if I've got the full context but would it be possible to
rearrange things such that libxc was bouncing/unbouncing only the slice
of the input which is needed for the invocation? Perhaps by pushing it
into whichever loop there is.

If not then I think set_xen_guest_handle_offset or perhaps
guest_handle_add_offset (in line with the xen side equivalent) would be
the way to go.

Under no circumstances should set_xen_guest_handle_raw be being used.

Ian.