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: <4A143251.90208@goop.org>
Date:	Wed, 20 May 2009 09:39:45 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Andi Kleen <andi@...stfloor.org>
CC:	Ingo Molnar <mingo@...e.hu>,
	Xen-devel <xen-devel@...ts.xensource.com>,
	the arch/x86 maintainers <x86@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [GIT PULL] xen /proc/mtrr implementation

Andi Kleen wrote:
> Jeremy Fitzhardinge <jeremy@...p.org> writes:
>
>   
>> arch/x86 already defines an mtrr_ops, which defines how to manipulate
>> the MTRR registers.  There are currently several implementations of
>> that interface.  In Xen the MTRR registers belong to the hypervisor,
>> but it allows a privileged kernel to modify them via hypercalls. 
>>     
>
> One part that's unclear to me in this discussion. Could you perhaps
> clarify Jeremy?:
>
> Even Dom0 is not continuous in physical memory, but mapped page by page
> except for swiotlb mappings. But MTRRs are fundamentally a way 
> to change attributes for large physically continous mappings. How do these
> two meet?
>
> After all when you change a MTRR for a given range of memory
> linux sees as continuous it isn't necessarily in Xen.
>
> Is this new interface only defined for swiotlb or MMIO mappings?
> If yes did you check the drivers only actually set it on
> swiotlb or MMIO (that seems dubious to me)?

Really?   Do we ever set unusual memory types on normal system memory?  
 From what I've seen, MTRRs are only ever applied to device mapped 
memory (framebuffers, etc).  I guess it could possibly make sense on 
system memory which is being prepped for DMA (swiotlb, alloc_coherent, 
etc), but dom0 would have a pseudo-phys to machine mapping for that 
memory too (it would be obviously problematic if something tried to 
program MTRR with pseudo-physical addresses, but Xen would/should 
probably disallow it anyway).

    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/