[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 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. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |