Memory allocation/sharing when DMA operations used..

Hey everybody,

For last few days i came whith idea of how Device-Drivers, should handle DMA
requests. If DMA channels access can be considered as a priviledge of only
PLM's, or even centralized DMA driver(which is prefered), through which will
all DMA requests will be handled. First, i think DD's, that receives DMA
request from user for the first time, should allocate/map memory for it selt 
by requesting it from physmem. Then share this region of memory whith
task(as far as i can think these will be device drivers) that requests DMA.
There would be read-only and the writeable memory shared, every of which
is decided to be given whereas task want to receive(read) data, or
send(write) it.
Here i can see a good decision on that only a DMA driver should allocate and
share memory regions whith tasks requesting the operations. Because allowing
user to supply a buffer is not far clever, cause user can die or give up its
pages back to physmem, and at time of receive-operation from DMA channel
memory region could be used by some other task.

This probably can apply not only to DMA operations. Some system part that
provide service(s) to many tasks may can come whith this approach.

At the moment i don't know much about the memory allocation/sharing in hurd-l4
and can't be more specific on this, or supply code.

Comments please.

Re: Memory allocation/sharing when DMA operations used..

Hi,

I'm not very familiar with DMA, but I remembered that only certain pages
can be used for DMA.  Or was that only for ISA?  Anyway, if that is not
the case, it becomes a lot simpler.

The L4-Hurd design uses the idea to give the costs to the user (which is
a program in this context).  This is true in many places, in particular
for memory.  For example, if a client wants to read data from a
filesystem, it supplies a page to the filesystem, which then fills it
with data.

You suggest to leave that design for DMA.  If there are special
"DMA-pages", that doesn't sound strange: Otherwise a DoS-attack would be
possible by allocating many DMA pages.  Of course there could be a quota
system, which might be enough to prevent this.  If all pages can be used
for DMA, I don't see any reason not to use the normal approach of the
client providing the memory for the operation.

You say the user can die on you, leaving a big mess.  This is no
problem, as the container is shared by the driver and the user.  If the
user dies, the container is not deallocated until the driver lets go of
it.  It shouldn't do that before the DMA operation is finished.  It is
not unusual for device drivers to wait with freeing resources after
client death until the device has finished its operation.  This is not a
big problem.  I think it should not be a reason to leave a good design
decision.

If I misunderstood you, please rephrase.

Re: Memory allocation/sharing when DMA operations used..

On Fri, Apr 01, 2005 at 11:22:21AM +0200, Bas Wijnen wrote:
> Hi,
> 
> I'm not very familiar with DMA, but I remembered that only certain pages
> can be used for DMA.  Or was that only for ISA?  Anyway, if that is not
> the case, it becomes a lot simpler.
> 

It's true for ISA but also for PCI in some 64bit systems. In general we
have the following magic barriers on IA32/AMD64 systems :

1MB  : 8bit ISA DMA 
16MB : 16bit ISA DMA
4GB  : Non-DAC capable PCI cards on 64bit systems lacking an IO-MMU.
       (DAC stands for Dual Address Cycle here. Ie. the ability to use a
       64bit address by doing two 32bit address cycles).

Additionally 8 and 16bit ISA DMA transfers can't cross a 64KB or a 128KB
boundary respectively. 

Cheers,

Peter (p2).

_______________________________________________
L4-hurd mailing list
L4-hurd <at> gnu.org
http://lists.gnu.org/mailman/listinfo/l4-hurd

Re: Memory allocation/sharing when DMA operations used..

On Friday 01 April 2005 03:22, Bas Wijnen wrote:
> Markus Kode Kaarn wrote:
> > Hey everybody,
> >
> > For last few days i came whith idea of how Device-Drivers, should handle
> > DMA requests. If DMA channels access can be considered as a priviledge of
> > only PLM's, or even centralized DMA driver(which is prefered), through
> > which will all DMA requests will be handled. First, i think DD's, that
> > receives DMA request from user for the first time, should allocate/map
> > memory for it selt by requesting it from physmem. Then share this region
> > of memory whith task(as far as i can think these will be device drivers)
> > that requests DMA. There would be read-only and the writeable memory
> > shared, every of which is decided to be given whereas task want to
> > receive(read) data, or send(write) it.
> > Here i can see a good decision on that only a DMA driver should allocate
> > and share memory regions whith tasks requesting the operations. Because
> > allowing user to supply a buffer is not far clever, cause user can die or
> > give up its pages back to physmem, and at time of receive-operation from
> > DMA channel memory region could be used by some other task.
> >
> > This probably can apply not only to DMA operations. Some system part that
> > provide service(s) to many tasks may can come whith this approach.
> >
> > At the moment i don't know much about the memory allocation/sharing in
> > hurd-l4 and can't be more specific on this, or supply code.
> >
> > Comments please.
>
> Hi,
>

Re: Memory allocation/sharing when DMA operations used..

On Friday 01 April 2005 03:22, you wrote:
>
> Markus Kode Kaarn wrote:
> > Hey everybody,
> >
> > For last few days i came whith idea of how Device-Drivers, should handle
> > DMA requests. If DMA channels access can be considered as a priviledge of
> > only PLM's, or even centralized DMA driver(which is prefered), through
> > which will all DMA requests will be handled. First, i think DD's, that
> > receives DMA request from user for the first time, should allocate/map
> > memory for it selt by requesting it from physmem. Then share this region
> > of memory whith task(as far as i can think these will be device drivers)
> > that requests DMA. There would be read-only and the writeable memory
> > shared, every of which is decided to be given whereas task want to
> > receive(read) data, or send(write) it.
> > Here i can see a good decision on that only a DMA driver should allocate
> > and share memory regions whith tasks requesting the operations. Because
> > allowing user to supply a buffer is not far clever, cause user can die or
> > give up its pages back to physmem, and at time of receive-operation from
> > DMA channel memory region could be used by some other task.
> >
> > This probably can apply not only to DMA operations. Some system part that
> > provide service(s) to many tasks may can come whith this approach.
> >
> > At the moment i don't know much about the memory allocation/sharing in
> > hurd-l4 and can't be more specific on this, or supply code.
> >
> > Comments please.
>
> Hi,

