From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avery Pennarun Subject: Re: perl hypervisor interface Date: Fri, 9 Jul 2004 12:18:00 -0400 Sender: xen-devel-admin@lists.sourceforge.net Message-ID: <20040709161800.GL2502@worldvisions.ca> References: <20040709153043.GF11293@cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Errors-To: xen-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Keir Fraser Cc: David Becker , xen-devel@lists.sourceforge.net List-Id: xen-devel@lists.xenproject.org On Fri, Jul 09, 2004 at 05:02:27PM +0100, Keir Fraser wrote: > > One bit I left out from the libxc do_dom0_op() procedure, was calling mlock() > > on the dom0_op struct before passing it into the ioctl(). > > When does the mlock() come into play? > > Xen doesn't do paging, so any memory buffers you pass to the dom0_op > hypercall (including the dom0_op_t structure itself) must be resident > when Xen is entered. If the buffer is allocated in-kernel then this > isn't a problem, as Linux doesn't page itself. In user space we must > use mlock() to force the buffer to be resident. Wouldn't it be better to have the ioctl() auto-mlock() the memory area, rather than trusting userspace apps to know what they're doing? In general, calls from userspace shouldn't be able to *accidentally* crash the kernel... at least not without asking the kernel for permission first :) Have fun, Avery ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com