[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PCI arbiter memory mapping
From: |
Sergey Bugaev |
Subject: |
Re: PCI arbiter memory mapping |
Date: |
Mon, 16 Aug 2021 21:59:47 +0300 |
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 () — basically like
vm_map (), but instead of a memory object to map it takes another
(task, address) pair. OSF (or just Apple's?) Mach has it [0], although
I'd add 'anywhere' and 'unmap_source' flags to that interface.
[0] https://developer.apple.com/documentation/kernel/1585336-vm_remap
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? Then you'd be able to map the new proxy, and there wouldn't be
a need for a separate vm_remap () — all without getting direct access
to the underlying memory object(s).
So, something like this:
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);
(Hmm, but what about increasing the map size? This cannot be done
securely for non-anonimous mappings, can it?)
This could also be used for other fun things, like implementing
/proc/pid/mem in a coherent way. (It can be implemented in a sad way
without this by making a pager that does vm_read () / vm_write () when
asked to retrieve / store a page.)
What do you think?
Sergey
- Re: PCI arbiter memory mapping, Samuel Thibault, 2021/08/04
- Re: PCI arbiter memory mapping, Samuel Thibault, 2021/08/04
- Re: PCI arbiter memory mapping, Joan Lledó, 2021/08/16
- Re: PCI arbiter memory mapping, Samuel Thibault, 2021/08/16
- Re: PCI arbiter memory mapping,
Sergey Bugaev <=
- Re: PCI arbiter memory mapping, Samuel Thibault, 2021/08/16
- Re: PCI arbiter memory mapping, Sergey Bugaev, 2021/08/16
- Re: PCI arbiter memory mapping, Samuel Thibault, 2021/08/16
- Re: PCI arbiter memory mapping, Sergey Bugaev, 2021/08/16
- Re: PCI arbiter memory mapping, Samuel Thibault, 2021/08/16
- Re: PCI arbiter memory mapping, Sergey Bugaev, 2021/08/16
- Re: PCI arbiter memory mapping, Samuel Thibault, 2021/08/16
- Re: PCI arbiter memory mapping, Joan Lledó, 2021/08/17
- Re: PCI arbiter memory mapping, Sergey Bugaev, 2021/08/17
- Re: PCI arbiter memory mapping, Joan Lledó, 2021/08/18