Re: gnumach memory attributes
Il 19/11/2016 20:01, Richard Braun ha scritto:
> On Sat, Nov 19, 2016 at 02:37:45PM +0100, Luca dariz wrote:
>> I was thinking about what kind of memory addresses should be allowed to
>> be translated to physical addresses from user-space drivers, for example
>> based on rump kernel.
>> Obviously memory allocated with vm_allocate_contiguous from dde patch,
>> so from the DIRECTMAP segment and of type VM_PT_KERNEL. Are there other
>> possibilities or other parameters to check?
>
> The two major types of memory are anonymous and "file", where file means
> that a memory object isn't backed by the default pager. These shouldn't
> be affected by what you're trying to do.
>
Maybe the translation should be done by the pager?
For example, the default pager would deny such requests, while there
could be an "io pager" which handles only contiguous memory objects and
perform the translation.
The main reason of this distinction is that sometimes on rump drivers
the buffer used for I/O is not allocated from contiguous memory.
>
>> I am thinking about adding an rpc to handle vitual to physical
>> translations (instead of using the debug interface) and maybe rework the
>> vm_allocate_contiguous rpc to not give the physical address, making it
>> similar to vm_allocate.
>
> What we'd rather have is something like hugetlbfs, where contiguous
> physical memory is backed by a pager (probably in the kernel), and
> applications would use vm_map to get access.
>
Ok, so memory mapped I/O would work for user-space drivers.
I still have to figure out how this "io pager" should be implemented.
Should it be driver-specific? Or should it ask the specific driver to
fill a specific memory page on demand?
Currently I am experimenting with a disk driver in libstore, based on
rump kernel. Here I can implement a store_map function which returns a
memory object, that will be created and handled by this "io pager". I
think in this case the driver-specific part could be implemented in a
separate thread or process, which is created/destroyed on store
opening/closing.
Luca
Reply to: