linux-kernel - Re: [PATCH] x86: mtrr cleanup for converting continuous to discrete

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 1 May 2008 15:52:02 -0700
From:	"Yinghai Lu" <yhlu.kernel@...il.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Ingo Molnar" <mingo@...e.hu>,
	"Thomas Gleixner" <tglx@...utronix.de>,
	"Gabriel C" <nix.or.die@...glemail.com>,
	"Mika Fischer" <mika.fischer@...pnet.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86: mtrr cleanup for converting continuous to discrete - auto detect v2

On Thu, May 1, 2008 at 2:49 PM, H. Peter Anvin <hpa@...or.com> wrote:
> Yinghai Lu wrote:
>
> >
> > >
> > > >
> > > >
> > >  That's not the point.  I understand you want to flatten the layout.
> The
> > > point is: why do you need manual tunables for the algorithm to do the
> right
> > > thing?
> > >
> >
> > optimal result is not losing covering for ranges that is originally
> > covered, and still keep as many of spare mtrr entries for X server
> > driver.
> > we only have 8 mtrrs, could lose some covering because of run out of mtrr
> regs.
> > So we need to search it according to chunk/gran with ram ranges that
> > is defined by old mtrr layout.
> >
>
>  Yes.  You have a search space of less than 1000 possible combinations
> (64..20 bits), so it hardly is any reason to not search the entire universe
> of possibilities, even if by exhaustive search.

only search 78
2g, 1g, ...1m, and half matrix 13 * 6..

and don't need to search than 78.

also if we don't need to get the more spare regs than
mtrr_spare_reg_nr, we could search less... about 10 etc.

>
>  Now, if even that searching can't come up with the optimal solution (if one
> exists) in all cases, then the algorithm is broken.

because we only have 8 mtrrs, and user may specify mtrr_spare_reg_nr =
2 or 3 to get more entries for the graphics cards...
then can not the optimal setting without losing any covering.

so if the optimal is there (only need to search to 2g), it will catch it.

YH
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/