kernel/x86: Move the add_memory_type_range tracing to level "2".

We usually set level "1" by default, so this will hide it.
It's not really that useful when debugging problems in general
at this point.

OK'ed by tqh.

kernel: Use anonymous namespaces to avoid type collisions.

The anonymous namespace makes type definitions local to the translation
unit (like static does for objects). For pretty much any type not shared
across multiple files this is what one wants to happen (and might
erroneously expect to happen automatically).

This commit solves some actual collisions that were present:

* The VFS and the rootfs both used an incompatible VnodeHash struct for
their BOpenHashTable.
* XSI semaphores and message queues both used queued_thread, Ipc and
IpcHashTableDefinition.

For release builds these did not cause problems as the types were fully
inlined. Debug builds would crash at boot however because parts of a
BOpenHashTable<VnodeHash> from the rootfs meant to operate on struct
rootfs_vnode would be applied to one from the VFS expecting struct
vnode.

As such collisions are violations of the one definition rule, the code
is at fault and unfortunatley the compiler isn't required to diagnose
such problems across translation units (which isn't actually trivial).
This can lead to subtle and hard to debug problems and it's therefore
best to avoid leaking types into the global namespace whenever possible.

x86: enable data execution prevention

Set execute disable bit for any page that belongs to area with neither
B_EXECUTE_AREA nor B_KERNEL_EXECUTE_AREA set.

In order to take advanage of NX bit in 32 bit protected mode PAE must be
enabled. Thus, from now on it is also enabled when the CPU supports NX bit.

vm_page_fault() takes additional argument which indicates whether page fault
was caused by an illegal instruction fetch.

Compile remaining x86 bits for x86_64.

The IOAPIC and IRQ routing code now gets compiled for x86_64, though
they won't be used yet as there is no ACPI support currently.

A couple of bug fixes.

* mmu_get_virtual_mapping() should check that the page directory entry is
present rather than assuming there's a page table there. This was resulting
in some invalid mappings being created in the 64-bit virtual address space.
* arch_vm_init_end() should clear from KERNEL_LOAD_BASE to virtual_end, not
from KERNEL_BASE. On x86_64 this was causing it to loop through ~512GB of
address space, which obviously was taking quite a while.

Build arch_vm.cpp for x86_64. No changes required except for temporarily disabling bios_init call.

Removed unnecessary inclusions of <boot/kernel_args.h> in private kernel
headers and respectively added includes in source files.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37259 a95241bf-73f2-0310-859d-f6bbb57e9c96

Removed not needed and no longer existing header. Fixes the build.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37067 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Changed physical_entry::{address,size} to phys_{addr,size}_t and changed
map_physical_memory()'s physicalAddress parameter type from void* to
phys_addr_t. This breaks source compatibility, but -- as long as
phys_{addr,size}_t remain 32 bit wide -- keeps binary compatibility with
BeOS.
* Adjusted all code using the affected interfaces (Oh what fun!). Added a few
TODOs in places where the wrong types (e.g. void* for physical addresses
are used). Looks like quite a few drivers aren't 64 bit safe and others
will break with PAE.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36960 a95241bf-73f2-0310-859d-f6bbb57e9c96

* First run through the kernel's private parts to use phys_{addr,size}_t
where appropriate.
* Typedef'ed page_num_t to phys_addr_t and used it in more places in
vm_page.{h,cpp}.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36937 a95241bf-73f2-0310-859d-f6bbb57e9c96

Hopefully the last work on the MTRR code for the time being:
Since we also force uncacheability via the PTEs, it is no longer necessary to
use MTRRs for uncacheable ranges. It is recommended, which is why we still do
it, if possible, but when we run out of MTRRs, the algorithm ignores
uncacheable ranges now -- iteratively it increases the minimum size of ranges
to drop until the available MTRRs suffice.
Should fix #5703 and #5865.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36591 a95241bf-73f2-0310-859d-f6bbb57e9c96

* VMArea: Made memory_type private and added setter and getter methods.
* Don't set the VMArea's memory type in arch_vm_set_memory_type(), but let the
callers do that.
* vm_set_area_memory_type(): Does nothing, if the memory type doesn't change.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36573 a95241bf-73f2-0310-859d-f6bbb57e9c96

arch_vm_supports_protection(): Fixed broken check.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36570 a95241bf-73f2-0310-859d-f6bbb57e9c96

panic() when running out of MTRRs. I know I'm gonna regret this...


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35755 a95241bf-73f2-0310-859d-f6bbb57e9c96

add_mtrrs_for_range(): Fixed computation of the register ranges. Per power of
2 size we might need to use two registers (for the start and the end of the
range).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35753 a95241bf-73f2-0310-859d-f6bbb57e9c96

Boot loader (x86 mmu.cpp):
* Made the page table allocation more flexible. Got rid of sMaxVirtualAddress
and added new virtual_end address to the architecture specific kernel args.
* Increased the virtual space we reserve for the kernel to 16 MB. That
should suffice for quite a while. The previous 2 MB were too tight when
building the kernel with debug info.
* mmu_init(): The way we were translating the BIOS' extended memory map to
our physical ranges arrays was broken. Small gaps between usable memory
ranges would be ignored and instead marked allocated. This worked fine for
the boot loader and during the early kernel initialization, but after the
VM has been fully set up it frees all physical ranges that have not been
claimed otherwise. So those ranges could be entered into the free pages
list and would be used later. This could possibly cause all kinds of weird
problems, probably including ACPI issues. Now we add only the actually
usable ranges to our list.

Kernel:
* vm_page_init(): The pages of the ranges between the usable physical memory
ranges are now marked PAGE_STATE_UNUSED, the allocated ranges
PAGE_STATE_WIRED.
* unmap_and_free_physical_pages(): Don't free pages marked as unused.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35726 a95241bf-73f2-0310-859d-f6bbb57e9c96

Don't complain about running out of MTRRs before the CPU modules have been
loaded in the first place.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35585 a95241bf-73f2-0310-859d-f6bbb57e9c96

* map_physical_memory() does now always set a memory type. If none is given (it
needs to be or'ed to the address specification), "uncached" is assumed.
* Set the memory type for the "BIOS" and "DMA" areas to write-back. Not sure, if
that's correct, but that's what was effectively used on my machines before.
* Changed x86_set_mtrrs() and the CPU module hook to also set the default memory
type.
* Rewrote the MTRR computation once more:
- Now we know all used memory ranges, so we are free to extend used ranges
into unused ones in order to simplify them for MTRR setup.
- Leverage the subtractive properties of uncached and write-through ranges to
simplify ranges of any other respectively write-back type.
- Set the default memory type to write-back, so we don't need MTRRs for the
RAM ranges.
- If a new range intersects with an existing one, we no longer just fail.
Instead we use the strictest requirements implied by the ranges. This fixes
#5383.

Overall the new algorithm should be sufficient with far less MTRRs than before
(on my desktop machine 4 are used at maximum, while 8 didn't quite suffice
before). A drawback of the current implementation is that it doesn't deal with
the case of running out of MTRRs at all, which might result in some ranges
having weaker caching/memory ordering properties than requested.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35515 a95241bf-73f2-0310-859d-f6bbb57e9c96

Made the VMArea fields base and size private and added accessors instead.
This makes it more explicit where the fields are modified.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34464 a95241bf-73f2-0310-859d-f6bbb57e9c96

Created VMArea.{h,cpp} and moved VMArea and the global area hash table (new
class VMAreaHash) there.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34450 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Moved the VM headers into subdirectory vm/.
* Renamed vm_cache.h/vm_address_space.h to VMCache.h/VMAddressSpace.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34449 a95241bf-73f2-0310-859d-f6bbb57e9c96

vm_area -> VMArea


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34423 a95241bf-73f2-0310-859d-f6bbb57e9c96

Renamed vm_address_space to VMAddressSpace.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34422 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added a set_mtrrs() hook to x86_cpu_module_info, which is supposed to set
all MTRRs at once.
* Added a respective x86_set_mtrrs() kernel function.
* x86 CPU module:
- Implemented the new hook.
- Prefixed most debug output with the CPU index. Otherwise it gets quite
confusing with multiple CPUs.
- generic_init_mtrrs(): No longer clear all MTRRs, if they are already
enabled. This lets us benefit from the BIOS's setup until we install our
own -- otherwise with caching disabled things are *really* slow.
* arch_vm.cpp: Completely rewrote the MTRR handling as the old one was not
only slow (O(2^n)), but also broken (resulting in incorrect setups (e.g.
with cachable ranges larger than requested)), and not working by design for
certain cases (subtractive setups intersecting ranges added later).
Now we maintain an array with the successfully set ranges. When a new range
is added, we recompute the complete MTRR setup as we need to. The new
algorithm analyzing the ranges has linear complexity and also handles range
base addresses with an alignment not matching the range size (e.g. a range
at address 0x1000 with size 0x2000) and joining of adjacent/overlapping
ranges of the same type.

This fixes the slow graphics on my 4 GB machine (though unfortunately the
8 MTRRs aren't enough to fully cover the complete frame buffer (about 35
pixel lines remain uncachable), but that can't be helped without rounding up
the frame buffer size, for which we don't have enough information). It might
also fix #1823.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34197 a95241bf-73f2-0310-859d-f6bbb57e9c96

Make two runs of MTRR setting when setting memory ranges to write-back. At the
first run only set up uncacheable MTRRs and in the second run set the write-back
ones up. If this order is not followed, we could set too large ranges to
cacheable first and then limit it back to uncacheable later. On systems with
enough physical memory this would lead to a temporary situation in which areas
become cacheable that must not be, resulting in system hangs or other unexpected
behaviour. Fixes last part of #4018.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31027 a95241bf-73f2-0310-859d-f6bbb57e9c96

When switching to a kernel thread we no longer set the page directory.
This is not necessary, since userland teams' page directories also
contain the kernel mappings, and avoids unnecessary TLB flushes. To make
that possible the vm_translation_map_arch_info objects are reference
counted now.

This optimization reduces the kernel time of the Haiku build on my
machine with SMP disabled a few percent, but interestingly the total
time decreases only marginally. Haven't tested with SMP yet, but for
full impact CPU affinity would be needed.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28287 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Prefixed memset_physical() and memcpy_to_physical() with "vm_",
added vm_memcpy_from_physical() and vm_memcpy_physical_page(), and
added respective functions to the vm_translation_map operations. The
architecture specific implementation can now decide how to implement
them most efficiently. Added generic implementations that can be used,
though.
* Changed vm_{get,put}_physical_page(). The former no longer accepts
flags (the only flag PHYSICAL_PAGE_DONT_WAIT wasn't needed anymore).
Instead it returns an implementation-specific handle that has to be
passed to the latter. Added vm_{get,put}_physical_page_current_cpu()
and *_debug() variants, that work only for the current CPU,
respectively when in the kernel debugger. Also adjusted the
vm_translation_map operations accordingly.
* Made consequent use of the physical memory operations in the source
tree.
* Also adjusted the m68k and ppc implementations with respect to the
vm_translation_map operation changes, but they are probably broken,
nevertheless.
* For x86 the generic physical page mapper isn't used anymore. It is
suboptimal in any case. For systems with small memory it is too much
overhead, since one can just map the complete physical memory (that's
not done yet, though). For systems with large memory it counteracts
the VM strategy to reuse the least recently used pages. Since those
pages will most likely not be mapped by the page mapper anymore, it
will keep remapping chunks. This was also the reason why building
Haiku in Haiku was significantly faster with only 256 MB RAM (since
that much could be kept mapped all the time).
Now we're using a different strategy: We have small pools of virtual
page slots per CPU that are used for the physical page operations
(memset_physical(), memcpy_*_physical()) with CPU-pinned thread.
Furthermore we have four slots per translation map, which are used to
map page tables.

These changes speed up the Haiku image build in Haiku significantly. On
my Core2 Duo 2.2 GHz 2 GB machine about 40% to 20 min 40 s (KDEBUG
disabled, block cache debug disabled). Still more than factor 3 slower
than FreeBSD and Linux, though.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28244 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added "from" address space parameter to vm_swap_address_space()/
arch_vm_aspace_swap().
* The x86 implementation does now maintain a bit mask per
vm_translation_map_arch_info indicating on which CPUs the address
space is active. This allows flush_tmap() to avoid ICI for user
address spaces when the team isn't currently running on any other CPU.
In this context ICI is relatively expensive, particularly since we map
most pages via vm_map_page() and therefore invoke flush_tmap() pretty
much for every single page.
This optimization speeds up a "hello world" compilation about 20% on
my machine (KDEBUG turned off, freshly booted), but interestingly it
has virtually no effect on the "-j2" haiku build time.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27912 a95241bf-73f2-0310-859d-f6bbb57e9c96

Fixed various warnings.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27841 a95241bf-73f2-0310-859d-f6bbb57e9c96

find_nearest() now saves a solution when reaching the max number of solutions and not near enough


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25859 a95241bf-73f2-0310-859d-f6bbb57e9c96

disabled check for memory overlaps for the time being


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24946 a95241bf-73f2-0310-859d-f6bbb57e9c96

reduced MTRR min size to 512KB


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24679 a95241bf-73f2-0310-859d-f6bbb57e9c96

take into account areas starting or ending equally


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24612 a95241bf-73f2-0310-859d-f6bbb57e9c96

now checks if another mtrr range is extended by a new one and extends it


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24582 a95241bf-73f2-0310-859d-f6bbb57e9c96

now fails if a write combining overlaps


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24494 a95241bf-73f2-0310-859d-f6bbb57e9c96

style cleanup
replaced addr_t by uint64
more debug output


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24476 a95241bf-73f2-0310-859d-f6bbb57e9c96

clean up, comments, header


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24452 a95241bf-73f2-0310-859d-f6bbb57e9c96

Fixed warning.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24438 a95241bf-73f2-0310-859d-f6bbb57e9c96

algorithm to find best suited mtrr values to match a memory region. tested ok with 3071MB.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24424 a95241bf-73f2-0310-859d-f6bbb57e9c96

here with 3GB of memory, a 4GB MTRR slot is being written, which triggers a reboot.
we now split more than 2GB MTRR slot, we might improve this and split more and more.
this could fix the bug #1711.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24244 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Cleaned up vm_types.h a bit, and made vm_page, vm_cache, and vm_area
opaque types for C.
* As a result, I've renamed some more source files to .cpp, and fixed
all warnings caused by that.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22326 a95241bf-73f2-0310-859d-f6bbb57e9c96

x86: enable data execution prevention

Set execute disable bit for any page that belongs to area with neither
B_EXECUTE_AREA nor B_KERNEL_EXECUTE_AREA set.

In order to take advanage of NX bit in 32 bit protected mode PAE must be
enabled. Thus, from now on it is also enabled when the CPU supports NX bit.

vm_page_fault() takes additional argument which indicates whether page fault
was caused by an illegal instruction fetch.

Compile remaining x86 bits for x86_64.

The IOAPIC and IRQ routing code now gets compiled for x86_64, though
they won't be used yet as there is no ACPI support currently.

A couple of bug fixes.

* mmu_get_virtual_mapping() should check that the page directory entry is
present rather than assuming there's a page table there. This was resulting
in some invalid mappings being created in the 64-bit virtual address space.
* arch_vm_init_end() should clear from KERNEL_LOAD_BASE to virtual_end, not
from KERNEL_BASE. On x86_64 this was causing it to loop through ~512GB of
address space, which obviously was taking quite a while.

Build arch_vm.cpp for x86_64. No changes required except for temporarily disabling bios_init call.

Removed unnecessary inclusions of <boot/kernel_args.h> in private kernel
headers and respectively added includes in source files.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37259 a95241bf-73f2-0310-859d-f6bbb57e9c96

Removed not needed and no longer existing header. Fixes the build.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37067 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Changed physical_entry::{address,size} to phys_{addr,size}_t and changed
map_physical_memory()'s physicalAddress parameter type from void* to
phys_addr_t. This breaks source compatibility, but -- as long as
phys_{addr,size}_t remain 32 bit wide -- keeps binary compatibility with
BeOS.
* Adjusted all code using the affected interfaces (Oh what fun!). Added a few
TODOs in places where the wrong types (e.g. void* for physical addresses
are used). Looks like quite a few drivers aren't 64 bit safe and others
will break with PAE.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36960 a95241bf-73f2-0310-859d-f6bbb57e9c96

* First run through the kernel's private parts to use phys_{addr,size}_t
where appropriate.
* Typedef'ed page_num_t to phys_addr_t and used it in more places in
vm_page.{h,cpp}.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36937 a95241bf-73f2-0310-859d-f6bbb57e9c96

Hopefully the last work on the MTRR code for the time being:
Since we also force uncacheability via the PTEs, it is no longer necessary to
use MTRRs for uncacheable ranges. It is recommended, which is why we still do
it, if possible, but when we run out of MTRRs, the algorithm ignores
uncacheable ranges now -- iteratively it increases the minimum size of ranges
to drop until the available MTRRs suffice.
Should fix #5703 and #5865.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36591 a95241bf-73f2-0310-859d-f6bbb57e9c96

* VMArea: Made memory_type private and added setter and getter methods.
* Don't set the VMArea's memory type in arch_vm_set_memory_type(), but let the
callers do that.
* vm_set_area_memory_type(): Does nothing, if the memory type doesn't change.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36573 a95241bf-73f2-0310-859d-f6bbb57e9c96

arch_vm_supports_protection(): Fixed broken check.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36570 a95241bf-73f2-0310-859d-f6bbb57e9c96

panic() when running out of MTRRs. I know I'm gonna regret this...


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35755 a95241bf-73f2-0310-859d-f6bbb57e9c96

add_mtrrs_for_range(): Fixed computation of the register ranges. Per power of
2 size we might need to use two registers (for the start and the end of the
range).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35753 a95241bf-73f2-0310-859d-f6bbb57e9c96

Boot loader (x86 mmu.cpp):
* Made the page table allocation more flexible. Got rid of sMaxVirtualAddress
and added new virtual_end address to the architecture specific kernel args.
* Increased the virtual space we reserve for the kernel to 16 MB. That
should suffice for quite a while. The previous 2 MB were too tight when
building the kernel with debug info.
* mmu_init(): The way we were translating the BIOS' extended memory map to
our physical ranges arrays was broken. Small gaps between usable memory
ranges would be ignored and instead marked allocated. This worked fine for
the boot loader and during the early kernel initialization, but after the
VM has been fully set up it frees all physical ranges that have not been
claimed otherwise. So those ranges could be entered into the free pages
list and would be used later. This could possibly cause all kinds of weird
problems, probably including ACPI issues. Now we add only the actually
usable ranges to our list.

Kernel:
* vm_page_init(): The pages of the ranges between the usable physical memory
ranges are now marked PAGE_STATE_UNUSED, the allocated ranges
PAGE_STATE_WIRED.
* unmap_and_free_physical_pages(): Don't free pages marked as unused.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35726 a95241bf-73f2-0310-859d-f6bbb57e9c96

Don't complain about running out of MTRRs before the CPU modules have been
loaded in the first place.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35585 a95241bf-73f2-0310-859d-f6bbb57e9c96

* map_physical_memory() does now always set a memory type. If none is given (it
needs to be or'ed to the address specification), "uncached" is assumed.
* Set the memory type for the "BIOS" and "DMA" areas to write-back. Not sure, if
that's correct, but that's what was effectively used on my machines before.
* Changed x86_set_mtrrs() and the CPU module hook to also set the default memory
type.
* Rewrote the MTRR computation once more:
- Now we know all used memory ranges, so we are free to extend used ranges
into unused ones in order to simplify them for MTRR setup.
- Leverage the subtractive properties of uncached and write-through ranges to
simplify ranges of any other respectively write-back type.
- Set the default memory type to write-back, so we don't need MTRRs for the
RAM ranges.
- If a new range intersects with an existing one, we no longer just fail.
Instead we use the strictest requirements implied by the ranges. This fixes
#5383.

Overall the new algorithm should be sufficient with far less MTRRs than before
(on my desktop machine 4 are used at maximum, while 8 didn't quite suffice
before). A drawback of the current implementation is that it doesn't deal with
the case of running out of MTRRs at all, which might result in some ranges
having weaker caching/memory ordering properties than requested.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35515 a95241bf-73f2-0310-859d-f6bbb57e9c96

Made the VMArea fields base and size private and added accessors instead.
This makes it more explicit where the fields are modified.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34464 a95241bf-73f2-0310-859d-f6bbb57e9c96

Created VMArea.{h,cpp} and moved VMArea and the global area hash table (new
class VMAreaHash) there.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34450 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Moved the VM headers into subdirectory vm/.
* Renamed vm_cache.h/vm_address_space.h to VMCache.h/VMAddressSpace.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34449 a95241bf-73f2-0310-859d-f6bbb57e9c96

vm_area -> VMArea


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34423 a95241bf-73f2-0310-859d-f6bbb57e9c96

Renamed vm_address_space to VMAddressSpace.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34422 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added a set_mtrrs() hook to x86_cpu_module_info, which is supposed to set
all MTRRs at once.
* Added a respective x86_set_mtrrs() kernel function.
* x86 CPU module:
- Implemented the new hook.
- Prefixed most debug output with the CPU index. Otherwise it gets quite
confusing with multiple CPUs.
- generic_init_mtrrs(): No longer clear all MTRRs, if they are already
enabled. This lets us benefit from the BIOS's setup until we install our
own -- otherwise with caching disabled things are *really* slow.
* arch_vm.cpp: Completely rewrote the MTRR handling as the old one was not
only slow (O(2^n)), but also broken (resulting in incorrect setups (e.g.
with cachable ranges larger than requested)), and not working by design for
certain cases (subtractive setups intersecting ranges added later).
Now we maintain an array with the successfully set ranges. When a new range
is added, we recompute the complete MTRR setup as we need to. The new
algorithm analyzing the ranges has linear complexity and also handles range
base addresses with an alignment not matching the range size (e.g. a range
at address 0x1000 with size 0x2000) and joining of adjacent/overlapping
ranges of the same type.

This fixes the slow graphics on my 4 GB machine (though unfortunately the
8 MTRRs aren't enough to fully cover the complete frame buffer (about 35
pixel lines remain uncachable), but that can't be helped without rounding up
the frame buffer size, for which we don't have enough information). It might
also fix #1823.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34197 a95241bf-73f2-0310-859d-f6bbb57e9c96

Make two runs of MTRR setting when setting memory ranges to write-back. At the
first run only set up uncacheable MTRRs and in the second run set the write-back
ones up. If this order is not followed, we could set too large ranges to
cacheable first and then limit it back to uncacheable later. On systems with
enough physical memory this would lead to a temporary situation in which areas
become cacheable that must not be, resulting in system hangs or other unexpected
behaviour. Fixes last part of #4018.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31027 a95241bf-73f2-0310-859d-f6bbb57e9c96

When switching to a kernel thread we no longer set the page directory.
This is not necessary, since userland teams' page directories also
contain the kernel mappings, and avoids unnecessary TLB flushes. To make
that possible the vm_translation_map_arch_info objects are reference
counted now.

This optimization reduces the kernel time of the Haiku build on my
machine with SMP disabled a few percent, but interestingly the total
time decreases only marginally. Haven't tested with SMP yet, but for
full impact CPU affinity would be needed.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28287 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Prefixed memset_physical() and memcpy_to_physical() with "vm_",
added vm_memcpy_from_physical() and vm_memcpy_physical_page(), and
added respective functions to the vm_translation_map operations. The
architecture specific implementation can now decide how to implement
them most efficiently. Added generic implementations that can be used,
though.
* Changed vm_{get,put}_physical_page(). The former no longer accepts
flags (the only flag PHYSICAL_PAGE_DONT_WAIT wasn't needed anymore).
Instead it returns an implementation-specific handle that has to be
passed to the latter. Added vm_{get,put}_physical_page_current_cpu()
and *_debug() variants, that work only for the current CPU,
respectively when in the kernel debugger. Also adjusted the
vm_translation_map operations accordingly.
* Made consequent use of the physical memory operations in the source
tree.
* Also adjusted the m68k and ppc implementations with respect to the
vm_translation_map operation changes, but they are probably broken,
nevertheless.
* For x86 the generic physical page mapper isn't used anymore. It is
suboptimal in any case. For systems with small memory it is too much
overhead, since one can just map the complete physical memory (that's
not done yet, though). For systems with large memory it counteracts
the VM strategy to reuse the least recently used pages. Since those
pages will most likely not be mapped by the page mapper anymore, it
will keep remapping chunks. This was also the reason why building
Haiku in Haiku was significantly faster with only 256 MB RAM (since
that much could be kept mapped all the time).
Now we're using a different strategy: We have small pools of virtual
page slots per CPU that are used for the physical page operations
(memset_physical(), memcpy_*_physical()) with CPU-pinned thread.
Furthermore we have four slots per translation map, which are used to
map page tables.

These changes speed up the Haiku image build in Haiku significantly. On
my Core2 Duo 2.2 GHz 2 GB machine about 40% to 20 min 40 s (KDEBUG
disabled, block cache debug disabled). Still more than factor 3 slower
than FreeBSD and Linux, though.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28244 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added "from" address space parameter to vm_swap_address_space()/
arch_vm_aspace_swap().
* The x86 implementation does now maintain a bit mask per
vm_translation_map_arch_info indicating on which CPUs the address
space is active. This allows flush_tmap() to avoid ICI for user
address spaces when the team isn't currently running on any other CPU.
In this context ICI is relatively expensive, particularly since we map
most pages via vm_map_page() and therefore invoke flush_tmap() pretty
much for every single page.
This optimization speeds up a "hello world" compilation about 20% on
my machine (KDEBUG turned off, freshly booted), but interestingly it
has virtually no effect on the "-j2" haiku build time.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27912 a95241bf-73f2-0310-859d-f6bbb57e9c96

Fixed various warnings.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27841 a95241bf-73f2-0310-859d-f6bbb57e9c96

find_nearest() now saves a solution when reaching the max number of solutions and not near enough


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25859 a95241bf-73f2-0310-859d-f6bbb57e9c96

disabled check for memory overlaps for the time being


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24946 a95241bf-73f2-0310-859d-f6bbb57e9c96

reduced MTRR min size to 512KB


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24679 a95241bf-73f2-0310-859d-f6bbb57e9c96

take into account areas starting or ending equally


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24612 a95241bf-73f2-0310-859d-f6bbb57e9c96

now checks if another mtrr range is extended by a new one and extends it


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24582 a95241bf-73f2-0310-859d-f6bbb57e9c96

now fails if a write combining overlaps


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24494 a95241bf-73f2-0310-859d-f6bbb57e9c96

style cleanup
replaced addr_t by uint64
more debug output


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24476 a95241bf-73f2-0310-859d-f6bbb57e9c96

clean up, comments, header


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24452 a95241bf-73f2-0310-859d-f6bbb57e9c96

Fixed warning.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24438 a95241bf-73f2-0310-859d-f6bbb57e9c96

algorithm to find best suited mtrr values to match a memory region. tested ok with 3071MB.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24424 a95241bf-73f2-0310-859d-f6bbb57e9c96

here with 3GB of memory, a 4GB MTRR slot is being written, which triggers a reboot.
we now split more than 2GB MTRR slot, we might improve this and split more and more.
this could fix the bug #1711.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24244 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Cleaned up vm_types.h a bit, and made vm_page, vm_cache, and vm_area
opaque types for C.
* As a result, I've renamed some more source files to .cpp, and fixed
all warnings caused by that.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22326 a95241bf-73f2-0310-859d-f6bbb57e9c96