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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 22.03.18 at 12:55, <paul.durrant@xxxxxxxxxx> wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -3863,6 +3863,35 @@ int mem_sharing_gref_to_gfn(struct grant_table *gt, 
> grant_ref_t ref,
>  }
>  #endif
>  
> +/* caller must hold read or write lock */
> +static int gnttab_get_status_frame_mfn(struct domain *d,
> +                                       unsigned long idx, mfn_t *mfn)
> +{
> +    struct grant_table *gt = d->grant_table;
> +
> +    if ( idx >= nr_status_frames(gt) )
> +        return -EINVAL;
> +
> +    *mfn = _mfn(virt_to_mfn(gt->status[idx]));
> +    return 0;
> +}
> +
> +/* caller must hold write lock */
> +static int gnttab_get_shared_frame_mfn(struct domain *d,
> +                                       unsigned long idx, mfn_t *mfn)
> +{
> +    struct grant_table *gt = d->grant_table;
> +
> +    if ( (idx >= nr_grant_frames(gt)) && (idx < gt->max_grant_frames) )
> +        gnttab_grow_table(d, idx + 1);
> +
> +    if ( idx >= nr_grant_frames(gt) )
> +        return -EINVAL;
> +
> +    *mfn = _mfn(virt_to_mfn(gt->shared_raw[idx]));
> +    return 0;
> +}

I realize the anomaly was there already before, but imo it becomes
more pronounced with the two functions differing in more than just
the shared vs status naming (IOW I find it strange that one grows
the grant table while the other doesn't). This extends to ...

> +int gnttab_get_shared_frame(struct domain *d, unsigned long idx,
> +                            mfn_t *mfn)
> +{
> +    struct grant_table *gt = d->grant_table;
> +    int rc;
> +
> +    grant_write_lock(gt);
> +    rc = gnttab_get_shared_frame_mfn(d, idx, mfn);
> +    grant_write_unlock(gt);
> +
> +    return rc;
> +}
> +
> +int gnttab_get_status_frame(struct domain *d, unsigned long idx,
> +                            mfn_t *mfn)
> +{
> +    struct grant_table *gt = d->grant_table;
> +    int rc;
> +
> +    grant_read_lock(gt);
> +    rc = gnttab_get_status_frame_mfn(d, idx, mfn);
> +    grant_read_unlock(gt);
> +
> +    return rc;
> +}

... these two acquiring the lock in different ways.

And then I'm completely missing the interaction with
gnttab_unpopulate_status_frames(). While this might not be a
practical problem at this point in time, we're liable to forget to
address this later on if there's no stop gap measure. A PV guest
mapping the obtained MFNs is going to be fine, but a HVM/PVH
one isn't, since neither x86 nor ARM refcount pages inserted into
or removed from a domain's p2m. I therefore think you need to
add a is_hvm_domain() check to acquire_grant_table(), with a
suitable fixme comment attached to it.

With that (and despite the noticed anomaly)
Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel