[GSOC]Progress Report of MMU support project

[Jan Andersson]

On 07/12/2011 12:44 PM, Peter Dufault wrote:
> 
> On Jul 12, 2011, at 5:55 , Aanjhan R wrote:
> 
>> Having worked on this project 2 yrs back, I am happy to see it
>> progress through to this stage [which Joel and Thomas would agree on
>> the ambitious quotient level of the proposal]. However, as I mentioned
>> in the proposal review, it would be very helpful to the community if
>> you can start thinking on slowly [in small parts] try to integrate
>> "relevant" code into the trunk. Its not trivial and a solid "start" to
>> this project would be when the first few bits go into the source
>> control.
> 
> I think that if Quanming can get it to the point that
> 
> 1. There's a clean abstraction for differing hardware  (Quanming, the discussions we've had about that should also go onto your Wiki);
> 2. (I haven't discussed this with Quanming yet) The interface described in posix_typed_mem_open() either is present or is trivially implementable
> 
> then the interface will be useful for simple uses such as creating a private per-task memory block, etc. and would be a good candidate to go into the source tree.
> 


This isn't feedback on the GSoC progress so my apologies for heading OT,
but: Has anyone thought of expanding this to also cover IOMMUs?

With an IOMMU you would typically place one or several DMA-capable
peripheral units into one of several available groups. Each group has a
page table (or other data structure) associated with it. There are also
other variations but the end result is basically the same. In terms of
HW support you will, as far as I know, find this on reasonably recent
systems from AMD, Intel, IBM, and also on some LEON4 SoCs (for the first
three, perhaps you won't find this on systems targeting embedded).

If there was a way to associate a group of peripherals to a task, it
would be very convenient to be able to call
rtems_memp_alut_create_entry(..) with an attribute that specifies that
IOMMU mappings also should be set up. However this is just a naive
thought from someone who doesn't do much RTEMS development, perhaps a
separate ALUT for the IOMMU would be more appropriate.

IMHO, a logical step after preventing tasks from overwriting memory of
other tasks could be to add protection so that a task cannot instruct a
DMA peripheral to overwrite memory belonging to another task (or memory
belonging to the current where the memory isn't part of the area where
the peripheral is expected to do DMA). Supporting IOMMUs probably means
a significant amount of work that no one wants to do right now. I still
wanted to bring up the topic if a memory protection API is being
considered for inclusion so that the API can be defined with probable
future extensions in mind.

Best regards,
  Jan