bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PCI arbiter memory mapping


From: Samuel Thibault
Subject: Re: PCI arbiter memory mapping
Date: Mon, 16 Aug 2021 23:10:42 +0200
User-agent: NeoMutt/20170609 (1.8.3)

Sergey Bugaev, le mar. 17 août 2021 00:07:29 +0300, a ecrit:
> On Mon, Aug 16, 2021 at 11:43 PM Samuel Thibault
> <samuel.thibault@gnu.org> wrote:
> > Here, possibly proxies can indeed work properly. But please do look at
> > what Joan's situation is to make sure it does.
> 
> I don't think I understand enough about the situation. It would help
> if you or Joan were to kindly give me some more context :)
> 
> As I understand it, there's the PCI arbiter, which is a translator
> that arbitrates access to PCI, which is a hardware bus that various
> devices can be connected to. The hardware devices connected via PCI
> are available (to the PCI arbiter) as Mach devices, and in particular
> it's possible to use device_map () and then vm_map () to access the
> device memory. Then there's libpciaccess whose Hurd backend uses the
> files exported by the PCI arbiter to get access to the PCI, including
> mapping device memory. Naturally its user can request read-only or
> read-write mapping, but the PCI arbiter may decide to only return a
> read-only memory object (a proxy to the device pager), in which case
> libpciaccess should deallocate the port and return EPREM, or the PCI
> arbiter may return the real device pager.
> 
> Is that right?

Yes, and we want to implement nesting: providing a sub-hurd with a
partial view of the PCI space.

Samuel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]