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

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 04/24/2015 03:19 AM, Jan Beulich wrote:
> > > > On 24.04.15 at 00:20, <boris.ostrovsky@xxxxxxxxxx> 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.

(And my second paragraph was not stated correctly, now that I re-read 
it. I meant to say that my understanding is that API is expected to make 
all safety checks on buffers and with set_xen_guest_handle_offset() that 
I was picturing in my head we could pass in pretty much any pointer. I 
suppose we could check 'hbuf+offset < sz')

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel