Re: PCI arbiter memory mapping

[Sergey Bugaev]

On Tue, Aug 17, 2021 at 12:38 AM Samuel Thibault
<samuel.thibault@gnu.org> wrote:
> The root pci-arbiter uses libpciaccess' x86 backend to access PCI

On Tue, Aug 17, 2021 at 9:47 PM Joan Lledó <jlledom@mailfence.com> wrote:
> Yes, and the arbiter can play two roles: root arbiter, which uses x86
> module in libpciacces; and nested arbiter, which uses the hurd module in
> libpciaccess.
>
> > The hardware devices connected via PCI are available (to the PCI arbiter)
> > as Mach devices
>
> Actually, the devices are available to the arbiter as libpciaccess devices

Thank you both for explaining, this is the part that I was missing:
that the arbiter itself uses libpciaccess, and that it cannot map the
devices directly, it has to map /dev/mem.

To me it sounds like libpciaccess should have a Hurd-specific API
addition that would let the user get the memory object backing the
mapping created by device_map_region (). I.e., device_map_region () is
a cross-platform API that maps the device memory into your address
space (right?), but on the Hurd there'd also be a way to actually get
the memory object it would map (and map it yourself if you so choose,
or do something else).

It would be the job of that libpciaccess API to make this object have
the right offset and everything, so that the caller wouldn't have to
worry about that. If I understand this right, its Hurd backend already
gets the memory object with the right offset and size, and would
return that directly; while the x86 backend would either have to use
the unimplemented-as-of-now offset parameter in device_map (), or
create and return an appropriate proxy from that API.

In memory_object_create_proxy (), the kernel would take care of
short-circuiting nested proxy creation to make that a non-issue. This
will allow netfs_get_filemap (VM_PROT_READ) to create another proxy
just for enforcing read-only access without worrying that the object
might already be a proxy.

Does that sound remotely sensible? :)
Please keep in mind that while (I think) I understand Mach VM, I have
very little idea about PCI. I'm (obviously) not in a position to
decide what's best for libpciaccess and the PCI arbiter.

Sergey