Re: PCI arbiter memory mapping

[Samuel Thibault]

Sergey Bugaev, le lun. 16 août 2021 21:59:47 +0300, a ecrit:
> On Mon, Aug 16, 2021 at 9:17 PM Samuel Thibault <samuel.thibault@gnu.org> 
> wrote:
> > > > I'd rather see a
> > > > hurd-specific libpciaccess function to get the pager.
> > >
> > > That's better, but we'd have to add that function in both hurd_pci.c and
> > > x86_pci.c. I don't like the idea of adding Hurd specific code to 
> > > x86_module
> > > but there's already a lot of it and we could avoid the existence of struct
> > > pci_user_data, which I like even less.
> >
> > Actually I'm thinking that this is just another case of mremap(). The
> > underlying question is getting the memory object of a given memory
> > range, like vm_region does. We need to be careful since we don't want
> > any process to be able to get the memory object of any other process,
> > but it does make sense, and would be useful for mremap.
> 
> IMO the proper way to get mremap () is vm_remap ()

But that doesn't answer Joan's need for getting a memory object, to be
able to put a proxy memory object on top of it to make it read-only.

> This makes me think of something cooler though: what if there was an
> API to create a proxy memory object from a (task, address, size)
> triple?

That wouldn't answer his need either: we don't want to access the task
content, we want to access the underlying (PCI-mmapped) memory object.

> routine vm_create_proxy (
>     target_task : vm_task_t;
>     address : vm_address_t;
>     size : vm_size_t;
>     out proxy : memory_object_t);
> 
> Then mremap () could be implemented like this:
> 
> vm_create_proxy (mach_task_self (), old_address, old_size, &proxy);
> vm_deallocate (mach_task_self (), old_address, old_size);
> vm_map (mach_task_self (), new_address, new_size, ..., proxy, ...);
> mach_port_deallocate (mach_task_self (), proxy);

But then it'll create a pile of proxies if the application calls mremap
several times, which I guess some applications will happily try to do.

Samuel