Received: from MIT.MIT.EDU by po6.MIT.EDU (5.61/4.7) id AA15098; Mon, 3
Jan 94 12:31:10 EST
Received: from Sun.COM by MIT.EDU with SMTP
id AA26858; Mon, 3 Jan 94 12:31:08 EST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI4.1)
id AA07397; Mon, 3 Jan 94 09:31:04 PST
Received: from East.Sun.COM by snail.Sun.COM (4.1/SMI-4.1)
id AA03144; Mon, 3 Jan 94 09:31:03 PST
Received: from suneast.East.Sun.COM by East.Sun.COM (4.1/SMI-4.1)
id AA18140; Mon, 3 Jan 94 12:31:01 EST
Received: from scafell.East.Sun.COM by suneast.East.Sun.COM (4.1/SMI-4.1)
id AA22019; Mon, 3 Jan 94 12:31:00 EST
Received: by scafell.East.Sun.COM (4.1/SMI-4.1)
id AA00286; Mon, 3 Jan 94 12:27:10 EST
Date: Mon, 3 Jan 94 12:27:10 EST
From: mce@scafell.East.Sun.COM (Mark Elgood - Sun BOS Software)
Message-Id: <9401031727.AA00286@scafell.East.Sun.COM>
To: hackeron@MIT.EDU
Subject: Re: dma setup example
I think that using kmem (kernel memory) versus vn (vnode) segment would
be better. Should work for sun4c also. as_map + segkmem_alloc should do
it. Also need to turn off cache bit in PTE.
Let me know how this works.
--Mark
> From hackeron@MIT.EDU Wed Dec 22 15:58:37 1993
> To: mce@lancashire.East.Sun.COM (Mark Elgood - Sun BOS Software)
> Subject: Re: dma setup example
> From: Harris L. Gilliam - MIT LCS - Information Mechanics
<hackeron@MIT.EDU>
>
> Hi Mark,
>
>
Thanks for the code sample... I do have a few other questions
> though. What we now propose to do is to have an ioctl call that
> allocates memory in kernel address space. It will return two
things:
>
> 1) an offset which can be used in a subsequent call to mmap
> 2) an address in dvma space for the allocated memory
>
> The user will then pass the offset to mmap and get an address in
user
> space to access the previously allocated memory. This is where
the
> linked list will be built but the links will use dvma addresses.
>
>
> The code sample you sent contains the following line:
>
>
kern_addr = setup_kernel_segment()
>
> which is followed by the correct code to map this to DVMA space.
My
> problem is that I don't have a firm grasp on the proper
(portable) way
> to allocate large chunks of locked down memory in kernel address
> space. Here is a copy of the code we *were* using to do this:
>
>
>
/*
>
* Find an unused address range of at least <size> in
>
* the range [base, base + len).
>
*/
>
base = (caddr_t)KERNELBASE;
>
len = (u_int)Syslimit - (u_int)KERNELBASE;
>
>
if ((retval = as_hole(&kas, mblock->nbytes, &base, &len, AH_LO,
0)) !=
>
A_SUCCESS) {
>
CAM_ERROR_MSG(logpri, "as_hole size=0x%x failed with error
0x%x\n",
>
mblock->nbytes, retval);
>
retval = ENOMEM;
>
return(retval);
>
}
>
/*
* Setup kernel memory segment (locked down memory)
*/
retval = as_map(&kas, base, len, segkmem_create, NULL)
A_SUCCESS = ok
retval = segkmem_alloc(seg, addr, len, canwait, type)
1 =
ok, 0 = error
segkmem_alloc
allocates locked
down physical pages.
>
>
>
>
>
>
>
>
0x%x\n",
/*
* Set up a zero-fill-on-demand segment, with user protections.
*/
if ((retval = as_map(&kas, base, mblock->nbytes,
segvn_create, zfod_argsp)) != A_SUCCESS) {
CAM_ERROR_MSG(logpri,
"as_map base=0x%x, size=0x%x failed with error
>
base, mblock->nbytes, retval);
>
>
retval = ENOMEM;
>
return(retval);
>
}
>
>
mblock->ptr = base;
/* set mblock->ptr to new
base */
>
>
CAM_TRACK_MSG(logpri, "MemPtr: 0x%x\n", (u_int) mblock->ptr);
>
>
/*
>
* We have to lock down the pages so that the user can
>
* mmap /dev/kmem. The kmem driver will reject the mmap
>
* if any of the ptes are invalid. So we lock now. Additional
>
* calls would need to be added to (un)lock pages if demand
>
* paging is to be used.
>
*
>
* map [mblock->ptr, mblock->ptr + mblock->nbytes)
>
* to physical memory and lock everything down.
>
*/
>
>
if ((retval = as_fault(&kas, mblock->ptr, mblock->nbytes,
>
F_SOFTLOCK, S_OTHER)) != A_SUCCESS ) {
>
>
CAM_ERROR_MSG(logpri,
>
"SOFTLOCK base=0x%x, size=0x%x failed with
error 0x%x\n",
>
mblock->ptr, mblock->nbytes, retval);
>
>
retval = ENOMEM;
>
return(retval);
>
}
>
>
> This code was causing a panic in the call to as_fault. We need
the
> equivalent chunk of code for the LX to allocate kernel memory,
lock it
> down and turn off the cache bit in the PTE.
>
>
>
>
Thanks,
>
Harris
>
>
>