On Sat, Nov 17, 2012 at 1:53 PM, Shentino wrote:
> I'm actually curious if the architecture docs/software developer
> manuals for IA-32 mandate any TLB invalidations on a #PF
>
> Is there any official vendor documentation on the subject?
Yes. Quoting a prior email:
Actually, it is architected on
On 11/17/2012 09:56 AM, Linus Torvalds wrote:
On Sat, Nov 17, 2012 at 6:50 AM, Borislav Petkov wrote:
I don't know, however, whether it would be prudent to have some sort of
a cheap assertion in the code (cheaper than INVLPG %ADDR, although on
older cpus we do MOV CR3) just in case. This should
On Sat, Nov 17, 2012 at 06:56:10AM -0800, Linus Torvalds wrote:
> I wonder how we could actually test for it. We'd have to have some
> per-cpu page-fault address check (along with a generation count on the
> mm or similar). I doubt we'd figure out anything that works reliably
> and efficiently and
On Sat, Nov 17, 2012 at 6:50 AM, Borislav Petkov wrote:
>
> Albeit with a slight delay, the answer is yes: all AMD cpus
> automatically invalidate cached TLB entries (and intermediate walk
> results, for that matter) on a #PF.
Thanks. I suspect it ends up being basically architectural, and that
W
On Mon, Oct 29, 2012 at 10:06:15AM -0700, Linus Torvalds wrote:
> On Mon, Oct 29, 2012 at 9:57 AM, Borislav Petkov wrote:
> >
> > On current AMD64 processors,
>
> Can you verify that this is true for older cpu's too (ie the old
> pre-64-bit ones, say K6 and original Athlon)?
Albeit with a slight
On Mon, Oct 29, 2012 at 9:57 AM, Borislav Petkov wrote:
>
> On current AMD64 processors,
Can you verify that this is true for older cpu's too (ie the old
pre-64-bit ones, say K6 and original Athlon)?
> This is done because a table entry is allowed
> to be upgraded (by marking it
On Sat, Oct 27, 2012 at 09:40:41AM -0400, Rik van Riel wrote:
> Borislav, would you happen to know whether AMD (and VIA) CPUs
> automatically invalidate TLB entries that cause page faults? If you do
> not know, would you happen who to ask? :)
Short answer: yes.
Long answer (from APM v2, section 5
On 10/26/2012 05:12 PM, Alan Cox wrote:
On Fri, 26 Oct 2012 14:45:02 -0400
Rik van Riel wrote:
Intel has an architectural guarantee that the TLB entry causing
a page fault gets invalidated automatically. This means
we should be able to drop the local TLB invalidation.
Because of the way other
* Rik van Riel wrote:
> On 10/26/2012 05:12 PM, Alan Cox wrote:
> >On Fri, 26 Oct 2012 14:45:02 -0400
> >Rik van Riel wrote:
> >
> >>Intel has an architectural guarantee that the TLB entry causing
> >>a page fault gets invalidated automatically. This means
> >>we should be able to drop the loca
On 10/26/2012 05:12 PM, Alan Cox wrote:
On Fri, 26 Oct 2012 14:45:02 -0400
Rik van Riel wrote:
Intel has an architectural guarantee that the TLB entry causing
a page fault gets invalidated automatically. This means
we should be able to drop the local TLB invalidation.
Because of the way other
On Fri, 26 Oct 2012 14:45:02 -0400
Rik van Riel wrote:
> Intel has an architectural guarantee that the TLB entry causing
> a page fault gets invalidated automatically. This means
> we should be able to drop the local TLB invalidation.
>
> Because of the way other areas of the page fault code wor
Intel has an architectural guarantee that the TLB entry causing
a page fault gets invalidated automatically. This means
we should be able to drop the local TLB invalidation.
Because of the way other areas of the page fault code work,
chances are good that all x86 CPUs do this. However, if
someone
12 matches
Mail list logo
