[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.