Re: [PATCH for-4.14] mm: fix public declaration of struct xen_mem_acquire_resource

[Jan Beulich <jbeulich@suse.com>]

On 24.06.2020 14:47, Julien Grall wrote:
> Hi,
> 
> On 24/06/2020 13:08, Jan Beulich wrote:
>> On 24.06.2020 12:52, Julien Grall wrote:
>>> Hi Jan,
>>>
>>> On 24/06/2020 11:05, Jan Beulich wrote:
>>>> On 23.06.2020 19:32, Roger Pau Monné wrote:
>>>>> On Tue, Jun 23, 2020 at 05:04:53PM +0200, Jan Beulich wrote:
>>>>>> On 23.06.2020 15:52, Roger Pau Monne wrote:
>>>>>>> XENMEM_acquire_resource and it's related structure is currently inside
>>>>>>> a __XEN__ or __XEN_TOOLS__ guarded section to limit it's scope to the
>>>>>>> hypervisor or the toolstack only. This is wrong as the hypercall is
>>>>>>> already being used by the Linux kernel at least, and as such needs to
>>>>>>> be public.
>>>>>>
>>>>>> Actually - how does this work for the Linux kernel, seeing
>>>>>>
>>>>>>       rc = rcu_lock_remote_domain_by_id(xmar.domid, &d);
>>>>>>       if ( rc )
>>>>>>           return rc;
>>>>>>
>>>>>>       rc = xsm_domain_resource_map(XSM_DM_PRIV, d);
>>>>>>       if ( rc )
>>>>>>           goto out;
>>>>>>
>>>>>> in the function?
>>>>>
>>>>> It's my understanding (I haven't tried to use that hypercall yet on
>>>>> FreeBSD, so I cannot say I've tested it), that xmar.domid is the
>>>>> remote domain, which the functions locks and then uses
>>>>> xsm_domain_resource_map to check whether the current domain has
>>>>> permissions to do privileged operations against it.
>>>>
>>>> Yes, but that's a tool stack operation, not something the kernel
>>>> would do all by itself. The kernel would only ever pass DOMID_SELF
>>>> (or the actual local domain ID), I would think.
>>>
>>> You can't issue that hypercall directly from userspace because you need
>>> to map the page in the physical address space of the toolstack domain.
>>>
>>> So the kernel has to act as the proxy for the hypercall. This is
>>> implemented as mmap() in Linux.
>>
>> Oh, and there's no generic wrapping available here, unlike for
>> dmop. 
> 
> It is not clear to me the sort of generic wrapping you are referring to. 
> Are you referring to a stable interface for an application?
> 
>> Makes me wonder whether, for this purpose, there should
>> be (have been) a new dmop with identical functionality, to
>> allow such funneling.
> 
> I am not sure how using DMOP will allow us to implement it fully in 
> userspace. Do you mind expanding it?

dmop was designed so that a kernel proxying requests wouldn't need
updating for every new request added to the interface. If the
request here was made through a new dmop, the kernel would never
have had a need to know of an interface structure that's of no
interest to it, but only to the tool stack.

Jan