From owner-freebsd-hackers Mon Feb 24 9:23:28 2003 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5061537B401 for ; Mon, 24 Feb 2003 09:23:26 -0800 (PST) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61D5443F85 for ; Mon, 24 Feb 2003 09:23:25 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0419.cvx40-bradley.dialup.earthlink.net ([216.244.43.164] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18nMK0-00002N-00; Mon, 24 Feb 2003 09:23:21 -0800 Message-ID: <3E5A54B6.CC1639F1@mindspring.com> Date: Mon, 24 Feb 2003 09:21:58 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Byunghyun Oh Cc: freebsd-hackers@freebsd.org Subject: Re: Replacement for get_user_pages() of Linux References: <20030223163746.A19421@shell.postech.ac.kr> <20030224100346.GA6374@HAL9000.homeunix.com> <3E59FA6C.CF8CB852@mindspring.com> <20030224143911.GA645@localhost.postech.ac.kr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4e66010e690b72fffd123ab9f06eec65f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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?!?: -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message