[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |