[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> On 29.03.18 at 17:36, <paul.durrant@xxxxxxxxxx> wrote:
> @@ -967,6 +968,54 @@ static long xatp_permission_check(struct domain *d, 
> unsigned int space)
>      return xsm_add_to_physmap(XSM_TARGET, current->domain, d);
>  }
>  
> +static int acquire_grant_table(struct domain *d, unsigned int id,
> +                               unsigned long frame,
> +                               unsigned int nr_frames,
> +                               xen_pfn_t mfn_list[])
> +{
> +    unsigned int i = nr_frames;
> +
> +    /*
> +     * FIXME: It is not currently safe to map grant status frames if they
> +     *        will be inserted into the caller's P2M, because these
> +     *        insertions are not yet properly reference counted.
> +     *        This restriction can be removed when appropriate reference
> +     *        counting is added.
> +     */
> +    if ( paging_mode_translate(current->domain) &&
> +         (id == XENMEM_resource_grant_table_id_status) )
> +        return -EOPNOTSUPP;

I don't understand why this is for status frames only: The refcounting problem
exists in any case (at the very least when the guest goes away but the mapping
domain survives). The ioreq server use is fine because the page gets assigned
to the domain intended to do the mapping.

However, besides tightening the check, there can also be a little bit of
relaxation, I think: At least the hardware domain can do such mappings, as
we trust it anyway (and it won't - for the foreseeable future - go away).

Jan



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.