pmap: Convert boolean_t to bool.

Reviewed by: kib (older version)
Differential Revision: https://reviews.freebsd.org/D39921

sys: Remove $FreeBSD$: two-line .h pattern

Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/

arm: Rename pte-v6.h to pte.h

There is no need for this to be versioned after the removal of armv4/v5

Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D41139

arm: Move contents of cpu-v6.h into cpu.h

Previously we had an armv4/v5 and armv6/v7 copy of the cpu.h header. As
we have removed armv4/v5 support we can now merge the armv6/v7 code
into cpu.h

Revi

arm: Move contents of cpu-v6.h into cpu.h

Previously we had an armv4/v5 and armv6/v7 copy of the cpu.h header. As
we have removed armv4/v5 support we can now merge the armv6/v7 code
into cpu.h

Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D41137

show more ...

Don't use atomic operations for page table entries and handle access
and R/W emulation aborts under pmap lock.

There were two reasons for using of atomic operations:
(1) the pmap code is based on i3

Don't use atomic operations for page table entries and handle access
and R/W emulation aborts under pmap lock.

There were two reasons for using of atomic operations:
(1) the pmap code is based on i386 one where they are used,
(2) there was an idea that access and R/W emulation aborts should be
handled as quick as possible, without pmap locking.

However, the atomic operations in i386 pmap code are used only because
page table entries may be modified by hardware. At the beginning, we
were not sure that it's the only reason. So even if arm hardware does
not modify them, we did not risk to not use them at that time. Further,
it turns out after some testing that using of pmap lock for access and
R/W emulation aborts does not bring any extra cost and there was no
measurable difference. Thus, we have decided finally to use pmap lock
for all operations on page table entries and so, there is no reason for
atomic operations on them. This makes the code cleaner and safer.

This decision introduce a question if it's safe to use pmap lock for
access and R/W emulation aborts. Anyhow, there may happen two cases in
general:
(A) Aborts while the pmap lock is locked already - this should not
happen as pmap lock is not recursive. However, under pmap lock only
internal kernel data should be accessed and such data should be mapped
with A bit set and NM bit cleared. If double abort happens, then
a mapping of data which has caused it must be fixed.
(B) Aborts while another lock(s) is/are locked - this already can
happen. There is no difference here if it's either access or R/W
emulation abort, or if it's some other abort.

Reviewed by: kib

show more ...

Merge ^/head r295601 through r295844.

MFH

Sponsored by: The FreeBSD Foundation

Include pte-v6.h only where needed.

Catch up with HEAD (r280229-r284686).

Merge sync of head

MFH: r280643-r281852

Sponsored by: The FreeBSD Foundation

Merge from HEAD

New pmap code for armv6. Disabled by default, option ARM_NEW_PMAP enables it.

This is pretty much a complete rewrite based on the existing i386 code. The
patches have been circulating for a couple

New pmap code for armv6. Disabled by default, option ARM_NEW_PMAP enables it.

This is pretty much a complete rewrite based on the existing i386 code. The
patches have been circulating for a couple years and have been looked at by
plenty of people, but I'm not putting anybody on the hook as having reviewed
this in any formal sense except myself.

After this has gotten wider testing from the user community, ARM_NEW_PMAP
will become the default and various dregs of the old pmap code will be
removed.

Submitted by: Svatopluk Kraus <onwahe@gmail.com>,
Michal Meloun <meloun@miracle.cz>

show more ...