Re: PCI arbiter memory mapping

[Sergey Bugaev]

On Wed, Aug 18, 2021 at 8:34 PM Joan Lledó <jlledom@mailfence.com> wrote:
> El 18/8/21 a les 0:13, Sergey Bugaev ha escrit:
> > you can no longer get the underlying memory object with vm_region ()
>
> How so? reading the docs I understood it does:
>
> https://www.gnu.org/software/hurd/gnumach-doc/Memory-Attributes.html
>
> "The port object_name identifies the memory object associated with this
> region"

Yes; the docs could have been clearer about this — and I was myself
confused about this not long ago. What it gives you is a _memory
object name port_ which "identifies" the memory object, in the sense
that you can get name ports for two regions (even from different
tasks) and they'll compare equal if it's the same memory object mapped
into both. And that's about the only thing you can do with the name
port. It's *not* the actual port to the underlying memory object.

> > (Well in fact what actually changed is that gnumach at some point
> > allowed the use of "memory object name ports" in vm_map (), and now
> > once again doesn't.
>
> vm_map does receive  the memory object as parameter:
>
> https://www.gnu.org/software/hurd/gnumach-doc/Mapping-Memory-Objects.html
>
> "memory_object is the port that represents the memory object: used by
> user tasks in vm_map"

Previously, as a GNU Mach extension, you could also pass the memory
object *name* port (one you get from vm_region ()), instead of the
memory object port. But not anymore.

> > It never allowed you to get the actual memory
> > object.)
>
> vm_map receives a memory object, doesn't return it

Yes. What I'm saying is vm_region () gives you the name port, which
previously could be used in vm_map () much like the memory object port
(this was allowed to enable mremap () to be implemented). vm_region ()
never gave out the actual memory object port, but the name port could
be used in vm_map () in a similar way to the real memory object port.

Sergey