All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@novell.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
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	[thread overview]
Message-ID: <20110725143339.GE23212@dumpdata.com> (raw)
In-Reply-To: <4E2D9866020000780004F80B@nat28.tlf.novell.com>

On Mon, Jul 25, 2011 at 03:23:02PM +0100, Jan Beulich wrote:
> >>> On 25.07.11 at 16:19, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 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).

<nods>Absolutly. Will wait.

      reply	other threads:[~2011-07-25 14:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-25 10:05 [PATCH] linux-2.6.18/x86: replace order-based range checking of M2P table by linear one Jan Beulich
2011-07-25 14:19 ` Konrad Rzeszutek Wilk
2011-07-25 14:23   ` Jan Beulich
2011-07-25 14:33     ` Konrad Rzeszutek Wilk [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110725143339.GE23212@dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=JBeulich@novell.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.