#
267654 |
|
19-Jun-2014 |
gjb |
Copy stable/9 to releng/9.3 as part of the 9.3-RELEASE cycle.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
256207 |
|
09-Oct-2013 |
mav |
MFC r251703 (by attilio): - Add a BIT_FFS() macro and use it to replace cpusetffs_obj()
|
#
225736 |
|
22-Sep-2011 |
kensmith |
Copy head to stable/9 as part of 9.0-RELEASE release cycle.
Approved by: re (implicit)
|
#
223758 |
|
04-Jul-2011 |
attilio |
With retirement of cpumask_t and usage of cpuset_t for representing a mask of CPUs, pc_other_cpus and pc_cpumask become highly inefficient.
Remove them and replace their usage with custom pc_cpuid magic (as, atm, pc_cpumask can be easilly represented by (1 << pc_cpuid) and pc_other_cpus by (all_cpus & ~(1 << pc_cpuid))).
This change is not targeted for MFC because of struct pcpu members removal and dependency by cpumask_t retirement.
MD review by: marcel, marius, alc Tested by: pluknet MD testing by: marcel, marius, gonzo, andreast
|
#
222813 |
|
07-Jun-2011 |
attilio |
etire the cpumask_t type and replace it with cpuset_t usage.
This is intended to fix the bug where cpu mask objects are capped to 32. MAXCPU, then, can now arbitrarely bumped to whatever value. Anyway, as long as several structures in the kernel are statically allocated and sized as MAXCPU, it is suggested to keep it as low as possible for the time being.
Technical notes on this commit itself: - More functions to handle with cpuset_t objects are introduced. The most notable are cpusetobj_ffs() (which calculates a ffs(3) for a cpuset_t object), cpusetobj_strprint() (which prepares a string representing a cpuset_t object) and cpusetobj_strscan() (which creates a valid cpuset_t starting from a string representation). - pc_cpumask and pc_other_cpus are target to be removed soon. With the moving from cpumask_t to cpuset_t they are now inefficient and not really useful. Anyway, for the time being, please note that access to pcpu datas is protected by sched_pin() in order to avoid migrating the CPU while reading more than one (possible) word - Please note that size of cpuset_t objects may differ between kernel and userland. While this is not directly related to the patch itself, it is good to understand that concept and possibly use the patch as a reference on how to deal with cpuset_t objects in userland, when accessing kernland members. - KTR_CPUMASK is changed and now is represented through a string, to be set as the example reported in NOTES.
Please additively note that no MAXCPU is bumped in this patch, but private testing has been done until to MAXCPU=128 on a real 8x8x2(htt) machine (amd64).
Please note that the FreeBSD version is not yet bumped because of the upcoming pcpu changes. However, note that this patch is not targeted for MFC.
People to thank for the time spent on this patch: - sbruno, pluknet and Nicholas Esborn (nick AT desert DOT net) tested several revision of the patches and really helped in improving stability of this work. - marius fixed several bugs in the sparc64 implementation and reviewed patches related to ktr. - jeff and jhb discussed the basic approach followed. - kib and marcel made targeted review on some specific part of the patch. - marius, art, nwhitehorn and andreast reviewed MD specific part of the patch. - marius, andreast, gonzo, nwhitehorn and jceel tested MD specific implementations of the patch. - Other people have made contributions on other patches that have been already committed and have been listed separately.
Companies that should be mentioned for having participated at several degrees: - Yahoo! for having offered the machines used for testing on big count of CPUs. - The FreeBSD Foundation for having sponsored my devsummit attendance, which has been instrumental. - Sandvine for having offered offices and infrastructure during development.
(I really hope I didn't forget anyone, if it happened I apologize in advance).
|
#
222065 |
|
18-May-2011 |
attilio |
Merge part of r221322 from largeSMP project: Sync XEN support with i386 about the usage of ipi_send_cpu()
Tested by: pluknet MFC after: 2 weeks
|
#
221835 |
|
13-May-2011 |
mav |
Refactor Xen PV code to use new event timers subsystem. That uses one-shot Xen timer and time counter to provide one-shot and periodic time events.
On my tests this reduces idle interruts rate down to about 30Hz, and accor- ding to Xen VM Manager reduces host CPU load by three times comparing to the previous periodic 100Hz clock. Also now, when needed, it is possible to increase HZ rate without useless CPU burning during idle periods.
Now only ia64 and some ARMs left not migrated to the new event timers.
|
#
217072 |
|
06-Jan-2011 |
jhb |
Remove bogus usage of INTR_FAST. "Fast" interrupts are now indicated by registering a filter handler rather than a threaded handler. Also remove a bogus use of INTR_MPSAFE for a filter.
|
#
215587 |
|
20-Nov-2010 |
cperciva |
Add VTOM(va) macro as xpmap_ptom(VTOP(va)) to convert to machine addresses.
Clean up the code by converting xpmap_ptom(VTOP(...)) to VTOM(...) and converting xpmap_ptom(VM_PAGE_TO_PHYS(...)) to VM_PAGE_TO_MACH(...). In a few places we take advantage of the fact that xpmap_ptom can commute with setting PG_* flags.
This commit should have no net effect save to improve the readability of this code.
|
#
214631 |
|
01-Nov-2010 |
jhb |
Move <machine/apicreg.h> to <x86/apicreg.h>.
|
#
210939 |
|
06-Aug-2010 |
jhb |
Add a new ipi_cpu() function to the MI IPI API that can be used to send an IPI to a specific CPU by its cpuid. Replace calls to ipi_selected() that constructed a mask for a single CPU with calls to ipi_cpu() instead. This will matter more in the future when we transition from cpumask_t to cpuset_t for CPU masks in which case building a CPU mask is more expensive.
Submitted by: peter, sbruno Reviewed by: rookie Obtained from: Yahoo! (x86) MFC after: 1 month
|
#
204972 |
|
10-Mar-2010 |
jhb |
Make NKPT a kernel option on i386 so that it can be set to a non-default value from kernel config files.
Tested by: Charles Sprickman spork of bway net MFC after: 2 weeks
|
#
202084 |
|
11-Jan-2010 |
alc |
Eliminate an unused declaration.
|
#
196256 |
|
15-Aug-2009 |
attilio |
Port recent IPI enhachements to en: * Introduce the ipi_nmi_handler() function for the Xen infrastructure * Fixup adeguately the ipi sender functions
Approved by: re (kib)
|
#
196196 |
|
13-Aug-2009 |
attilio |
* Completely Remove the option STOP_NMI from the kernel. This option 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)
|
#
194784 |
|
23-Jun-2009 |
jeff |
Implement a facility for dynamic per-cpu variables. - 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
|
#
193154 |
|
31-May-2009 |
adrian |
Fix the MP IPI code to differentiate between bitmapped IPIs and function IPIs.
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
|
#
193153 |
|
31-May-2009 |
adrian |
Remove some unused code in ipi_selected() .
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.
|
#
193098 |
|
30-May-2009 |
adrian |
Even though I'm not quite sure that the call_func stuff will work properly 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.
|
#
193094 |
|
30-May-2009 |
adrian |
Don't schedule a CALL_FUNCTION_VECTOR software IPI if the IPI was signaled via the bitmap (and thus sent via RESCHEDULE_VECTOR.)
|
#
193082 |
|
30-May-2009 |
adrian |
Correctly report the IPI IRQs being created; make it clear what vectors they are for.
|
#
192114 |
|
14-May-2009 |
attilio |
FreeBSD right now support 32 CPUs on all the architectures at least. 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>
|
#
191759 |
|
02-May-2009 |
kmacy |
fix XEN compilation
|
#
189420 |
|
05-Mar-2009 |
jhb |
Remove unused arg from npxinit(). Forgot to commit this file in the last i386 FPU change.
|
#
187966 |
|
31-Jan-2009 |
bz |
Bring over the code from sys/i386/i386/mp_machdep.c, r187880 to make XEN config compile again: - Allocate apic vectors on a per-cpu basis.
|
#
186557 |
|
29-Dec-2008 |
kmacy |
merge 186535, 186537, and 186538 from releng_7_xen
Log: - merge in latest xenbus from dfr's xenhvm - fix race condition in xs_read_reply by converting tsleep to mtx_sleep
Log: unmask evtchn in bind_{virq, ipi}_to_irq
Log: - remove code for handling case of not being able to sleep - eliminate tsleep - make sleeps atomic
|
#
184224 |
|
24-Oct-2008 |
kmacy |
Fix general issues with IPI support
|
#
184198 |
|
23-Oct-2008 |
kmacy |
Fix IPI support
|
#
184115 |
|
21-Oct-2008 |
kmacy |
Hook in ipi handlers
|
#
184112 |
|
21-Oct-2008 |
kmacy |
Implement infrastructure for gluing i386 ipi functions in to xen's infrastructure
|
#
183439 |
|
28-Sep-2008 |
marius |
Remove ipi_all() and ipi_self() as the former hasn't been used at all to date and the latter also is only used in ia64 and powerpc code which no longer serves a real purpose after bring-up and just can be removed as well. Note that architectures like sun4u also provide no means of implementing IPI'ing a CPU itself natively in the first place.
Suggested by: jhb Reviewed by: arch, grehan, jhb
|
#
183379 |
|
26-Sep-2008 |
kmacy |
move ipi_pcpu to evtchn.c
|
#
183345 |
|
25-Sep-2008 |
kmacy |
add initial ipi definitions
MFC after: 1 month
|
#
183132 |
|
18-Sep-2008 |
kmacy |
Change order of pcpu initialization so the pc_prvspace is set
MFC after: 1 month
|
#
183131 |
|
17-Sep-2008 |
kmacy |
fix initial page directory setup for APs to work when KERNBASE < 0xc0000000
MFC after: 1 month
|
#
182902 |
|
10-Sep-2008 |
kmacy |
Get initial bootstrap of APs working under xen. Note that the APs still blow up in sched_throw().
MFC after: 1 month
|