> -----Original Message----- > From: Jan Beulich <jbeul...@suse.com> > Sent: 24 June 2020 13:52 > To: Julien Grall <jul...@xen.org> > Cc: Roger Pau Monné <roger....@citrix.com>; xen-devel@lists.xenproject.org; > p...@xen.org; Andrew > Cooper <andrew.coop...@citrix.com>; George Dunlap <george.dun...@citrix.com>; > Ian Jackson > <ian.jack...@eu.citrix.com>; Stefano Stabellini <sstabell...@kernel.org>; Wei > Liu <w...@xen.org> > 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