>>> On 17.10.17 at 10:30, <paul.durr...@citrix.com> wrote: >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 17 October 2017 07:43 >> >>> Paul Durrant <paul.durr...@citrix.com> 10/12/17 6:28 PM >>> >> >+int gnttab_get_grant_frame(struct domain *d, unsigned long idx, >> >+ mfn_t *mfn) >> >+{ >> >+ struct grant_table *gt = d->grant_table; >> >+ int rc; >> >+ >> >+ /* write lock required as version may change and/or table may grow */ >> >+ grant_write_lock(gt); >> >+ >> >+ rc = (gt->gt_version == 2 && >> >+ idx > XENMAPIDX_grant_table_status) ? >> >> I don't understand this check - why does XENMAPIDX_grant_table_status >> matter here at all? Same in gnttab_get_status_frame() then. >> > > Well, the current legal range of grant table frames for v2 is 0 - (1 << > XENMAPIDX_grant_table_status) whereas it appears that for v1 there is no > limit. As for status frames, they are a v2-only concept but I agree that the > range check there is wrong.
I don't think the range limitation from the other interface should impose any restriction for this new one. Oh, one other thing I only notice now - could you please also attach a brief comment to the array that you grow to 32 entries making clear that this is a pretty arbitrary choice? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