Re: Memory allocation/sharing when DMA operations used..

On Friday 01 April 2005 14:39, Markus Kode Kaarn wrote:
>
> So, in short my answer is ..
>

Sorry, i meant "question" not "answer" here.

Little typos in LaTeX documentation

As I'm reading the doc in the hurd-l4 CVS, I correct some typos when I
see them:

Index: vmm.tex
===================================================================
RCS file: /cvsroot/hurd/hurd-l4/doc/vmm.tex,v
retrieving revision 1.12
diff -u -r1.12 vmm.tex
--- vmm.tex	30 Oct 2003 02:18:07 -0000	1.12
+++ vmm.tex	1 Apr 2005 15:09:15 -0000
@@ -97,7 +97,7 @@
 fault statistics and access pattern detection for its page eviction
 policy.

-Based on this observation, it is imperitive that the page eviction
+Based on this observation, it is imperative that the page eviction
 scheme have good knowledge about how pages are being used as it only
 requires a few bad decisions to destroy performance.  Thus, a new
 design can either choose to return to the monolithic design and add
@@ -218,7 +218,7 @@
 which frames can be remanufactured (e.g. reread from disk or
 recalculated) and internally promote them to guaranteed frames when
 the frame becomes dirty being careful to never have less than $E$
-clean frames in the task.  Given these semantics, guanteed frames
+clean frames in the task.  Given these semantics, guaranteed frames
 should not be thought of as wired (e.g. \function{mlock}ed in the
 POSIX sense)---although they can have this property---but as frames
 which the task itself must multiplex.  Thus the idea of self-paged
@@ -318,7 +318,7 @@
 exchanged between tasks: all services are provided by the kernel, a

Re: Little typos in LaTeX documentation

vmm.tex, chapter "Learning from Unix", last but one sentence:

"However, as the kernel does not and cannot know how how a task will use 
its memory except based on the use of page fault statistics is bound to 
make sub-ideal eviction decisions."

One "how" should be sufficient 

Regards, Johannes

Re: booting l4-Hurd, memory unaligned

 >Andreas,

 >Would you mind sending the full output?  There's some stuff printed
 >early on that might help in figuring out why you got that error.

 >Thanks,
 >Derek

Hi Derek,

here is (almost) the full output:

a few lines too fast to follow, then:

laden:debug_dump: Booted by GNU GRUB 0.95
laden:debug_dump: Memory: Lower 639 KB, Upper 523200 KB
laden:debug_dump: Module 1: Start 0x198000, End 0x1c1e7a, Cmd /l4/boot/ia-32-kernel
laden:debug_dump: Module 2: Start 0x1c2000, End 0x1d6e22, Cmd /l4/libexec/l4/sigma0
laden:debug_dump: Module 3: Start 0x1d7000, End 0x1e05a8, Cmd /l4/boot/wortel-D
laden:debug_dump: Module 4: Start 0x1e1000, End 0x1f72c8, Cmd /l4/boot/physmem
laden:debug_dump: Module 5: Start 0x1f8000, End 0x20f3c8, Cmd /l4/boot/task
laden:debug_dump: Module 6: Start 0x210000, End 0x2277c8, Cmd /l4/boot/deva
laden:debug_dump: Module 7: Start 0x228000, End 0x23f3c8, Cmd /l4/boot/task
laden:debug_dump: Module 8: Start 0x240000, End 0x250288, Cmd /l4/boot/ruth
laden:debug_dump: Memory Map 1: Type 1, Base: 0x0, Length: 0x9fc00
laden:debug_dump: Memory Map 2: Type 2, Base: 0x9fc00, Length: 0x400
laden:debug_dump: Memory Map 3: Type 2, Base: 0xf0000, Length: 0x10000
laden:debug_dump: Memory Map 4: Type 1, Base: 0x100000, Length: 0x1fef0000
laden:debug_dump: Memory Map 5: Type 3, Base: 0x1fff0000, Length: 0x8000
laden:debug_dump: Memory Map 6: Type 4, Base: 0x1fff8000, Length: 0x8000

Re: booting l4-Hurd, memory unaligned

> laden:debug_dump: Memory Map 7: Type 2, Base: 0xffee0000, Length: 0x2ffff

Andreas,

Superficially I see what's wrong, but I don't know what's causing it.
Memory Map 7's length is misaligned.  The length of each memory map
entry needs to have the lower 10 bits clear.  Since the start address
must also have the lower 10 bits clear this ensures alignment of both
the start and end addresses.

Grub supplies the initial memory map information to laden, so its
possible this is a grub bug.  Then again, the BIOS supplies the info
to grub, so it could be a BIOS bug.  I suppose there's some remote
possibility that its an l4/hurd bug too :)

I'm still looking at it, but figured I'd post in case anyone else has
some ideas.  It's hard to find good infomation regarding how the BIOS
makes the memory map.

Derek

"Andreas B. Mundt" <andi.mundt <at> web.de> writes:

>  >Andreas,
> 
>  >Would you mind sending the full output?  There's some stuff printed
>  >early on that might help in figuring out why you got that error.
> 
>  >Thanks,
>  >Derek