[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 2/2] x86/HVM: cache attribute pinning adjustments
On Thu, Mar 03, 2016 at 12:12:40PM +0000, Andrew Cooper wrote: > On 03/03/16 12:10, Wei Liu wrote: > > On Thu, Mar 03, 2016 at 11:03:43AM +0000, Andrew Cooper wrote: > > [...] > >>> @@ -587,20 +578,21 @@ static void free_pinned_cacheattr_entry( > >>> xfree(container_of(rcu, struct hvm_mem_pinned_cacheattr_range, rcu)); > >>> } > >>> > >>> -int32_t hvm_set_mem_pinned_cacheattr( > >>> - struct domain *d, > >>> - uint64_t gfn_start, > >>> - uint64_t gfn_end, > >>> - uint32_t type) > >>> +int hvm_set_mem_pinned_cacheattr(struct domain *d, uint64_t gfn_start, > >>> + uint64_t gfn_end, uint32_t type) > >>> { > >>> struct hvm_mem_pinned_cacheattr_range *range; > >>> int rc = 1; > >>> > >>> - if ( !is_hvm_domain(d) || gfn_end < gfn_start ) > >>> - return 0; > >>> + if ( !is_hvm_domain(d) ) > >>> + return -EOPNOTSUPP; > >> You introduce an asymmetry between set and get here, both in terms of > >> the checks (hvm vs hvm_container), and assert vs plain failure. Why is > >> this? > >> > >> I would suggest ASSERT(is_hvm_domain(d)) in both cases. > >> > > I don't think we can have ASSERT() in the set function because it might > > be called by untrusted entity. On the other hand, the get function can > > only be used by hypervisor so the ASSERT should be fine. > > The hypercall handler should sanitise the untrusted caller before we get > into this function. > I don't disagree. It is just that this seems undone at the moment -- I don't see xsm hook in the callsite of this function in domctl. Wei. > ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |