Re: [Xen-devel] [patch] pin/unpin must flush tlb

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 23 Jun 2005, at 17:36, Gerd Knorr wrote:

> Patch below is needed to make my system work stable in PAE mode.
> Havn't seen problems without PAE, not sure whenever thats just
> pure luck or whenever there is a bug in my PAE xenlinux kernel.
> To me it looks like a generic bug though.
>
> I've actually trapped into problems with unpin only:  A process
> exits, somewhere in exit_mm() the page tables are unpinned,
> shortly thereafter the mappings are cleared.  While doing so the
> kernel oopses in zap_pte_range(), on page table write access.
> Probably due to some stale tlb entry where the page is still
> tagged read-only.
That's a good catch!

I thought for a long time that, when you increase permissions of a page 
mapping, a TLB flush is unnecessary (because the processor would see 
restrictive TLB entry, but walk pagetables before triggering a page 
fault). This is certainly a feature of most architectures with 
hardware-walked pagetables, but does not occur on modern x86 CPUs 
because it significantly increases demand-fault latency. I only found 
that out from Intel a couple of days ago[*]. :-)
The flush on mm_pin() is actually unnecessary, because one will be 
triggered by pgd_pin(). But it is harmless to add it, it makes it clear 
we want a flush at that point, and it will cause pgd_pin not to do an 
extra superfluous fault (because we have flush-avoidance logic).
 -- Keir

[*]: Even more sophisticated, at the time it triggers the page fault 
the cpu will invalidate the read-only tlb entry. This means that, when 
doing copy-on-write demand faults, for example, the OS does not need to 
flush or invlpg to avoid another protection fault when it replays the 
faulting instruction. Kind of odd behaviour, but obvious required 
behaviour when you think about it...

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel