[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [v8][PATCH 03/17] introduce XENMEM_reserved_device_memory_map
>>> On 08.12.14 at 07:17, <tiejun.chen@xxxxxxxxx> wrote: > On 2014/12/3 3:47, Konrad Rzeszutek Wilk wrote: >> On Mon, Dec 01, 2014 at 05:24:21PM +0800, Tiejun Chen wrote: >>> @@ -1101,6 +1129,29 @@ long do_memory_op(unsigned long cmd, >>> XEN_GUEST_HANDLE_PARAM(void) arg) >>> break; >>> } >>> >>> +#ifdef HAS_PASSTHROUGH >>> + case XENMEM_reserved_device_memory_map: >>> + { >>> + struct get_reserved_device_memory grdm; >>> + >>> + if ( copy_from_guest(&grdm.map, arg, 1) || >>> + !guest_handle_okay(grdm.map.buffer, grdm.map.nr_entries) ) >>> + return -EFAULT; >>> + >> >> Shouldn't there be an XSM check here? > > I'm not sure, and Jan should be the author for this patch, so Jan can > give you a correct reply. Hmm, not sure: Daniel, does an operation like this need an XSM check? It's not clear whether the absence of such a check in e.g. the handling of XENMEM_memory_map, XENMEM_machphys_mapping, or XENMEM_maximum_ram_page is intentional (and can be used as justification for it to be absent here too - after all the operation is for a domain to find out information about only itself). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |