This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Gerd Knorr <kraxel@xxxxxxx>
Subject: Re: [Xen-devel] [patch] pin/unpin must flush tlb
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Thu, 23 Jun 2005 20:51:21 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 23 Jun 2005 19:54:31 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20050623163656.GA14572@bytesex>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20050623163656.GA14572@bytesex>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

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

<Prev in Thread] Current Thread [Next in Thread>