> -----Original Message----- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 11 October 2017 10:43 > To: Paul Durrant <paul.durr...@citrix.com> > Cc: Andrew Cooper <andrew.coop...@citrix.com>; George Dunlap > <george.dun...@citrix.com>; Ian Jackson <ian.jack...@citrix.com>; Wei Liu > <wei.l...@citrix.com>; Stefano Stabellini <sstabell...@kernel.org>; xen- > de...@lists.xenproject.org; KonradRzeszutek Wilk > <konrad.w...@oracle.com>; Tim (Xen.org) <t...@xen.org> > Subject: RE: [Xen-devel] [PATCH v9 10/11] common: add a new mappable > resource type: XENMEM_resource_grant_table > > >>> On 11.10.17 at 10:54, <paul.durr...@citrix.com> wrote: > >> From: Jan Beulich [mailto:jbeul...@suse.com] > >> Sent: 11 October 2017 09:47 > >> >>> On 10.10.17 at 18:01, <paul.durr...@citrix.com> wrote: > >> >> > @@ -993,6 +1018,11 @@ static int acquire_resource(const > >> >> xen_mem_acquire_resource_t *xmar) > >> >> > xmar->nr_frames, mfn_list); > >> >> > break; > >> >> > > >> >> > + case XENMEM_resource_grant_table: > >> >> > + rc = acquire_grant_table(d, xmar->id, xmar->frame, > >> >> > + xmar->nr_frames, mfn_list); > >> >> > + break; > >> >> > >> >> Is this really generally useful with mfn_list[] having just two entries? > >> >> > >> > > >> > Good point. I'll increase the size of the array in this patch (to the > >> > default table size of 32... I think that's a reasonable value to choose). > >> > >> I suppose for the only current use you have for this (seeding the > >> grant table from the tool stack) even the two entries you have > >> right now would suffice. If, however, a full grant table is supposed > >> to be accessible this way, I can't see how a static upper limit will do. > >> Or if you intend the caller to do multiple invocations in such a case, > >> there ought to be a way to find out the (implementation) limit. > > > > I'm open to ideas but there clearly needs to be some sort of upper limit, or > > we do away with being able to map multiple frames in a single invocation. > The > > dm_op hypercalls currently have a similar upper limit on the size of the > > buffer array. I'd rather not have to introduce another hypercall just to > > find > > out such a thing. It's a tools-only hypercall so could I not just add a > > comment on what the limit currently is? > > Hmm, that would be an option, but I'd prefer if we could get away > without. And no, I wasn't suggesting to introduce yet another > hypercall. Instead how about the handle being a null one asking > for the implementation limit to be returned in nr_frames (or, to > keep that IN only, in the re-purposed pad field)? >
Ok, I'll make nr_frames IN/OUT. I guess I could define it to be set to the implementation limit if the hypercall returns -E2BIG. Paul > Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
