Re: PAT support

[Terence Ripperda <tripperda@nvidia.com>]

[-- Attachment #1: Type: text/plain, Size: 2900 bytes --]


ok, got this finished up. modified change_page_attr to take a kernel virtual address instead of a page struct. also introduced restore_page_attr, which releases the cmap_range and assumed a pgprot of type PAGE_KERNEL. tweaked the change_page_attr a little to allow virtual addresses, convert from virtual to physical. if you'd prefer any style changes to what I made, feel free to flame me.

I also merged the ioremap functions into a single function (which really just means moving change_page_attr into __ioremap) and made ioremap, ioremap_nocache, and ioremap_wrcomb as inline routines that send the appropriate flags into __ioremap.

fixed an oversight in cmap_convert_flags.

updated all references to change_page_attr to use the correct arguments, but still need to finish the core function changes for x86_64.


between finishing this up and making a first pass at the /proc/bus/pci/* changes, I made some "doh!" realizations:

change_page_attr takes a kernel virtual address currently. this doesn't work well for mmap situations, which have a user virtual address. lookup_address could theoretically be changed to handle this (by switching between kernel & user pgd), but this wouldn't work for 4G/4G kernels.

change_page_attr can't take a physical address, since then it couldn't change_page_attr (change the page table attributes).

a side effect of having cmap_request_range being part of change_page_attr is that the caller must first setup the page tables for the virtual mapping, then check if the caching is ok. it would seem preferrable to use cmap_request_range to check if the caching is ok, setup the page tables, then modify the page tables via change_page_attr (for kernel pages). 

I haven't looked too closely yet, but it would seem like all of this could be encapsulated in remap_page_range and ioremap (ie, driver writers would never call cmap_ routines directly). I'll spend a day or two looking into how well this works.


Thanks,
Terence

On Tue, Apr 20, 2004 at 11:51:12AM -0700, ak@muc.de wrote:
> On Mon, Apr 19, 2004 at 05:54:57PM -0500, Terence Ripperda wrote:
> > > I think I prefer the do/undo model instead of push/pop.
> > > That can work with cmaps too. PAGE_KERNEL means no cmap,
> > > PAGE_KERNEL_WC and PAGE_KERNEL_NOCACHE get a cmap.
> > 
> > but then what is the point of cmap? I would expect a mix of WC and UC
> mappings to be much less dangerous than a mix of WC/UC and WB. perhaps
> my mindset is wrong, but it seems allowing ioremap to request a cached
> mapping is important, and that if that mapping was followed by
> ioremap_nocached or ioremap_wrcomb, that these subsequent calls should
> fail.
> 
> Hmm, you're right. push/pop is probably better for io-mappings,
> otherwise
> we cannot catch existing mappings.  This will be needed for user mmap
> too.
> 
> Ignore my previous suggestion on that then please. Sorry for the noise.
> 
> 
> -Andi

[-- Attachment #2: cachemap-1.10-2.6.4.patch.bz2 --]
[-- Type: application/octet-stream, Size: 13570 bytes --]