aboutsummaryrefslogtreecommitdiff
path: root/ObsoleteFiles.inc
diff options
context:
space:
mode:
authorAlan Cox <alc@FreeBSD.org>2012-03-22 04:52:51 +0000
committerAlan Cox <alc@FreeBSD.org>2012-03-22 04:52:51 +0000
commit5730afc9b6405f9325dfbbf7164dd6c818191ff5 (patch)
tree6628d621fc3b1f91d03b83dcd89b48528e3132fe /ObsoleteFiles.inc
parentbfb2fa9f007481070ebebbb93728b8b3648a5553 (diff)
downloadsrc-5730afc9b6405f9325dfbbf7164dd6c818191ff5.tar.gz
src-5730afc9b6405f9325dfbbf7164dd6c818191ff5.zip
Handle spurious page faults that may occur in no-fault sections of the
kernel. When access restrictions are added to a page table entry, we flush the corresponding virtual address mapping from the TLB. In contrast, when access restrictions are removed from a page table entry, we do not flush the virtual address mapping from the TLB. This is exactly as recommended in AMD's documentation. In effect, when access restrictions are removed from a page table entry, AMD's MMUs will transparently refresh a stale TLB entry. In short, this saves us from having to perform potentially costly TLB flushes. In contrast, Intel's MMUs are allowed to generate a spurious page fault based upon the stale TLB entry. Usually, such spurious page faults are handled by vm_fault() without incident. However, when we are executing no-fault sections of the kernel, we are not allowed to execute vm_fault(). This change introduces special-case handling for spurious page faults that occur in no-fault sections of the kernel. In collaboration with: kib Tested by: gibbs (an earlier version) I would also like to acknowledge Hiroki Sato's assistance in diagnosing this problem. MFC after: 1 week
Notes
Notes: svn path=/head/; revision=233291
Diffstat (limited to 'ObsoleteFiles.inc')
0 files changed, 0 insertions, 0 deletions