[Top][All Lists]

[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?


reply via email to

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