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

[Julien Grall <julien@xxxxxxx>]

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.
Cheers,

--
Julien Grall