[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH RFC] tools/libxc, xen/x86: Added xc_set_mem_access_sparse()



>>> On 26.08.16 at 09:40, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
> On 08/26/16 10:18, Jan Beulich wrote:
>>>>> On 26.08.16 at 08:11, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>>> --- a/xen/common/compat/memory.c
>>> +++ b/xen/common/compat/memory.c
>>> @@ -15,7 +15,6 @@ CHECK_TYPE(domid);
>>>  #undef compat_domid_t
>>>  #undef xen_domid_t
>>>  
>>> -CHECK_mem_access_op;
>>>  CHECK_vmemrange;
>> 
>> You can't just delete this line. Some form of replacement is needed:
>> Either you need to introduce compat mode translation, or you need
>> to keep the line and suitably adjust the interface structure (which
>> might be possible considering there's a [tools interface only] use of
>> uint64_aligned_t already).
> 
> I'll look into this. I'm not sure how to go about introducing compat
> mode translation, could you please tell me where to look for an example
> of doing that? Thanks!

Well, the first option to consider should be avoiding translation (and
hence keeping the check macro invocation in place), the more that
this is a tools only interface (you're certainly aware that e.g domctl
and sysctl also avoid translation). Examples of translation can be
found (you could have guessed that) in xen/common/compat/memory.c.

>>> @@ -76,6 +76,17 @@ int mem_access_memop(unsigned long cmd,
>>>          }
>>>          break;
>>>  
>>> +    case XENMEM_access_op_set_access_sparse:
>>> +    {
>>> +        xen_pfn_t *arr = xmalloc_bytes(sizeof(xen_pfn_t) * mao.nr);
>>> +
>>> +        // copy_from_guest(arr, mao.pfn_list, mao.nr);
>> 
>> What is this (wrongly C++ style) comment about? I think this really
>> wasn't meant to be a comment, so RFC or not - how do things work
>> with this commented out? And where is the error checking for the
>> allocation (which btw should be xmalloc_array(), but the need for
>> an allocation here is questionable - the called function would better
>> retrieve the GFNs one by one).
> 
> They don't work, I forgot that comment in (the line should not have been
> commented). I first wrote the patch on Xen 4.6 and there there was no
> CHECK_mem_access_op, so I was just trying to figure out what went wrong
> when I first saw the compile errors and tried this, then left it in
> accidentally.
> 
> Indeed, there should also be a check for allocation failure.
> 
> Do you mean that I would do better to just copy_from_guest(&gfn,
> mao.pfn_list + index, 1) in a for loop that sets mem_access restrictions?

Yes, albeit it is copy_from_guest_offset(&gfn, mao.pfn_list, index, 1).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

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