|
[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 |