Messages in this thread |  | | Date | Fri, 22 Aug 2008 01:06:39 +0200 | | From | Rene Herman <> | | Subject | Re: [PATCH] x86: {reverve,free}_memtype() take a physical address |
| |
On 22-08-08 00:57, Pallipadi, Venkatesh wrote: > >> -----Original Message----- >> From: Rene Herman [mailto:rene.herman@keyaccess.nl] >> Sent: Thursday, August 21, 2008 3:27 PM >> To: Pallipadi, Venkatesh >> Cc: Ingo Molnar; Li, Shaohua; Dave Airlie; Yinghai Lu; Andreas >> Herrmann; Arjan van de Ven; Linux Kernel; Siddha, Suresh B; >> Thomas Gleixner; H. Peter Anvin; Dave Jones >> Subject: Re: [PATCH] x86: {reverve,free}_memtype() take a >> physical address >> >> On 22-08-08 00:16, Pallipadi, Venkatesh wrote: >> >>> Yes. Noticed that too and sent a patch here for x86/tip. >>> >>> http://www.ussg.iu.edu/hypermail/linux/kernel/0808.2/2270.html >>> >>> It is not very critical as it sounds as only set_memory_uc sets PAT >>> bits for RAM pages. Most other users (devmem mmap, ioramep, pci) >>> set PAT bits on the reserved memory. And there will not be conflicts >>> across RAM and reserveed regions. Regardless, this was a stupid >>> bug that we had missed earlier. >> And unfortunately I don't think the above fully fixes it for >> AGP. __pa() >> gets the real physical address and the memtypes should be on the GART >> remapped physical addresses it seems. >> > > Page being marked here as uncached is the page got from alloc_page(). > We are not really marking GART physical address as uncacheable. And > that page returned from alloc_page is what we are tracking with > reserve and free. > IOW, the tracking is only to keep CPU accesses consistent across > different va->pa and va across different CPUs and has nothing to do > with GART physical address here.
Okay, if you say so... it _used_ to be before this array change to AGP that the GART addresses were in the memtype list, but I'll take your word for that being okay.
Rene
|  |