| History log of /src/sys/arch/xen/x86/xen_ipi.c |
| Revision | | Date | Author | Comments |
| 1.42 |
| 06-Nov-2023 |
rin | xen_ipi: valid_ipimask: Sprinkle __diagused to fix clang !DIAGNOSTIC build
|
| 1.41 |
| 06-Aug-2023 |
riastradh | xen/x86: Get the right intrframe pointer in ddb ipi.
This was broken with the transition from evtchn_set_handler to
intr_establish_xname in 2017, remained broken with the transition
from intr_establish_xname to xen_intr_establish_xname in 2018, and
still remained broken when xen_intr_establish_xname was changed back
to evtchn_set_handler in 2020.
The mechanism is grody -- instead of a secret second argument to the
interrupt handler, the intrframe pointer should be replaced by a
struct cpu_info member that is saved and restored by the interrupt
handler calling logic. But we should make sure the replacement
actually works first -- which is not trivial in part because the
users are hidden behind sketchy function pointer casts.
With any luck, this will make `mach cpu N' work in ddb on Xen.
XXX pullup-10
XXX pullup-9 (by patch)
|
| 1.40 |
| 05-Jan-2022 |
christos | branches: 1.40.4;
remove DIAGNOSTIC so that function is defined for KASSERTMSG. Hope that the
compiler removes it.
|
| 1.39 |
| 07-May-2020 |
bouyer | Change event_set_handler() to take the target CPU parameter. If ci is NULL,
event_set_handler() will choose the CPU and bind the event.
If ci is not NULL the caller is responsible for binding the event.
Use a IPI xcall to register the handlers if needed.
pull in a hack from x86 to force pirq handlers to be mpsafe if registered at
a level != IPL_VM. This is for the com at isa interrupt handler, which
registers at IPL_HIGH and has to way to tell it's mpsafe (taking
KERNEL_LOCK at IPL_HIGH causes deadlocks on MP systems).
|
| 1.38 |
| 25-Apr-2020 |
bouyer | Merge the bouyer-xenpvh branch, bringing in Xen PV drivers support under HVM
guests in GENERIC.
Xen support can be disabled at runtime with
boot -c
disable hypervisor
|
| 1.37 |
| 21-Apr-2020 |
ad | Remove spurious reference to XEN_IPI_KICK - it represents the absence of
a specific IPI type.
|
| 1.36 |
| 13-Apr-2020 |
bouyer | By default, events are bound to CPU 0 (exept for IPIs and VTIMERs which
are bound to a different CPU at creation time).
Recent MI changes caused the scheduler to choose a different CPU when
probing and attaching xennet devices (I guess it's the xenbus thread which
runs on a different CPU). This cause the callback to be called on a different
CPU than the one expected by the kernel, and the event is ignored.
It is handled when the clock causes the callback to be called on the right
CPU, which is why xennet still run, but slowly.
Change event_set_handler() to do a EVTCHNOP_bind_vcpu if requested to,
and make sure we don't do it for IPIs and VIRQs (for theses, the op fails).
|
| 1.35 |
| 01-Dec-2019 |
ad | branches: 1.35.6;
Fix false sharing problems with cpu_info. Identified with tprof(8).
This was a very nice win in my tests on a 48 CPU box.
- Reorganise cpu_data slightly according to usage.
- Put cpu_onproc into struct cpu_info alongside ci_curlwp (now is ci_onproc).
- On x86, put some items in their own cache lines according to usage, like
the IPI bitmask and ci_want_resched.
|
| 1.34 |
| 23-Nov-2019 |
ad | cpu_need_resched():
- Remove all code that should be MI, leaving the bare minimum under arch/.
- Make the required actions very explicit.
- Pass in LWP pointer for convenience.
- When a trap is required on another CPU, have the IPI set it locally.
- Expunge cpu_did_resched().
|
| 1.33 |
| 12-Oct-2019 |
maxv | Rewrite the FPU code on x86. This greatly simplifies the logic and removes
the dependency on IPL_HIGH. NVMM is updated accordingly. Posted on
port-amd64 a week ago.
Bump the kernel version to 9.99.16.
|
| 1.32 |
| 02-Feb-2019 |
cherry | branches: 1.32.4;
Switch NetBSD/xen to use XEN api tag RELEASE-4.11.1
The headers for this api are in sys/external/mit/xen-include-public/dist/
|
| 1.31 |
| 27-Jan-2019 |
dholland | fix duplicated chunk from merge
|
| 1.30 |
| 27-Jan-2019 |
pgoyette | Merge the [pgoyette-compat] branch
|
| 1.29 |
| 24-Dec-2018 |
cherry | Bifurcate the interrupt establish functions between XEN and non-XEN
Thus intr_establish_xname() becomes xen_intr_establish_xname() etc.
One consequence of this is that dom0 devices expect the native
function calls to be available and we thus provide weak aliasing for
dom0 builds to succeed. XEN and non-XEN devices are distinguished by
the PIC they are established on. XEN interrupts are exclusively
established on xen_pic, while dom0 interrupts are established on
natively available PICs.
This allows us an orthogonal path to xen device management (eg:
xenstore events) in XENPVHVM, without having to worry about unifying
the vector entry paths, etc., which is quite challenging.
|
| 1.28 |
| 26-Oct-2018 |
cherry | Decompose hypervisor_enable_event() into functional steps.
The hypervisor_unmask_event() step is relevant for any event.
The pirq related step is only relevant for pirq bound events.
Prune blanket usage of this, so that usage is semantically appropriate.
|
| 1.27 |
| 24-Oct-2018 |
cherry | When using the intr_establish_xname() interface to register
XEN events, follow established x86/intr.c conventions - set
the 'legacy' irq value to -1, to indicate that the pic, pin
combination (&xen_pic, port) is used for registration.
|
| 1.26 |
| 24-Jul-2018 |
bouyer | Fix what looks like a typo in xen_send_ipi():
ci != NULL || ci != curcpu()
is always true
|
| 1.25 |
| 24-Jun-2018 |
jdolecek | branches: 1.25.2;
add support for kern.intr.list aka intrctl(8) 'list' for xen
event_set_handler() and pirq_establish() now have extra intrname
parameter; shared intr_create_intrid() is used to provide the value
xen drivers were changed to pass the specific driver instance
name as the xname, e.g. 'vcpu0 clock' instead just 'clock', or
'xencons0' instead of 'xencons'
associated evcnt is now changed to use intrname - this matches native x86
|
| 1.24 |
| 23-Jun-2018 |
jdolecek | make compile without DDB
PR port-xen/50282
|
| 1.23 |
| 06-Nov-2017 |
cherry | branches: 1.23.2;
Switch XEN drivers to use intr_establish_xname()/intr_disestablish()
This completes the API transition.
|
| 1.22 |
| 15-Aug-2017 |
maxv | Remove unused arg, to have the same definition as amd64.
|
| 1.21 |
| 12-Aug-2017 |
maxv | Remove vm86.
Pass 3.
|
| 1.20 |
| 07-Jul-2016 |
msaitoh | branches: 1.20.10;
KNF. Remove extra spaces. No functional change.
|
| 1.19 |
| 07-Feb-2015 |
joerg | valid_ipimask is only used under DIAGNOSTIC, so only define it then.
|
| 1.18 |
| 19-May-2014 |
rmind | branches: 1.18.2; 1.18.4;
Implement MI IPI interface with cross-call support.
|
| 1.17 |
| 12-Feb-2014 |
dsl | branches: 1.17.2;
Change i386 to use x86/fpu.c instead of i386/isa/npx.c
This changes the trap10 and trap13 code to call directly into fpu.c,
removing all the code for T_ARITHTRAP, T_XMM and T_FPUNDA from i386/trap.c
Not all of the code thate appeared to handle fpu traps was ever called!
Most of the changes just replace the include of machine/npx.h with x86/fpu.h
(or remove it entirely).
|
| 1.16 |
| 11-Feb-2014 |
dsl | Move sys/arch/amd64/amd64/fpu.c and sys/arch/amd64/include/fpu.h
into sys/arch/x86 in preparation for using the same code for i386.
|
| 1.15 |
| 26-Jan-2014 |
dsl | Remove support for 'external' floating point units and the MS-DOS
compatible method of handling floating point exceptions.
Make kernel support for teh fpu non-optional (486SX should still work).
Only 386 cpus support external fpu, and i386 support was removed years ago.
This means that the npx code no longer uses port 0xf0 or interupt 13.
All the "npx at isa" lines go from the configs, arch/i386/isa/npx.c
is now mandatory for all i386 kernels.
I've renamed npxinit() to fpuinit() and npxinit_cpu() to fpuinit_cpu()
to match the very similar amd64 functions.
The fpu of the boot cpu is now initialised by a direct call from
cpu_configure(), this enables FP emulation for a 486SX.
(for amd64 the cr0 values are set in locore.S and similar).
This fixes a long-standing bug in linux_setregs() - which did not
save the fpu regsiters if they were active.
I've test booted a single cpu i386 kernel (using anita).
amd64 builds - none of teh changes should affect it.
The i386 XEN kernels build, but I'm not sure where they set cr0, and
it might have got lost!
|
| 1.14 |
| 01-Dec-2013 |
christos | revert fpu/pcu changes until we figure out what's wrong; they cause random
freezes
|
| 1.13 |
| 23-Oct-2013 |
drochner | Use the MI "pcu" framework for bookkeeping of npx/fpu states on x86.
This reduces the amount of MD code enormously, and makes it easier
to implement support for newer CPU features which require more fpu
state, or for fpu usage by the kernel.
For access to FPU state across CPUs, an xcall kthread is used now
rather than a dedicated IPI.
No user visible changes intended.
|
| 1.12 |
| 14-Sep-2013 |
joerg | GC max_cpus.
|
| 1.11 |
| 27-Dec-2012 |
cherry | branches: 1.11.2;
Remove unused header evtchn.h from intr.h
|
| 1.10 |
| 17-Feb-2012 |
bouyer | branches: 1.10.2;
Apply patch proposed in PR port-xen/45975 (this does not solve the exact
problem reported here but is part of the solution):
xen_kpm_sync() is not working as expected,
leading to races between CPUs.
1 the check (xpq_cpu != &x86_curcpu) is always false because we
have different x86_curcpu symbols with different addresses in the kernel.
Fortunably, all addresses dissaemble to the same code.
Because of this we always use the code intended for bootstrap, which doesn't
use cross-calls or lock.
2 once 1 above is fixed, xen_kpm_sync() will use xcalls to sync other CPUs,
which cause it to sleep and pmap.c doesn't like that. It triggers this
KASSERT() in pmap_unmap_ptes():
KASSERT(pmap->pm_ncsw == curlwp->l_ncsw);
3 pmap->pm_cpus is not safe for the purpose of xen_kpm_sync(), which
needs to know on which CPU a pmap is loaded *now*:
pmap->pm_cpus is cleared before cpu_load_pmap() is called to switch
to a new pmap, leaving a window where a pmap is still in a CPU's
ci_kpm_pdir but not in pm_cpus. As a virtual CPU may be preempted
by the hypervisor at any time, it can be large enough to let another
CPU free the PTP and reuse it as a normal page.
To fix 2), avoid cross-calls and IPIs completely, and instead
use a mutex to update all CPU's ci_kpm_pdir from the local CPU.
It's safe because we just need to update the table page, a tlbflush IPI will
happen later. As a side effect, we don't need a different code for bootstrap,
fixing 1). The mutex added to struct cpu needs a small headers reorganisation.
to fix 3), introduce a pm_xen_ptp_cpus which is updated from
cpu_pmap_load(), whith the ci_kpm_mtx mutex held. Checking it with
ci_kpm_mtx held will avoid overwriting the wrong pmap's ci_kpm_pdir.
While there I removed the unused pmap_is_active() function;
and added some more details to DIAGNOSTIC panics.
|
| 1.9 |
| 30-Dec-2011 |
cherry | branches: 1.9.2;
Remove spurious (debug) printf()
|
| 1.8 |
| 28-Dec-2011 |
cherry | Remove temporary variable definition that is unused in non DIAGNOSTIC builds.
|
| 1.7 |
| 07-Dec-2011 |
cegger | switch from xen3-public to xen-public.
|
| 1.6 |
| 07-Nov-2011 |
cherry | branches: 1.6.4;
Add an ipi callback to force hypervisor callback. this is useful to "re-route" interrupts to a given vcpu
|
| 1.5 |
| 27-Sep-2011 |
jym | branches: 1.5.2;
Modify *ASSERTMSG() so they are now used as variadic macros. The main goal
is to provide routines that do as KASSERT(9) says: append a message
to the panic format string when the assertion triggers, with optional
arguments.
Fix call sites to reflect the new definition.
Discussed on tech-kern@. See
http://mail-index.netbsd.org/tech-kern/2011/09/07/msg011427.html
|
| 1.4 |
| 15-Aug-2011 |
cherry | branches: 1.4.2;
invert buggy ci_flag test
|
| 1.3 |
| 10-Aug-2011 |
cherry | KNF police (rmind@ :-)
|
| 1.2 |
| 10-Aug-2011 |
cherry | xen ipi infrastructure
|
| 1.1 |
| 03-Jun-2011 |
cherry | branches: 1.1.2;
file xen_ipi.c was initially added on branch cherry-xenmp.
|
| 1.1.2.4 |
| 18-Sep-2011 |
cherry | Use an IPI to re-route events to the cpu where the handler has been registered
|
| 1.1.2.3 |
| 17-Aug-2011 |
cherry | Pullup relevant changes from -current
|
| 1.1.2.2 |
| 31-Jul-2011 |
cherry | grow MP support for i386. boots to single user
|
| 1.1.2.1 |
| 03-Jun-2011 |
cherry | Initial import of xen MP sources, with kernel and userspace tests.
- this is a source priview.
- boots to single user.
- spurious interrupt and pmap related panics are normal
|
| 1.4.2.2 |
| 27-Aug-2011 |
jym | Add/remove files, like in HEAD.
|
| 1.4.2.1 |
| 15-Aug-2011 |
jym | file xen_ipi.c was added on branch jym-xensuspend on 2011-08-27 15:59:49 +0000
|
| 1.5.2.4 |
| 22-May-2014 |
yamt | sync with head.
for a reference, the tree before this commit was tagged
as yamt-pagecache-tag8.
this commit was splitted into small chunks to avoid
a limitation of cvs. ("Protocol error: too many arguments")
|
| 1.5.2.3 |
| 23-Jan-2013 |
yamt | sync with head
|
| 1.5.2.2 |
| 17-Apr-2012 |
yamt | sync with head
|
| 1.5.2.1 |
| 10-Nov-2011 |
yamt | sync with head
|
| 1.6.4.1 |
| 18-Feb-2012 |
mrg | merge to -current.
|
| 1.9.2.1 |
| 22-Feb-2012 |
riz | Pull up following revision(s) (requested by bouyer in ticket #29):
sys/arch/xen/x86/x86_xpmap.c: revision 1.39
sys/arch/xen/include/hypervisor.h: revision 1.37
sys/arch/xen/include/intr.h: revision 1.34
sys/arch/xen/x86/xen_ipi.c: revision 1.10
sys/arch/x86/x86/cpu.c: revision 1.97
sys/arch/x86/include/cpu.h: revision 1.48
sys/uvm/uvm_map.c: revision 1.315
sys/arch/x86/x86/pmap.c: revision 1.165
sys/arch/xen/x86/cpu.c: revision 1.81
sys/arch/x86/x86/pmap.c: revision 1.167
sys/arch/xen/x86/cpu.c: revision 1.82
sys/arch/x86/x86/pmap.c: revision 1.168
sys/arch/xen/x86/xen_pmap.c: revision 1.17
sys/uvm/uvm_km.c: revision 1.122
sys/uvm/uvm_kmguard.c: revision 1.10
sys/arch/x86/include/pmap.h: revision 1.50
Apply patch proposed in PR port-xen/45975 (this does not solve the exact
problem reported here but is part of the solution):
xen_kpm_sync() is not working as expected,
leading to races between CPUs.
1 the check (xpq_cpu != &x86_curcpu) is always false because we
have different x86_curcpu symbols with different addresses in the kernel.
Fortunably, all addresses dissaemble to the same code.
Because of this we always use the code intended for bootstrap, which doesn't
use cross-calls or lock.
2 once 1 above is fixed, xen_kpm_sync() will use xcalls to sync other CPUs,
which cause it to sleep and pmap.c doesn't like that. It triggers this
KASSERT() in pmap_unmap_ptes():
KASSERT(pmap->pm_ncsw == curlwp->l_ncsw);
3 pmap->pm_cpus is not safe for the purpose of xen_kpm_sync(), which
needs to know on which CPU a pmap is loaded *now*:
pmap->pm_cpus is cleared before cpu_load_pmap() is called to switch
to a new pmap, leaving a window where a pmap is still in a CPU's
ci_kpm_pdir but not in pm_cpus. As a virtual CPU may be preempted
by the hypervisor at any time, it can be large enough to let another
CPU free the PTP and reuse it as a normal page.
To fix 2), avoid cross-calls and IPIs completely, and instead
use a mutex to update all CPU's ci_kpm_pdir from the local CPU.
It's safe because we just need to update the table page, a tlbflush IPI will
happen later. As a side effect, we don't need a different code for bootstrap,
fixing 1). The mutex added to struct cpu needs a small headers reorganisation.
to fix 3), introduce a pm_xen_ptp_cpus which is updated from
cpu_pmap_load(), whith the ci_kpm_mtx mutex held. Checking it with
ci_kpm_mtx held will avoid overwriting the wrong pmap's ci_kpm_pdir.
While there I removed the unused pmap_is_active() function;
and added some more details to DIAGNOSTIC panics.
When using uvm_km_pgremove_intrsafe() make sure mappings are removed
before returning the pages to the free pool. Otherwise, under Xen,
a page which still has a writable mapping could be allocated for
a PDP by another CPU and the hypervisor would refuse it (this is
PR port-xen/45975).
For this, move the pmap_kremove() calls inside uvm_km_pgremove_intrsafe(),
and do pmap_kremove()/uvm_pagefree() in batch of (at most) 16 entries
(as suggested by Chuck Silvers on tech-kern@, see also
http://mail-index.netbsd.org/tech-kern/2012/02/17/msg012727.html and
followups).
Avoid early use of xen_kpm_sync(); locks are not available at this time.
Don't call cpu_init() twice.
Makes LOCKDEBUG kernels boot again
Revert pmap_pte_flush() -> xpq_flush_queue() in previous.
|
| 1.10.2.3 |
| 03-Dec-2017 |
jdolecek | update from HEAD
|
| 1.10.2.2 |
| 20-Aug-2014 |
tls | Rebase to HEAD as of a few days ago.
|
| 1.10.2.1 |
| 25-Feb-2013 |
tls | resync with head
|
| 1.11.2.1 |
| 18-May-2014 |
rmind | sync with head
|
| 1.17.2.1 |
| 10-Aug-2014 |
tls | Rebase.
|
| 1.18.4.2 |
| 28-Aug-2017 |
skrll | Sync with HEAD
|
| 1.18.4.1 |
| 06-Apr-2015 |
skrll | Sync with HEAD
|
| 1.18.2.1 |
| 08-Feb-2015 |
snj | Pull up following revision(s) (requested by joerg in ticket #498):
sys/arch/xen/x86/xen_ipi.c: revision 1.19
valid_ipimask is only used under DIAGNOSTIC, so only define it then.
|
| 1.20.10.1 |
| 30-Apr-2021 |
martin | Pull up following revision(s) (requested by kre in ticket #1675):
sys/arch/xen/x86/xen_ipi.c: revision 1.24 (patch)
make compile without DDB
PR port-xen/50282
|
| 1.23.2.4 |
| 26-Dec-2018 |
pgoyette | Sync with HEAD, resolve a few conflicts
|
| 1.23.2.3 |
| 26-Nov-2018 |
pgoyette | Sync with HEAD, resolve a couple of conflicts
|
| 1.23.2.2 |
| 28-Jul-2018 |
pgoyette | Sync with HEAD
|
| 1.23.2.1 |
| 25-Jun-2018 |
pgoyette | Sync with HEAD
|
| 1.25.2.4 |
| 21-Apr-2020 |
martin | Sync with HEAD
|
| 1.25.2.3 |
| 13-Apr-2020 |
martin | Mostly merge changes from HEAD upto 20200411
|
| 1.25.2.2 |
| 08-Apr-2020 |
martin | Merge changes from current as of 20200406
|
| 1.25.2.1 |
| 10-Jun-2019 |
christos | Sync with HEAD
|
| 1.32.4.1 |
| 10-Aug-2023 |
sborrill | Pull up the following revisions(s) (requested by riastradh in ticket #1713):
sys/arch/xen/x86/xen_ipi.c: revision 1.41 via patch
xen/x86: Fix 'mach cpu N' in ddb by passing the right pointer to a
struct intrframe to IPI handlers.
|
| 1.35.6.7 |
| 25-Apr-2020 |
bouyer | sync with bouyer-xenpvh-base2 (HEAD)
|
| 1.35.6.6 |
| 20-Apr-2020 |
bouyer | Misc fixes after merge
|
| 1.35.6.5 |
| 20-Apr-2020 |
bouyer | Sync with HEAD
|
| 1.35.6.4 |
| 18-Apr-2020 |
bouyer | Add PVHVM multiprocessor support:
We need the hypervisor to be set up before cpus attaches.
Move hypervisor setup to a new function xen_hvm_init(), called at the
beggining of mainbus_attach(). This function searches the cfdata[] array
to see if the hypervisor device is enabled (so you can disable PV
support with
disable hypervisor
from userconf).
For HVM, ci_cpuid doens't match the virtual CPU index needed by Xen.
Introduce ci_vcpuid to cpu_info. Introduce xen_hvm_init_cpu(), to be
called for each CPU in in its context, which initialize ci_vcpuid and
ci_vcpu, and setup the event callback.
Change Xen code to use ci_vcpuid.
Do not call lapic_calibrate_timer() for VM_GUEST_XENPVHVM, we will use
Xen timers.
Don't call lapic_initclocks() from cpu_hatch(); instead set
x86_cpu_initclock_func to lapic_initclocks() in lapic_calibrate_timer(),
and call *(x86_cpu_initclock_func)() from cpu_hatch().
Also call x86_cpu_initclock_func from cpu_attach() for the boot CPU.
As x86_cpu_initclock_func is called for all CPUs, x86_initclock_func can
be a NOP for lapic timer.
Reorganize Xen code for x86_initclock_func/x86_cpu_initclock_func.
Move x86_cpu_idle_xen() to hypervisor_machdep.c
|
| 1.35.6.3 |
| 16-Apr-2020 |
bouyer | Reorganise sources to make it possible to include Xen PVHVM support in
native kernels. Among others:
- move xen/include/amd64/hypercall.h to amd64/include/xen and
xen/include/i386/hypercall.h to i386/include/xen
- exclude some native files from the build for xenpv
- add xen to "machine" config statement for amd64 and i386
- split arch/xen/conf/files.xen to arch/xen/conf/files.xen (for pv drivers)
and arch/xen/conf/files.xen.pv (for full pv support)
- add GENERIC_XENHVM kernel config which includes GENERIC and add Xen PV
drivers.
|
| 1.35.6.2 |
| 12-Apr-2020 |
bouyer | Add XEN_IPI_KPREEMPT to list of valid IPIs
|
| 1.35.6.1 |
| 11-Apr-2020 |
bouyer | Move softint and preemtion-related functions out of x86/x86/intr.c to
its own file, x86/x86/x86_softintr.c
Add x86/x86/x86_softintr.c for native and XenPV
Make sure XenPV also check ci_ioending, which is used for softints.
Switch XenPV to fast softints and allow kernel preemption.
kpreempt_disable() before calling pmap_changeprot_local()
run xen_wallclock_time() and xen_global_systime_ns() at splshed() to
avoid being interrupted.
XXX amd64 lock stubs are racy for XPENDING
|
| 1.40.4.2 |
| 14-Dec-2023 |
martin | Pull up following revision(s) (requested by rin in ticket #494):
sys/arch/xen/x86/xen_ipi.c: revision 1.42
sys/dev/nvmm/x86/nvmm_x86_vmx.c: revision 1.86
xen_ipi: valid_ipimask: Sprinkle __diagused to fix clang !DIAGNOSTIC build
nvmm_x86_vmx: vmx_vmptrst: Sprinkle __diagused to fix clang !DIAGNOSTIC build
|
| 1.40.4.1 |
| 10-Aug-2023 |
sborrill | Pull up the following revisions(s) (requested by riastradh in ticket #318):
sys/arch/xen/x86/xen_ipi.c: revision 1.41
xen/x86: Fix 'mach cpu N' in ddb by passing the right pointer to a
struct intrframe to IPI handlers.
|
