|
[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |