linux-kernel - Re: [GIT PULL] xen /proc/mtrr implementation

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]

Message-ID: <4A0DFF78.6000501@goop.org>
Date:	Fri, 15 May 2009 16:49:12 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	Ingo Molnar <mingo@...e.hu>,
	the arch/x86 maintainers <x86@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Xen-devel <xen-devel@...ts.xensource.com>
Subject: Re: [GIT PULL] xen /proc/mtrr implementation

Eric W. Biederman wrote:
>> /proc/mtrr is in wide use today.  It may be planned for obsolescence, but
>> there's no way you can claim its obsolete today (my completely up-to-date F10 X
>> server is using it, for example).  We don't break oldish usermode ABIs in new
>> kernels.
>>     
>
> Sure it is.  There is a better newer replacement.  It is taking a while to
> get userspace transitioned but that is different.  Honestly I am puzzled
> why that it but whatever.
>   

There's no mention in feature-removal-schedule.txt.

>> Besides, the MTRR code is also a kernel-internal API, used by DRM and other
>> drivers to configure the system MTRR state.  Those drivers will either perform
>> badly or outright fail if they can't set the appropriate cachability properties.
>> That is not obsolete in any way.
>>     
>
> There are about 5 of them so let's fix them.
>   

Well, I count at least 30+, but anyway.

> With PAT we are in a much better position both for portability and for
> flexibility.
>   

PAT is relatively recent, and even more recently bug-free.  There are 
many people with processors which can't or won't do PAT; what's the plan 
to support them?  Just hit them with a performance regression?  Or wrap 
MTRR in some other API?

> Is it possible to fix PAT and get that working first.   That is very definitely
> the preferend API.
>   

Sure, when available.  We're sorting out the details for Xen, but even 
then it may not be available, either because we're running on an old 
version of Xen, or because some other guest is using PAT differently.

But I honestly don't understand the hostility towards 120 lines of code 
to make an interface (albeit legacy/deprecated/whatever) behave in an 
expected way.

    J
--
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/