Re: Replacement for get_user_pages() of Linux
Thus spake Byunghyun Oh [EMAIL PROTECTED]: I'm porting Plex86 x86 VM, which uses get_user_pages() function at Linux-version kernel module to find and pin physical pages of memory in user space (according to its documentation). I tried many candidates as its replacement (PHYS_TO_VM_PAGE() macro in vm/vm_page.h seems most useful now), but they haven't worked at all. Any experience about porting VM-related things in Linux will be appreciated. :) Glancing at the Linux source, it looks like you want vm_map_wire(). BTW, in the future, it helps if you can describe what you're looking for, since we're not all Linux experts. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for get_user_pages() of Linux
David Schultz wrote: Thus spake Byunghyun Oh [EMAIL PROTECTED]: I'm porting Plex86 x86 VM, which uses get_user_pages() function at Linux-version kernel module to find and pin physical pages of memory in user space (according to its documentation). I tried many candidates as its replacement (PHYS_TO_VM_PAGE() macro in vm/vm_page.h seems most useful now), but they haven't worked at all. Any experience about porting VM-related things in Linux will be appreciated. :) Glancing at the Linux source, it looks like you want vm_map_wire(). BTW, in the future, it helps if you can describe what you're looking for, since we're not all Linux experts. I'm pretty sure this isn't what he really wants, it's just what he thinks he wants, and he's wrong about it, but he hasn't told us what problem he's trying to solve, so that we can correct his misconception. In general, FreeBSD drivers DMA to pages for which there is an established kernel mapping, period. With specific exceptions, kernel pages are not pageable, and so they do not need to be wired (you have to go way out of your way to get pageable kernel memory; most people don't do it, and I'm not even sure UMA allows you to get this type of memory any more). No FreeBSD driver DMA's into user space address space directly, bypassing kernel space address space; either there is a kernel mapping AND a user mapping, or there is ONLY a kernel mapping. The closest FreeBSD ever comes to this is to map a set of kernel space allocated pages into a user process address space, by the process opening a device node, and calling mmap() on it. In a pinch, you can force this on the process from kernel space, so you don't have to rewrite your code (e.g. the code is running under Linux or other emulation), but this is really frowned upon. In this case, the memory is usually allocated directly to the device at the time the device is attached, e.g. the video memory in a VGA card, or the memory window onto the AGP in the agpart device. Then it is mapped into the user process address space (e.g. the XFree86 server process), and DMAs into that memory are implicitly DMAs into the user process address space. Again, it would be really, really nice to know what problem he is trying to solve, so that people who know FreeBSD can tell him the FreeBSD way of solving the problem. I suspect that he wants to use bus_dmamem_alloc(), bus_dmamap_create(), bus_dma_tag_create(), etc., and write a standard FreeBSD device driver for his device, so that it will work on things like Alpha, SPARC64, IA64, PPC, and other platforms which care about memory windows onto main memory via bus space. Without knowing the problem he's trying to solve though... you get the point... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for get_user_pages() of Linux
I am so sorry that I couldn't (and maybe can't) explain what I want, because I don't know it exactly due to my poor knowledge of VM system and Plex86 itself (http://plex86.sourceforge.net/). But I'll try to explain here. Plex86 is a kind of VMWare or so, but it limits its focus to userland operation (many things had been said, but I only remember 'ring 3' and blah). Anyway, Plex86 originally allocated some memory places for some logging and VM guest's CPU info, and this allocation occured in kernel module. However, it changed to allocate in host application part, and kernel module just find user pages from their addresses (I'm not sure whether they are virtual or they are physical) and pin them (someone here already explained what pinning is). Of course, here is an un-pinning function also. I'm neither Linux expert nor FreeBSD expert, so I sought Linux-2.4.20 source, FreeBSD VM things, vmmon (VMWare kernel module part) for FreeBSD, and Google. However, I couldn't find no clear document and usage. Fortunately, many arguments from my question helped me so much, and I think its solution is so close. For now, thanks for answering my silly question. :) Byunghyun Oh octphial _at_ postech.ac.kr ps. Is DMA means just 'Direct Memory Access', and shall I understand it literally? On Mon, Feb 24, 2003 at 02:56:44AM -0800, Terry Lambert wrote: David Schultz wrote: Thus spake Byunghyun Oh [EMAIL PROTECTED]: I'm porting Plex86 x86 VM, which uses get_user_pages() function at Linux-version kernel module to find and pin physical pages of memory in user space (according to its documentation). I tried many candidates as its replacement (PHYS_TO_VM_PAGE() macro in vm/vm_page.h seems most useful now), but they haven't worked at all. Any experience about porting VM-related things in Linux will be appreciated. :) Glancing at the Linux source, it looks like you want vm_map_wire(). BTW, in the future, it helps if you can describe what you're looking for, since we're not all Linux experts. I'm pretty sure this isn't what he really wants, it's just what he thinks he wants, and he's wrong about it, but he hasn't told us what problem he's trying to solve, so that we can correct his misconception. In general, FreeBSD drivers DMA to pages for which there is an established kernel mapping, period. With specific exceptions, kernel pages are not pageable, and so they do not need to be wired (you have to go way out of your way to get pageable kernel memory; most people don't do it, and I'm not even sure UMA allows you to get this type of memory any more). No FreeBSD driver DMA's into user space address space directly, bypassing kernel space address space; either there is a kernel mapping AND a user mapping, or there is ONLY a kernel mapping. The closest FreeBSD ever comes to this is to map a set of kernel space allocated pages into a user process address space, by the process opening a device node, and calling mmap() on it. In a pinch, you can force this on the process from kernel space, so you don't have to rewrite your code (e.g. the code is running under Linux or other emulation), but this is really frowned upon. In this case, the memory is usually allocated directly to the device at the time the device is attached, e.g. the video memory in a VGA card, or the memory window onto the AGP in the agpart device. Then it is mapped into the user process address space (e.g. the XFree86 server process), and DMAs into that memory are implicitly DMAs into the user process address space. Again, it would be really, really nice to know what problem he is trying to solve, so that people who know FreeBSD can tell him the FreeBSD way of solving the problem. I suspect that he wants to use bus_dmamem_alloc(), bus_dmamap_create(), bus_dma_tag_create(), etc., and write a standard FreeBSD device driver for his device, so that it will work on things like Alpha, SPARC64, IA64, PPC, and other platforms which care about memory windows onto main memory via bus space. Without knowing the problem he's trying to solve though... you get the point... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for get_user_pages() of Linux
Byunghyun Oh wrote: ps. Is DMA means just 'Direct Memory Access', and shall I understand it literally? Yes, DMA stands for Direct Memory Access. The purpose of DMA is to allow devices other than the main CPU to directly access regions of physical memory by using a DMA line (DRQ) to arbitrate access to the physical memory bus, and then perform reads (DMA out) or writes (DMA in) to physical RAM belonging to system memory, rather than to the device. The reason to do permit this is so that the main CPU can keep processing whatever is in it's I and D (Instruction and Data) caches, without introducing a stall while the main CPU does its work. In this way, copy processing can be offloaded from the main CPU to chips on devices (DMA engines), instead. - In the context of Plex86, the reason for having this would be to permit physical devices to be assigned to the virtual machine, and not interact with the host system (I think). This idea ia somewhat flawed, and I don't think you can avoid the host system interaction. VMWare handles this by creating virtual hardware that then bridges to the real hardware (e.g. for serial ports and network adapters). In any case, what this would imply is that the kernel running under the Plex86 that has had the resource assigned to it would need *its* pages wired down, so that *its* driver(s) for the real hardware that has been assigned to it can pass kernel addresses to the DMA engines on the hardware, and have the hardware able to DMA into the kernel memory for the host OS. It seems to me that direct assignment of hardware resources is a bad idea, in this context, and that additional modifications to the hosted OS would be required in order to permit these addresses to be exported to real hardware, for DMA purposes. Specifically, you would need to translate from the virtual address to the physical address, given that the physical address is virtualized by the hardware, and this would not be automatic. A useful resource for someone porting Plex86 to FreeBSD is probably the NetBSD port of the code, back in December of last year (though the Plex86 web site claims that the code is significantly changed, as of February of this year, to mostly run in user space). See: http://slashdot.org/article.pl?sid=00/12/14/1041230 Also, FWIW, it looks like it already runs on FreeBSD?!?: http://savannah.nongnu.org/cgi-bin/viewcvs/plex86/plex86-release/kernel/host-freebsd.c http://savannah.nongnu.org/cgi-bin/viewcvs/*checkout*/plex86/plex86-release/kernel/host-freebsd.c?rev=1.1.1.1content-type=text/plain -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for get_user_pages() of Linux
Byunghyun Oh wrote: I'm porting Plex86 x86 VM, which uses get_user_pages() function at Linux-version kernel module to find and pin physical pages of memory in user space (according to its documentation). I tried many candidates as its replacement (PHYS_TO_VM_PAGE() macro in vm/vm_page.h seems most useful now), but they haven't worked at all. Any experience about porting VM-related things in Linux will be appreciated. :) I've been unable to find any documentation on get_user_pages(), and you didn't provide a link to any. But looking at the source code, the reason for doing this is to permit DMA directly into user pages. I don't understand what you mean by pin, in this context. You are aware that FreeBSD has a unified VM and buffer cache, and all user pages for the current process are automatically visible in th kernel address space, with no need to call something like get_user_pages() to establish a mapping, right? Is the intent of this to allow the process memory to be addressed, even though the process is not active? If so, then what you want to do is establish a kernel mapping for the pages, and mark them non-swappable. Otherwise, what you want is automatic (see uiomove). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for get_user_pages() of Linux
On Sun, Feb 23, 2003 at 12:49:31AM -0800, Terry Lambert wrote: I've been unable to find any documentation on get_user_pages(), and you didn't provide a link to any. But looking at the source code, the reason for doing this is to permit DMA directly into user pages. I don't understand what you mean by pin, in this context. get_user_pages() does the following: (1) force all pages into physical memory if they weren't before (2) increment the usage count on the to avoid paging them out The latter is usually called page pinning. You are aware that FreeBSD has a unified VM and buffer cache, and all user pages for the current process are automatically visible in th kernel address space, with no need to call something like get_user_pages() to establish a mapping, right? get_user_pages() does not establish a mapping, in Linux you don't need a kernel mapping to perform DMA on memory. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for get_user_pages() of Linux
Christoph Hellwig wrote: On Sun, Feb 23, 2003 at 12:49:31AM -0800, Terry Lambert wrote: I've been unable to find any documentation on get_user_pages(), and you didn't provide a link to any. But looking at the source code, the reason for doing this is to permit DMA directly into user pages. I don't understand what you mean by pin, in this context. get_user_pages() does the following: (1) force all pages into physical memory if they weren't before (2) increment the usage count on the to avoid paging them out The latter is usually called page pinning. OK, you mean make non-pageable. The question, I guess, is why?. Are you trying to do a delayed operation that will complete when the process has otherwise been swapped out? Is this something that's going to be initiated by the process itself, or does it have to work on a process that is not the current process (e.g. P1 sets up the operation to happen to pages in P2, vs. P1 sets up the operation to happen to pages in P1, and P2 sets up the operation to happen to pages in P2)? In other words, are you trying to pin pages that have resident mappings at the time you want pin them, or are you trying to pin pages that may not have resident mappings at the time you want to pin them? You are aware that FreeBSD has a unified VM and buffer cache, and all user pages for the current process are automatically visible in th kernel address space, with no need to call something like get_user_pages() to establish a mapping, right? get_user_pages() does not establish a mapping, in Linux you don't need a kernel mapping to perform DMA on memory. In FreeBSD, you generally do. First off, the VM and buffer cache is unified. That means that's there's no such thing as a buffer that exists seperately from the VM system. Second off, you aren't really telling us who is doing the DMA; if it's something for which there's an existing device driver, like a disk or whatever, then that's the way it is. Thirdly, when you do demand paged I/O, you always do it into a mapped page, which is then COW mapped into the process (e.g. via mmap(), or mapped directly because it's a page in a process). In other words, there's no such thing as an uncached page. Mabe it would be useful for you to tell us what problem you were trying to solve; I'm sure if you were to do that, then you would get a lot of suggestions of how to go about solving it. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for get_user_pages() of Linux
On Sun, Feb 23, 2003 at 02:17:23AM -0800, Terry Lambert wrote: OK, you mean make non-pageable. Well, I didn't write the initial mail :) The question, I guess, is why?. Are you trying to do a delayed operation that will complete when the process has otherwise been swapped out? well, I don't plan to do anything. The usual way get_user_pages is used on linux is: get_user_pages() perform scatter gatter dma to some device on the pages unping pages as linux VM scanning is fully mutithreaded pages could get paged out during the dma if you didn't pin them so this is needed. get_user_pages() does not establish a mapping, in Linux you don't need a kernel mapping to perform DMA on memory. In FreeBSD, you generally do. First off, the VM and buffer cache is unified. That means that's there's no such thing as a buffer that exists seperately from the VM system. Who talks about buffers? And yes, in Linux you can have buffers that have pages attached to it that aren't mapped into kernel virtual space, in fact that's usual for pages used for actual filesystem data if you have enough memory. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Replacement for get_user_pages() of Linux
I'm porting Plex86 x86 VM, which uses get_user_pages() function at Linux-version kernel module to find and pin physical pages of memory in user space (according to its documentation). I tried many candidates as its replacement (PHYS_TO_VM_PAGE() macro in vm/vm_page.h seems most useful now), but they haven't worked at all. Any experience about porting VM-related things in Linux will be appreciated. :) Byunghyun Oh octphial _at_ postech.ac.kr To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
