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.thiba...@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
