Re: [Xen-devel] [PATCH v9 10/11] common: add a new mappable resource type: XENMEM_resource_grant_table

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 11 October 2017 10:43
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; George Dunlap
> <George.Dunlap@xxxxxxxxxx>; Ian Jackson <Ian.Jackson@xxxxxxxxxx>; Wei Liu
> <wei.liu2@xxxxxxxxxx>; Stefano Stabellini <sstabellini@xxxxxxxxxx>; xen-
> devel@xxxxxxxxxxxxxxxxxxxx; KonradRzeszutek Wilk
> <konrad.wilk@xxxxxxxxxx>; Tim (Xen.org) <tim@xxxxxxx>
> 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.Durrant@xxxxxxxxxx> wrote:
> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> Sent: 11 October 2017 09:47
> >> >>> On 10.10.17 at 18:01, <Paul.Durrant@xxxxxxxxxx> 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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel