Re: PCI arbiter memory mapping

[Samuel Thibault]

Sergey Bugaev, le mar. 17 août 2021 00:30:34 +0300, a ecrit:
> On Tue, Aug 17, 2021 at 12:10 AM Samuel Thibault
> <samuel.thibault@gnu.org> wrote:
> > Yes, and we want to implement nesting: providing a sub-hurd with a
> > partial view of the PCI space.
> 
> Interesting. But I still don't think I understand what the problem you
> are running into.

Please look at the actual source code, I'm sorry I just don't have time
to spend on paraphrasing the thorough story.

The root pci-arbiter uses libpciaccess' x86 backend to access PCI, and
x86_pci.c which uses mmap(/dev/mem) to map PCI BARs. pci-arbiter wants
to expose them in /servers/bus/pci, but for that it needs a memory
object. In the current branches of Joan the memory object is passed
under the hood between libpciaccess and pci-arbiter, but we want to
avoid such horrible thing.

Then there is the sub-arbiter, which gets its mapping from libpciaccess'
hurd backend, whose underlying memory object behaves differently
(because the mem device does not implement yet the offset feature, while
the memory object proxy does). And thus his current has a bad-looking
"if I'm dealing with a proxy rather than a device" which we'd really
want to avoid.

Again, the devil lies in the details.

> (Hmm, how does I/O port access work in a subhurd? I'm guessing the
> subhurd has to be privileged?

The I/O port access tokens can be provided to the subhurd.

> But then it probably has to anyway, to access the PCI devices?)

It can access them through the memory maps provided by the pci-arbiter.

Samuel