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

[Paul Durrant <xadimgnik@xxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich <jbeulich@xxxxxxxx>
> Sent: 24 June 2020 13:52
> To: Julien Grall <julien@xxxxxxx>
> Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx; 
> paul@xxxxxxx; Andrew
> Cooper <andrew.cooper3@xxxxxxxxxx>; George Dunlap <george.dunlap@xxxxxxxxxx>; 
> Ian Jackson
> <ian.jackson@xxxxxxxxxxxxx>; Stefano Stabellini <sstabellini@xxxxxxxxxx>; Wei 
> Liu <wl@xxxxxxx>
> Subject: Re: [PATCH for-4.14] mm: fix public declaration of struct 
> xen_mem_acquire_resource
> 
> 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.

How would the pages get mapped into process address space if the kernel doesn't 
know what's being done?

  Paul

> 
> Jan