From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [PATCH v7 2/5] sysctl: Add sysctl interface for querying PCI topology Date: Fri, 24 Apr 2015 13:42:31 -0400 Message-ID: <553A8087.8000107@oracle.com> References: <1429289966-4121-1-git-send-email-boris.ostrovsky@oracle.com> <1429289966-4121-3-git-send-email-boris.ostrovsky@oracle.com> <553611EC0200007800074107@mail.emea.novell.com> <55397047.2080101@oracle.com> <553A0AA6020000780007573E@mail.emea.novell.com> <553A4E7C.90805@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <553A4E7C.90805@oracle.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: ian.campbell@citrix.com, wei.liu2@citrix.com, ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com Cc: elena.ufimtseva@oracle.com, keir@xen.org, andrew.cooper3@citrix.com, dario.faggioli@citrix.com, xen-devel@lists.xen.org, Jan Beulich , dgdegra@tycho.nsa.gov List-Id: xen-devel@lists.xenproject.org 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, 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). > > (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