| History log of /src/sys/arch/xen/xenbus/xenbus_comms.c |
| Revision | | Date | Author | Comments |
| 1.26 |
| 25-Feb-2023 |
riastradh | xenbus_comms.c: Nix trailing whitespace.
No functional change intended.
|
| 1.25 |
| 25-Feb-2023 |
riastradh | xenbus_comms.c: Membar audit.
This had the sense of membars reversed, presumably because xen_rmb
and xen_wmb had gotten reversed at some point.
|
| 1.24 |
| 13-May-2020 |
jdolecek | branches: 1.24.20;
don't reinitialize mutexes/cv on resume
part of PR port-xen/55207
|
| 1.23 |
| 06-May-2020 |
bouyer | Convert remaining splfoo/splx and tsleep/wakeup to mutex and condvar.
Mark kernel threads and interrupt handlers MPSAFE.
|
| 1.22 |
| 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.21 |
| 24-Dec-2018 |
cherry | branches: 1.21.10;
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.20 |
| 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.19 |
| 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.18 |
| 24-Jun-2018 |
jdolecek | branches: 1.18.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.17 |
| 13-Nov-2017 |
riastradh | branches: 1.17.2;
Missed a spot: preserve known_mpsafe = (level != IPL_VM).
Noted by kre -- sorry!
|
| 1.16 |
| 06-Nov-2017 |
cherry | Switch XEN drivers to use intr_establish_xname()/intr_disestablish()
This completes the API transition.
|
| 1.15 |
| 07-Jul-2016 |
msaitoh | KNF. Remove extra spaces. No functional change.
|
| 1.14 |
| 20-Sep-2011 |
jym | branches: 1.14.12; 1.14.30;
Merge jym-xensuspend branch in -current. ok bouyer@.
Goal: save/restore support in NetBSD domUs, for i386, i386 PAE and amd64.
Executive summary:
- split all Xen drivers (xenbus(4), grant tables, xbd(4), xennet(4))
in two parts: suspend and resume, and hook them to pmf(9).
- modify pmap so that Xen hypervisor does not cry out loud in case
it finds "unexpected" recursive memory mappings
- provide a sysctl(7), machdep.xen.suspend, to command suspend from
userland via powerd(8). Note: a suspend can only be handled correctly
when dom0 requested it, so provide a mechanism that will prevent
kernel to blindly validate user's commands
The code is still in experimental state, use at your own risk: restore
can corrupt backend communications rings; this can completely thrash
dom0 as it will loop at a high interrupt level trying to honor
all domU requests.
XXX PAE suspend does not work in amd64 currently, due to (yet again!)
page validation issues with hypervisor. Will fix.
XXX secondary CPUs are not suspended, I will write the handlers
in sync with cherry's Xen MP work.
Tested under i386 and amd64, bear in mind ring corruption though.
No build break expected, GENERICs and XEN* kernels should be fine.
./build.sh distribution still running. In any case: sorry if it does
break for you, contact me directly for reports.
|
| 1.13 |
| 02-Jul-2011 |
jym | Remove all return error checks for event_set_handler(...). It either
succeeds or end in panic.
|
| 1.12 |
| 16-Jan-2009 |
jym | branches: 1.12.2;
Replace x86 memory fences in Xen drivers by their Xen equivalents, to reduce
MD dependency:
x86_lfence() => xen_rmb()
x86_sfence() => xen_wmb()
x86_mfence() => xen_mb()
Discussed in
http://mail-index.netbsd.org/port-xen/2009/01/15/msg004655.html
Ok by bouyer@.
|
| 1.11 |
| 18-Dec-2008 |
cegger | remove unused malloc.h
|
| 1.10 |
| 29-Oct-2008 |
cegger | include <xen/xen.h> for xendomain_is_dom0()
|
| 1.9 |
| 24-Oct-2008 |
jym | branches: 1.9.2;
- printf -> aprint_*
- fix and add comments
- make some panic/error messages more relevant
- remove last '\n' in DPRINTK() macros, not required as it is already part of format string.
No functional changes.
|
| 1.8 |
| 21-Oct-2008 |
cegger | introduce two macros: xendomain_is_dom0() and xendomain_is_privileged(). Use them.
|
| 1.7 |
| 16-Apr-2008 |
cegger | branches: 1.7.4; 1.7.10;
device_t / softc split
reviewed, tested and approved by bouyer
|
| 1.6 |
| 06-Apr-2008 |
cegger | use aprint_*_dev and device_xname
|
| 1.5 |
| 22-Nov-2007 |
bouyer | branches: 1.5.14;
Pull up the bouyer-xenamd64 branch to HEAD. This brings in amd64 support
to NetBSD/Xen, both Dom0 and DomU.
|
| 1.4 |
| 04-Mar-2007 |
christos | branches: 1.4.2; 1.4.18; 1.4.20; 1.4.24; 1.4.26;
Kill caddr_t; there will be some MI fallout, but it will be fixed shortly.
|
| 1.3 |
| 23-May-2006 |
bouyer | branches: 1.3.4; 1.3.10; 1.3.16;
Add needed framework for backend drivers.
As we want some control on the name the backend driver will have we
can't use autoconf(9) here. Instead backend drivers registers to
xenbus, which will call a create callback when a new device is there.
Backend devices won't have a "struct device" in xenbus, use a void pointer
instead.
|
| 1.2 |
| 06-Mar-2006 |
bouyer | branches: 1.2.4; 1.2.6; 1.2.8; 1.2.10; 1.2.12;
Adapt for NetBSD and add glue for config(9). Enough to get guest domain
virtual devices probed and attached, domain0 and xenstore watch needs to
be done.
|
| 1.1 |
| 06-Mar-2006 |
bouyer | branches: 1.1.1;
Initial revision
|
| 1.1.1.1 |
| 06-Mar-2006 |
bouyer | Import xenbus sources, from linux sparse tree in the 20060107 xen-3.0
snapshot.
|
| 1.2.12.1 |
| 19-Jun-2006 |
chap | Sync with head.
|
| 1.2.10.3 |
| 01-Jun-2006 |
kardel | Sync with head.
|
| 1.2.10.2 |
| 22-Apr-2006 |
simonb | Sync with head.
|
| 1.2.10.1 |
| 06-Mar-2006 |
simonb | file xenbus_comms.c was added on branch simonb-timecounters on 2006-04-22 11:38:11 +0000
|
| 1.2.8.2 |
| 07-Apr-2006 |
tron | Apply patch (requested by bouyer in ticket #1245):
Pull up Xen3 domU support. This adds support for the Xen-3 memory bootstrap,
xenstore, and block and network device frontend. Xen-3 support is turned
on by 'options XEN3', which disable Xen-2 support.
Changes affecting non-xen3 specific code:
- xbd and xennet at hypervisor now attaches with xbd_hypervisor and
xennet_hypervisor
- x86_atomic_* renamed to xen_atomic_*
- use genassim.cf to pull in more constant from include files for assembly
- Map the shared info page from locore.S instead of the 0xffffffff hack
in xen_machdep.c
- remove some unused code
- some __asm__ __volatile__ -> __asm volatile and __inline__ -> inline
- more debug code
|
| 1.2.8.1 |
| 06-Mar-2006 |
tron | file xenbus_comms.c was added on branch netbsd-3 on 2006-04-07 12:51:26 +0000
|
| 1.2.6.1 |
| 24-May-2006 |
tron | Merge 2006-05-24 NetBSD-current into the "peter-altq" branch.
|
| 1.2.4.3 |
| 24-May-2006 |
yamt | sync with head.
|
| 1.2.4.2 |
| 13-Mar-2006 |
yamt | sync with head.
|
| 1.2.4.1 |
| 06-Mar-2006 |
yamt | file xenbus_comms.c was added on branch yamt-pdpolicy on 2006-03-13 09:07:07 +0000
|
| 1.3.16.1 |
| 12-Mar-2007 |
rmind | Sync with HEAD.
|
| 1.3.10.2 |
| 09-Sep-2006 |
rpaulo | sync with head
|
| 1.3.10.1 |
| 23-May-2006 |
rpaulo | file xenbus_comms.c was added on branch rpaulo-netinet-merge-pcb on 2006-09-09 02:45:06 +0000
|
| 1.3.4.4 |
| 07-Dec-2007 |
yamt | sync with head
|
| 1.3.4.3 |
| 03-Sep-2007 |
yamt | sync with head.
|
| 1.3.4.2 |
| 21-Jun-2006 |
yamt | sync with head.
|
| 1.3.4.1 |
| 23-May-2006 |
yamt | file xenbus_comms.c was added on branch yamt-lazymbuf on 2006-06-21 14:58:23 +0000
|
| 1.4.26.1 |
| 08-Dec-2007 |
mjf | Sync with HEAD.
|
| 1.4.24.1 |
| 17-Oct-2007 |
bouyer | Prepare for xenamd64:
- kill xen/i386/identcpu.c, use i386/i386/identcpu.c instead (with a few
#ifndef XEN)
- move some files that can be shared between i386 and amd64 from
xen/i386 to xen/x86 (or to xen/xen for non-cpu-specific code)
- split assembly out of xen/include/hypervisor.h to xen/include/hypercalls.h
- use <xen/...> instead of <machine/...> for cpu-independant include files.
more work needed here, i386-specific files should got out of arch/xen to
arch/xeni386, and more code shared with arch/i386.
|
| 1.4.20.1 |
| 09-Jan-2008 |
matt | sync with HEAD
|
| 1.4.18.1 |
| 27-Nov-2007 |
joerg | Sync with HEAD. amd64 Xen support needs testing.
|
| 1.4.2.1 |
| 03-Dec-2007 |
ad | Sync with HEAD.
|
| 1.5.14.2 |
| 17-Jan-2009 |
mjf | Sync with HEAD.
|
| 1.5.14.1 |
| 02-Jun-2008 |
mjf | Sync with HEAD.
|
| 1.7.10.1 |
| 13-Dec-2008 |
haad | Update haad-dm branch to haad-dm-base2.
|
| 1.7.4.1 |
| 04-May-2009 |
yamt | sync with head.
|
| 1.9.2.1 |
| 19-Jan-2009 |
skrll | Sync with HEAD.
|
| 1.12.2.5 |
| 27-Aug-2011 |
jym | Sync with HEAD. Most notably: uvm/pmap work done by rmind@, and MP Xen
work of cherry@.
No regression observed on suspend/restore.
|
| 1.12.2.4 |
| 25-Jul-2011 |
jym | Pull-up to my branch some of the improvements I committed to HEAD, but
forgot to reflect here.
Improvements in the attachement routines: in case of error, don't forget
to free() the allocated rings. Should not happen anyway, more a matter
of staying clean.
|
| 1.12.2.3 |
| 01-Nov-2009 |
jym | - Upgrade suspend/resume code to comply with Xen2 removal.
- Add support for PAE domUs suspend/resume.
- Fix an issue regarding initialization of the xbd ring I/O that could end
badly during resume, with invalid block operations submitted to dom0 backend.
NetBSD supports PAE under x86_32 by considering the L2 page as being
4 pages long instead of 1.
Xen validates the page types during resume. Sadly, the hypervisor handles
alternative recursive mappings (== PG/PD entries pointing to pages other
than self) inadequately, which could lead to incorrect page pinning.
As a result, the important change with this patch is to clear these alternative
mappings during suspend, and reset them back to their former self upon
resume. For PAE, approx. all 4 PDIR_SLOT_PTEs could be considered as
alternative recursive mappings.
See comments in pmap.c for further details.
Now, let the testing and bug hunting begin.
|
| 1.12.2.2 |
| 01-Nov-2009 |
jym | Sync with HEAD.
|
| 1.12.2.1 |
| 09-Feb-2009 |
jym | Initial code for xen save/restore/migrate facilities.
- split the attach code of frontends in two half: one that is only needed
during autoconf(9) attach/detach phases, and one used at each save/restore
of device state (between suspend and resume).
Applies to hypervisor, xencons, xenbus, xbd, and xennet.
- add a rwlock(9) ("ptom_lock") to protect the different parts in the kernel
that manipulate MFNs (which could change between a suspend and a resume,
without the kernel noticing it). Parts that require MFNs acquire a reader lock,
while suspend code will acquire a writer lock to ensure that no-other parts
in kernel still use MFNs.
- integrate the suspend code with sysmon.
- various things in pmap(9), and clock.
TODO:
- factorize code a bit more inside frontends drivers.
- remove all alternative recursive (APDP_PDE) mappings found in PD/PT during
suspend, as Xen does not support them.
- abstract the ptom_lock locking, it is only required when kernel preemption
is enabled, or on MP systems.
Current code works mostly. You may experience difficulties in some corner
cases (dom0 warnings about xennet interface errors, and Xen tools failing to
validate NetBSD's alternative pmaps).
|
| 1.14.30.1 |
| 09-Jul-2016 |
skrll | Sync with HEAD
|
| 1.14.12.1 |
| 03-Dec-2017 |
jdolecek | update from HEAD
|
| 1.17.2.3 |
| 26-Dec-2018 |
pgoyette | Sync with HEAD, resolve a few conflicts
|
| 1.17.2.2 |
| 26-Nov-2018 |
pgoyette | Sync with HEAD, resolve a couple of conflicts
|
| 1.17.2.1 |
| 25-Jun-2018 |
pgoyette | Sync with HEAD
|
| 1.18.2.1 |
| 10-Jun-2019 |
christos | Sync with HEAD
|
| 1.21.10.1 |
| 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.24.20.1 |
| 31-Jul-2023 |
martin | Pull up following revision(s) (requested by riastradh in ticket #268):
sys/arch/xen/xenbus/xenbus_comms.c: revision 1.25
sys/arch/xen/xenbus/xenbus_comms.c: revision 1.26
sys/arch/xen/xen/xennetback_xenbus.c: revision 1.110
sys/arch/xen/xen/xennetback_xenbus.c: revision 1.111
sys/arch/xen/xen/xennetback_xenbus.c: revision 1.112
sys/arch/xen/x86/cpu.c: revision 1.144
sys/arch/xen/x86/cpu.c: revision 1.145
sys/arch/xen/include/hypervisor.h: revision 1.56
sys/arch/xen/include/hypervisor.h: revision 1.57
sys/arch/xen/xen/xbdback_xenbus.c: revision 1.102
sys/arch/xen/xen/xbdback_xenbus.c: revision 1.103
sys/arch/xen/include/xenring.h: revision 1.7
sys/arch/xen/xen/xennetback_xenbus.c: revision 1.109
sys/arch/xen/xen/xengnt.c: revision 1.40
sys/arch/xen/xen/xengnt.c: revision 1.41
sys/arch/xen/xen/if_xennet_xenbus.c: revision 1.129
sys/arch/xen/xen/xencons.c: revision 1.51
sys/arch/xen/xen/xencons.c: revision 1.52
sys/arch/xen/xen/xencons.c: revision 1.53
sys/arch/xen/xen/xbd_xenbus.c: revision 1.130 (patch)
sys/arch/xen/xen/xbd_xenbus.c: revision 1.131 (patch)
xen: Fix sense of xen_rmb/wmb to make sense.
Use membar_acquire and membar_release, not membar_consumer and
membar_producer, out of paranoia -- that better matches Linux's
rmb/wmb (at least for non-I/O loads and stores).
Proposed on port-xen:
https://mail-index.netbsd.org/port-xen/2022/07/13/msg010248.html
xen/x86/cpu.c: Membar audit.
I see no reason for store-before-load ordering here; as far as I'm
aware, evtchn_upcall_mask is only shared between a (v)CPU and its
(hypervisor) interrupts, not other (v)CPUs.
xennet(4): Membar audit.
- xennet_tx_complete: Other side owns rsp_prod, giving us responses
to tx commands. We own rsp_cons, recording which responess we've
processed already.
1. Other side initializes responses before advancing rsp_prod, so
we must observe rsp_prod before trying to examine the responses.
Hence load from rsp_prod must be followed by xen_rmb.
(Can this just use atomic_load_acquire?)
2. As soon as other side observes rsp_event, it may start to
overwrite now-unused response slots, so we must finish using the
response before advancing rsp_cons. Hence we must issue xen_wmb
before store to rsp_event.
(Can this just use atomic_store_release?)
(Should this use RING_FINAL_CHECK_FOR_RESPONSES?)
3. When loop is done and we set rsp_event, we must ensure the other
side has had a chance to see that we want more before we check
whether there is more to consume; otherwise the other side might
not bother to send us an interrupt. Hence after setting
rsp_event, we must issue xen_mb (store-before-load) before
re-checking rsp_prod.
- xennet_handler (rx): Same deal, except the xen_mb is buried in
RING_FINAL_CHECK_FOR_RESPONSES. Unclear why xennet_tx_complete has
this open-coded while xennet_handler (rx) uses the macro.
xbd(4): Membar audit.
After consuming slots, must issue xen_wmb before notifying the other
side that we've consumed them in RING_FINAL_CHECK_FOR_RESPONSES.
xbdback(4): Membar audit.
After consuming request slots, must issue xen_wmb notifying the other
side that we've consumed them in RING_FINAL_CHECK_FOR_REQUESTS.
xencons(4): Membar audit.
- xenconscn_getc: Once we have consumed an input slot, it is clearer
to issue xen_wmb (release, i.e., load/store-before-store) before
advancing in_cons so that the update becomes a store-release
freeing the input slot for the other side to reuse.
- xenconscn_putc: After filling an output slot, must issue xen_wmb
(release, i.e., load/store-before-store) before advancing out_prod,
and another one before notifying the other side of the advance.
xencons(4): Reduce unnecessary membars.
- xencons_handler: After advancing in_cons, only need one xen_wmb
before notifying the hypervisor that we're ready for more.
(XXX Should this do xen_mb and re-check in_prod at that point, or
does hypervisor_notify_via_evtchn obviate the need for this?)
- xenvonscn_getc: After reading in_prod, only need one xen_rmb before
using the slots it is telling us are now ready.
xengnt(4): Membar audit.
This had the sense of membars reversed, presumably because xen_rmb
and xen_wmb had gotten reversed at some point.
xenbus_comms.c: Membar audit.
This had the sense of membars reversed, presumably because xen_rmb
and xen_wmb had gotten reversed at some point.
xennetback(4): Fix xennetback_evthandler loop.
- After observing the other side has produced pending tx requests by
reading sring->req_prod, must issue xen_rmb before touching them.
Despite all the effort to use the heavy-weight
RING_FINAL_CHECK_FOR_REQUESTS on each request in the loop, this
barrier was missing.
- No need to update req_cons at each iteration in the loop. It's
private. Just update it once at the end.
- After consuming requests, must issue xen_wmb before releasing the
slots with RING_FINAL_CHECK_FOR_REQUEST for the other side to
reuse.
xennetback(4): Fix membars in xennetback_rx_copy_process.
- No need for barrier around touching req_cons and rsp_prod_pvt,
which are private.
- RING_PUSH_RESPONSES_AND_CHECK_NOTIFY already issues xen_wmb, no
need to add one explicitly.
- After pushing responses, must issue xen_wmb (not xen_rmb) before
hypervisor_notify_via_evtchn.
xennetback(4): Omit needless membars in xennetback_connect.
xneti is a private data structure to which we have exclusive access
here; ordering the stores doesn't make sense.
xen/hypervisor.h: Nix trailing whitespace.
No functional change intended.
xen/x86/cpu.c: Nix trailing whitespace.
No functional change intended.
xbd(4): Nix trailing whitespace.
xbdback(4): Nix trailing whitespace.
No functional change intended.
xencons(4): Nix trailing whitespace.
No functional change intended.
xengnt(4): Nix trailing whitespace.
No functional change intended.
xenbus_comms.c: Nix trailing whitespace.
No functional change intended.
xennetback(4): Nix trailing whitespace.
No functional change intended.
|
