From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH] linux-2.6.18/x86: replace order-based range checking of M2P table by linear one Date: Mon, 25 Jul 2011 10:33:39 -0400 Message-ID: <20110725143339.GE23212@dumpdata.com> References: <4E2D5C02020000780004F6BB@nat28.tlf.novell.com> <20110725141903.GD23212@dumpdata.com> <4E2D9866020000780004F80B@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <4E2D9866020000780004F80B@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On Mon, Jul 25, 2011 at 03:23:02PM +0100, Jan Beulich wrote: > >>> On 25.07.11 at 16:19, Konrad Rzeszutek Wilk wrote: > > On Mon, Jul 25, 2011 at 11:05:22AM +0100, Jan Beulich wrote: > >> The order-based approach is not only less efficient (requiring a shift > >> and a compare, typical generated code looking like this > >> > >> mov eax, [machine_to_phys_order] > >> mov ecx, eax > >> shr ebx, cl > >> test ebx, ebx > >> jnz ... > >> > >> whereas a direct check requires just a compare, like in > >> > >> cmp ebx, [machine_to_phys_nr] > >> jae ... > >> > >> ), but also slightly dangerous in the 32-on-64 case - the element > >> address calculation can wrap if the next power of two boundary is > >> sufficiently far away from the actual upper limit of the table, and > >> hence can result in user space addresses being accessed (with it being > >> unknown what may actually be mapped there). > > > > You wouldn't have a patch for upstream Linux for this? > > I can try to port this over, but it'll take some time until I can get to > this (certainly not before returning from the summit). Absolutly. Will wait.