summaryrefslogtreecommitdiffstats
path: root/sys/i386/xen
Commit message (Collapse)AuthorAgeFilesLines
* Make NKPT a kernel option on i386 so that it can be set to a non-defaultjhb2010-03-101-0/+1
| | | | | | | value from kernel config files. Tested by: Charles Sprickman spork of bway net MFC after: 2 weeks
* Introduce the new kernel sub-tree x86 which should contain all the codeattilio2010-02-251-2/+2
| | | | | | | | | | | | | | shared and generalized between our current amd64, i386 and pc98. This is just an initial step that should lead to a more complete effort. For the moment, a very simple porting of cpufreq modules, BIOS calls and the whole MD specific ISA bus part is added to the sub-tree but ideally a lot of code might be added and more shared support should grow. Sponsored by: Sandvine Incorporated Reviewed by: emaste, kib, jhb, imp Discussed on: arch MFC: 3 weeks
* - fix bootstrap for variable KVA_PAGESkmacy2010-02-212-85/+55
| | | | | | | - remove unused CADDR1 - hold lock across page table update MFC after: 3 days
* Allow the pmap code to be built with GCC from FreeBSD 7 again.ed2010-02-181-0/+4
| | | | | | | | | This patch basically gives us the best of both worlds. Instead of forcing the compiler to emulate GNU-style inline semantics even though we're using ISO C99, it will only use GNU-style inlining when the compiler is configured that way (__GNUC_GNU_INLINE__). Tested by: jhb
* Recommit r193732:ed2010-01-191-1/+1
| | | | | | | | | | | | | | | | Remove __gnu89_inline. Now that we use C99 almost everywhere, just use C99-style in the pmap code. Since the pmap code is the only consumer of __gnu89_inline, remove it from cdefs.h as well. Because the flag was only introduced 17 months ago, I don't expect any problems. Reviewed by: alc It was backed out, because it prevented us from building kernels using a 7.x compiler. Now that most people use 8.x, there is nothing that holds us back. Even if people run 7.x, they should be able to build a kernel if they run `make kernel-toolchain' or `make buildworld' first.
* Eliminate an unused declaration.alc2010-01-111-3/+0
|
* Eliminate unused declarations.alc2010-01-101-3/+0
|
* Unbreak the XEN build after r201751.bz2010-01-081-0/+4
|
* Make pmap_set_pg() static.alc2010-01-071-1/+2
|
* Eliminate unused variables (see r137912).alc2010-01-071-2/+0
|
* - revert pmap_kenter_temporary to taking a physical addresskmacy2009-12-101-1/+2
| | | | - make minidump work
* i386 has not (yet) any DEV_ATPIC conditional than axe it out from Xenattilio2009-11-271-4/+0
| | | | | | version. No objections by: kmacy
* fixup kernel core dumps on paravirtual guestskmacy2009-11-241-1/+1
|
* reflect that pg_ps_enabled is a tunable, not just a read-only sysctlavg2009-11-111-1/+1
| | | | Nod from: jhb
* o Introduce vm_sync_icache() for making the I-cache coherent withmarcel2009-10-211-0/+5
| | | | | | | | | | | | | | | | | | | | | the memory or D-cache, depending on the semantics of the platform. vm_sync_icache() is basically a wrapper around pmap_sync_icache(), that translates the vm_map_t argumument to pmap_t. o Introduce pmap_sync_icache() to all PMAP implementation. For powerpc it replaces the pmap_page_executable() function, added to solve the I-cache problem in uiomove_fromphys(). o In proc_rwmem() call vm_sync_icache() when writing to a page that has execute permissions. This assures that when breakpoints are written, the I-cache will be coherent and the process will actually hit the breakpoint. o This also fixes the Book-E PMAP implementation that was missing necessary locking while trying to deal with the I-cache coherency in pmap_enter() (read: mmu_booke_enter_locked). The key property of this change is that the I-cache is made coherent *after* writes have been done. Doing it in the PMAP layer when adding or changing a mapping means that the I-cache is made coherent *before* any writes happen. The difference is key when the I-cache prefetches.
* make read_eflags and write_eflags accomplish the same effect on PVM as native,kmacy2009-10-011-10/+32
| | | | simplifying interrupt handling
* fix UP compilationkmacy2009-09-111-2/+0
|
* Consolidate CPUID to CPU family/model macros for amd64 and i386 to reducejkim2009-09-101-1/+1
| | | | unnecessary #ifdef's for shared code between them.
* As was done in r196643 for i386 and amd64, swap the start/end virtualkib2009-09-091-2/+2
| | | | | | | | addresses in pmap_invalidate_cache_range(). Reported by: Vincent Hoffman <vince unsane co uk> Reviewed by: jhb MFC after: 3 days
* Delete whitespace not in i386/pmap.cadrian2009-09-011-1/+0
|
* Migrate to use cpuset_t.adrian2009-09-011-5/+4
|
* Merge in the pat_works work from sys/i386/i386/pmap.c - primarily to reduceadrian2009-09-011-65/+74
| | | | diff size.
* Fix broken build.adrian2009-09-011-0/+1
|
* Revert previous commit; that was left-over junk in the tree.adrian2009-08-311-0/+2
|
* Shuffle pagezero() into the same location as in sys/i386/i386/pmap.c.adrian2009-08-312-18/+16
|
* Port recent IPI enhachements to en:attilio2009-08-151-0/+38
| | | | | | | * Introduce the ipi_nmi_handler() function for the Xen infrastructure * Fixup adeguately the ipi sender functions Approved by: re (kib)
* * Completely Remove the option STOP_NMI from the kernel. This optionattilio2009-08-131-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | has proven to have a good effect when entering KDB by using a NMI, but it completely violates all the good rules about interrupts disabled while holding a spinlock in other occasions. This can be the cause of deadlocks on events where a normal IPI_STOP is expected. * Adds an new IPI called IPI_STOP_HARD on all the supported architectures. This IPI is responsible for sending a stop message among CPUs using a privileged channel when disponible. In other cases it just does match a normal IPI_STOP. Right now the IPI_STOP_HARD functionality uses a NMI on ia32 and amd64 architectures, while on the other has a normal IPI_STOP effect. It is responsibility of maintainers to eventually implement an hard stop when necessary and possible. * Use the new IPI facility in order to implement a new userend SMP kernel function called stop_cpus_hard(). That is specular to stop_cpu() but it does use the privileged channel for the stopping facility. * Let KDB use the newly introduced function stop_cpus_hard() and leave stop_cpus() for all the other cases * Disable interrupts on CPU0 when starting the process of APs suspension. * Style cleanup and comments adding This patch should fix the reboot/shutdown deadlocks many users are constantly reporting on mailing lists. Please don't forget to update your config file with the STOP_NMI option removal Reviewed by: jhb Tested by: pho, bz, rink Approved by: re (kib)
* Fix XEN build breakage, by implementing pmap_invalidate_cache_range()kib2009-07-291-16/+88
| | | | | | | and using it when appropriate. Merge analogue of the r195836 optimization to XEN. Approved by: re (kensmith)
* Add a new type of VM object: OBJT_SG. An OBJT_SG object is very similar tojhb2009-07-241-1/+1
| | | | | | | | | | | a device pager (OBJT_DEVICE) object in that it uses fictitious pages to provide aliases to other memory addresses. The primary difference is that it uses an sglist(9) to determine the physical addresses for a given offset into the object instead of invoking the d_mmap() method in a device driver. Reviewed by: alc Approved by: re (kensmith) MFC after: 2 weeks
* Change the handling of fictitious pages by pmap_page_set_memattr() onalc2009-07-191-0/+19
| | | | | | | | | | | | | | | | | amd64 and i386. Essentially, fictitious pages provide a mechanism for creating aliases for either normal or device-backed pages. Therefore, pmap_page_set_memattr() on a fictitious page needn't update the direct map or flush the cache. Such actions are the responsibility of the "primary" instance of the page or the device driver that "owns" the physical address. For example, these actions are already performed by pmap_mapdev(). The device pager needn't restore the memory attributes on a fictitious page before releasing it. It's now pointless. Add pmap_page_set_memattr() to the Xen pmap. Approved by: re (kib)
* Add support to the virtual memory system for configuring machine-alc2009-07-121-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dependent memory attributes: Rename vm_cache_mode_t to vm_memattr_t. The new name reflects the fact that there are machine-dependent memory attributes that have nothing to do with controlling the cache's behavior. Introduce vm_object_set_memattr() for setting the default memory attributes that will be given to an object's pages. Introduce and use pmap_page_{get,set}_memattr() for getting and setting a page's machine-dependent memory attributes. Add full support for these functions on amd64 and i386 and stubs for them on the other architectures. The function pmap_page_set_memattr() is also responsible for any other machine-dependent aspects of changing a page's memory attributes, such as flushing the cache or updating the direct map. The uses include kmem_alloc_contig(), vm_page_alloc(), and the device pager: kmem_alloc_contig() can now be used to allocate kernel memory with non-default memory attributes on amd64 and i386. vm_page_alloc() and the device pager will set the memory attributes for the real or fictitious page according to the object's default memory attributes. Update the various pmap functions on amd64 and i386 that map pages to incorporate each page's memory attributes in the mapping. Notes: (1) Inherent to this design are safety features that prevent the specification of inconsistent memory attributes by different mappings on amd64 and i386. In addition, the device pager provides a warning when a device driver creates a fictitious page with memory attributes that are inconsistent with the real page that the fictitious page is an alias for. (2) Storing the machine-dependent memory attributes for amd64 and i386 as a dedicated "int" in "struct md_page" represents a compromise between space efficiency and the ease of MFCing these changes to RELENG_7. In collaboration with: jhb Approved by: re (kib)
* PAE adds another level to the i386 page table. This level is a smallalc2009-07-051-6/+5
| | | | | | | | | | | | | | | | | | | | | | 4-entry table that must be located within the first 4GB of RAM. This requirement is met by defining an UMA zone with a custom back-end allocator function. This revision makes two changes to this back-end allocator function: (1) It replaces the use of contigmalloc() with the use of kmem_alloc_contig(). This eliminates "double accounting", i.e., accounting by both the UMA zone and malloc tags. (I made the same change for the same reason to the zones supporting jumbo frames a week ago.) (2) It passes through the "wait" parameter, i.e., M_WAITOK, M_ZERO, etc. to kmem_alloc_contig() rather than ignoring it. pmap_init() calls uma_zalloc() with both M_WAITOK and M_ZERO. At the moment, this is harmless only because the default behavior of contigmalloc()/kmem_alloc_contig() is to wait and because pmap_init() doesn't really depend on the memory being zeroed. The back-end allocator function in the Xen pmap is dead code. I am changing it nonetheless because I don't want to leave any "bad examples" in the source tree for someone to copy at a later date. Approved by: re (kib)
* Implement a facility for dynamic per-cpu variables.jeff2009-06-231-0/+1
| | | | | | | | | | | | | | | - Modules and kernel code alike may use DPCPU_DEFINE(), DPCPU_GET(), DPCPU_SET(), etc. akin to the statically defined PCPU_*. Requires only one extra instruction more than PCPU_* and is virtually the same as __thread for builtin and much faster for shared objects. DPCPU variables can be initialized when defined. - Modules are supported by relocating the module's per-cpu linker set over space reserved in the kernel. Modules may fail to load if there is insufficient space available. - Track space available for modules with a one-off extent allocator. Free may block for memory to allocate space for an extent. Reviewed by: jhb, rwatson, kan, sam, grehan, marius, marcel, stas
* Revert my change; reintroduce __gnu89_inline.ed2009-06-081-1/+1
| | | | | | | | | It turns out our compiler in stable/7 can't build this code anymore. Even though my opinion is that those people should just run `make kernel-toolchain' before building a kernel, I am willing to wait and commit this after we've branched stable/8. Requested by: rwatson
* Remove __gnu89_inline.ed2009-06-081-1/+1
| | | | | | | | | Now that we use C99 almost everywhere, just use C99-style in the pmap code. Since the pmap code is the only consumer of __gnu89_inline, remove it from cdefs.h as well. Because the flag was only introduced 17 months ago, I don't expect any problems. Reviewed by: alc
* Fix the MP IPI code to differentiate between bitmapped IPIs and function IPIs.adrian2009-05-311-12/+7
| | | | | | | | | | | | | | | | This attempts to fix the IPI handling code to correctly differentiate between bitmapped IPIs and function IPIs. The Xen IPIs were on low numbers which clashed with the bitmapped IPIs. This commit bumps those IPI numbers up to 240 and above (just like in the i386 code) and fiddles with the ipi_vectors[] logic to call the correct function. This still isn't "right". Specifically, the IPI code may work fine for TLB shootdown events but the rendezvous/lazypmap IPIs are thrown by calling ipi_*() routines which don't set the call_func stuff (function id, addr1, addr2) that the TLB shootdown events are. So the Xen SMP support is still broken. PR: 135069
* Remove some unused code in ipi_selected() .adrian2009-05-311-5/+0
| | | | | | The code path this was copied from (sys/i386/i386/mp_machdep.c:ipi_selected()) handles bitmap'ed IPIs and normal IPIs via separate notification paths. Xen SMP handles them the same way.
* Even though I'm not quite sure that the call_func stuff will work properlyadrian2009-05-301-2/+3
| | | | | | | | | in all the places/cases IPI messages will be generated, at least be consistent with how the call_data pointer is assigned and cleared (ie, all done inside the spinlock. Ensure that its NULL before continuing, just to try and identify situations where things are going horribly wrong.
* Don't schedule a CALL_FUNCTION_VECTOR software IPI if the IPI was signaledadrian2009-05-301-3/+3
| | | | via the bitmap (and thus sent via RESCHEDULE_VECTOR.)
* Correctly report the IPI IRQs being created; make it clear what vectors they ↵adrian2009-05-301-4/+4
| | | | are for.
* Fix the Xen TOD update when the hypervisor wall clock is nudged.adrian2009-05-291-0/+14
| | | | | | | | | | | | | | | | | | | | | The "wall clock" in the current code is actually the hypervisor start time. The time of day is the "start time" plus the hypervisor "uptime". Large enough bumps in the dom0 clock lead to a hypervisor "bump" which is implemented as a bump in the start time, not the uptime. The clock.c routines were reading in the hypervisor start time and then using this as the TOD. This meant that any hypervisor time bump would cause the FreeBSD DomU to set its TOD to the hypervisor start time, rather than the actual TOD. This fix is a bit hacky and some reshuffling should be done later on to clarify what is going on. I've left the wall clock code alone. (The code which updates shadow_tv and shadow_tv_version.) A new routine adds the uptime to the shadow_tv, which is then used to update the TOD. I've included some debugging so it is obvious when the clock is nudged. PR: 135008
* Migrate the Xen hypervisor clock reading routines into somethingadrian2009-05-292-49/+103
| | | | sharable.
* Say hello to a very basic, read-only, Xen Hypervisor RTC.adrian2009-05-281-0/+191
| | | | | | | | | | | | | | The hypervisor doesn't provide a single "TOD" - it instead provides a "start time" and a "running time". These are added together to form the current TOD. The TOD is in UTC. This RTC is only (initially) designed to be read at startup. There's some further poking that needs to happen to pick up hypervisor time changes (ie, by the Dom0 time being adjusted by something). This time adjustment currently can cause "weird stuff" in the DomU clock; I'll begin investigating and repairing that in subsequent commits. PR: 135008
* FreeBSD right now support 32 CPUs on all the architectures at least.attilio2009-05-141-61/+5
| | | | | | | | | | | | | | | | With the arrival of 128+ cores it is necessary to handle more than that. One of the first thing to change is the support for cpumask_t that needs to handle more than 32 bits masking (which happens now). Some places, however, still assume that cpumask_t is a 32 bits mask. Fix that situation by using always correctly cpumask_t when needed. While here, remove the part under STOP_NMI for the Xen support as it is broken in any case. Additively make ipi_nmi_pending as static. Reviewed by: jhb, kmacy Tested by: Giovanni Trematerra <giovanni dot trematerra at gmail dot com>
* Rename statclock_disable variable to atrtcclock_disable that it actually is,mav2009-05-031-1/+0
| | | | | | | | | | | | | and hide it inside of atrtc driver. Add new tunable hint.atrtc.0.clock controlling it. Setting it to 0 disables using RTC clock as stat-/ profclock sources. Teach i386 and amd64 SMP platforms to emulate stat-/profclocks using i8254 hardclock, when LAPIC and RTC clocks are disabled. This allows to reduce global interrupt rate of idle system down to about 100 interrupts per core, permitting C3 and deeper C-states provide maximum CPU power efficiency.
* fix XEN compilationkmacy2009-05-021-0/+3
|
* Fix the Xen build for i386 PV mode.dfr2009-04-012-1/+101
|
* Remove unused arg from npxinit(). Forgot to commit this file in thejhb2009-03-051-1/+1
| | | | last i386 FPU change.
* - fix formattingkmacy2009-02-151-68/+25
| | | | - fix types in ticks_to_system_time
* Remove unnecessary page queues locking around vm_page_wakeup().alc2009-02-141-2/+0
| | | | Approved by: kmacy
OpenPOWER on IntegriCloud