RE: [PATCH] x86: {reverve,free}_memtype() take a physical address

[Pallipadi, Venkatesh]

>-----Original Message-----
>From: Rene Herman [mailto:rene.herman@xxxxxxxxxxxx]
>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.

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