The NetBSD Project

CVS log for src/sys/arch/xen/include/xenring.h

[BACK] Up to [cvs.NetBSD.org] / src / sys / arch / xen / include

Request diff between arbitrary revisions


Keyword substitution: kv
Default branch: MAIN


Revision 1.6.20.2: download - view: text, markup, annotated - select for diffs
Sat Jul 20 16:11:26 2024 UTC (6 months, 3 weeks ago) by martin
Branches: netbsd-10
CVS tags: netbsd-10-1-RELEASE
Diff to: previous 1.6.20.1: preferred, colored; branchpoint 1.6: preferred, colored; next MAIN 1.7: preferred, colored
Changes since revision 1.6.20.1: +2 -2 lines
Pull up following revision(s) (requested by riastradh in ticket #764):

	common/lib/libc/arch/i386/atomic/atomic.S: revision 1.37
	sys/arch/xen/include/xenring.h: revision 1.8
	sys/arch/i386/i386/cpufunc.S: revision 1.52
	sys/arch/amd64/amd64/cpufunc.S: revision 1.68
	sys/arch/xen/include/hypervisor.h: revision 1.60
	common/lib/libc/arch/x86_64/atomic/atomic.S: revision 1.30

xen: Don't hotpatch away LOCK prefix in xen_mb, even on UP boots.

Both xen_mb and membar_sync are designed to provide store-before-load
ordering, but xen_mb has to provide it in synchronizing guest with
hypervisor, while membar_sync only has to provide it in synchronizing
one (guest) CPU with another (guest) CPU.

It is safe to hotpatch away the LOCK prefix in membar_sync on a
uniprocessor boot because membar_sync is only designed to coordinate
between normal memory on multiple CPUs, and is never necessary when
there's only one CPU involved.

But xen_mb is used to coordinate between the guest and the `device'
implemented by a hypervisor, which might be running on another
_physical_ CPU even if the NetBSD guest only sees one `CPU', i.e.,
one _virtual_ CPU.  So even on `uniprocessor' boots, xen_mb must
still issue an instruction with store-before-load ordering on
multiprocessor systems, such as a LOCK ADD (or MFENCE, but MFENCE is
costlier for no benefit here).

No need to change xen_wmb (release ordering, load/store-before-store)
or xen_rmb (acquire ordering, load-before-load/store) because every
x86 store is a store-release and every x86 load is a load-acquire,
even on multiprocessor systems, so there's no hotpatching involved
anyway.

PR kern/57199

Revision 1.8: download - view: text, markup, annotated - select for diffs
Tue Jul 16 22:44:38 2024 UTC (6 months, 3 weeks ago) by riastradh
Branches: MAIN
CVS tags: HEAD
Diff to: previous 1.7: preferred, colored
Changes since revision 1.7: +2 -2 lines
xen: Don't hotpatch away LOCK prefix in xen_mb, even on UP boots.

Both xen_mb and membar_sync are designed to provide store-before-load
ordering, but xen_mb has to provide it in synchronizing guest with
hypervisor, while membar_sync only has to provide it in synchronizing
one (guest) CPU with another (guest) CPU.

It is safe to hotpatch away the LOCK prefix in membar_sync on a
uniprocessor boot because membar_sync is only designed to coordinate
between normal memory on multiple CPUs, and is never necessary when
there's only one CPU involved.

But xen_mb is used to coordinate between the guest and the `device'
implemented by a hypervisor, which might be running on another
_physical_ CPU even if the NetBSD guest only sees one `CPU', i.e.,
one _virtual_ CPU.  So even on `uniprocessor' boots, xen_mb must
still issue an instruction with store-before-load ordering on
multiprocessor systems, such as a LOCK ADD (or MFENCE, but MFENCE is
costlier for no benefit here).

No need to change xen_wmb (release ordering, load/store-before-store)
or xen_rmb (acquire ordering, load-before-load/store) because every
x86 store is a store-release and every x86 load is a load-acquire,
even on multiprocessor systems, so there's no hotpatching involved
anyway.

PR kern/57199

Revision 1.6.20.1: download - view: text, markup, annotated - select for diffs
Mon Jul 31 15:23:02 2023 UTC (18 months, 2 weeks ago) by martin
Branches: netbsd-10
CVS tags: netbsd-10-0-RELEASE, netbsd-10-0-RC6, netbsd-10-0-RC5, netbsd-10-0-RC4, netbsd-10-0-RC3, netbsd-10-0-RC2, netbsd-10-0-RC1
Diff to: previous 1.6: preferred, colored
Changes since revision 1.6: +3 -3 lines
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.

Revision 1.7: download - view: text, markup, annotated - select for diffs
Sat Feb 25 00:32:26 2023 UTC (23 months, 2 weeks ago) by riastradh
Branches: MAIN
CVS tags: thorpej-ifq-base, thorpej-ifq, thorpej-altq-separation-base, thorpej-altq-separation, perseant-exfatfs-base-20240630, perseant-exfatfs-base, perseant-exfatfs
Diff to: previous 1.6: preferred, colored
Changes since revision 1.6: +3 -3 lines
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

Revision 1.6: download - view: text, markup, annotated - select for diffs
Sat Apr 25 15:26:17 2020 UTC (4 years, 9 months ago) by bouyer
Branches: MAIN
CVS tags: thorpej-i2c-spi-conf2-base, thorpej-i2c-spi-conf2, thorpej-i2c-spi-conf-base, thorpej-i2c-spi-conf, thorpej-futex2-base, thorpej-futex2, thorpej-futex-base, thorpej-futex, thorpej-cfargs2-base, thorpej-cfargs2, thorpej-cfargs-base, thorpej-cfargs, netbsd-10-base, cjep_sun2x-base1, cjep_sun2x-base, cjep_sun2x, cjep_staticlib_x-base1, cjep_staticlib_x-base, cjep_staticlib_x, bouyer-sunxi-drm-base, bouyer-sunxi-drm
Branch point for: netbsd-10
Diff to: previous 1.5: preferred, colored
Changes since revision 1.5: +1 -1 lines
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

Revision 1.4.12.1: download - view: text, markup, annotated - select for diffs
Sat Apr 25 11:23:57 2020 UTC (4 years, 9 months ago) by bouyer
Branches: bouyer-xenpvh
Diff to: previous 1.4: preferred, colored; next MAIN 1.5: preferred, colored
Changes since revision 1.4: +33 -1 lines
Sync with bouyer-xenpvh-base2 (HEAD)

Revision 1.4.4.3: download - view: text, markup, annotated - select for diffs
Tue Apr 21 18:42:13 2020 UTC (4 years, 9 months ago) by martin
Branches: phil-wifi
Diff to: previous 1.4.4.2: preferred, colored; branchpoint 1.4: preferred, colored; next MAIN 1.5: preferred, colored
Changes since revision 1.4.4.2: +33 -1 lines
Sync with HEAD

Revision 1.5: download - view: text, markup, annotated - select for diffs
Tue Apr 21 14:51:06 2020 UTC (4 years, 9 months ago) by jdolecek
Branches: MAIN
CVS tags: phil-wifi-20200421, bouyer-xenpvh-base2
Diff to: previous 1.4: preferred, colored
Changes since revision 1.4: +33 -1 lines
add blkif_x86_{32,64}_request_indirect types

Revision 1.4.4.2: download - view: text, markup, annotated - select for diffs
Mon Jun 10 22:06:54 2019 UTC (5 years, 8 months ago) by christos
Branches: phil-wifi
Diff to: previous 1.4.4.1: preferred, colored; branchpoint 1.4: preferred, colored
Changes since revision 1.4.4.1: +85 -0 lines
Sync with HEAD

Revision 1.4.4.1
Sun Apr 7 12:23:54 2019 UTC (5 years, 10 months ago) by christos
Branches: phil-wifi
FILE REMOVED
Changes since revision 1.4: +0 -85 lines
file xenring.h was added on branch phil-wifi on 2019-06-10 22:06:54 +0000

Revision 1.4: download - view: text, markup, annotated - select for diffs
Sun Apr 7 12:23:54 2019 UTC (5 years, 10 months ago) by bouyer
Branches: MAIN
CVS tags: phil-wifi-20200411, phil-wifi-20200406, phil-wifi-20191119, phil-wifi-20190609, netbsd-9-base, netbsd-9-4-RELEASE, netbsd-9-3-RELEASE, netbsd-9-2-RELEASE, netbsd-9-1-RELEASE, netbsd-9-0-RELEASE, netbsd-9-0-RC2, netbsd-9-0-RC1, netbsd-9, isaki-audio2-base, isaki-audio2, is-mlppp-base, is-mlppp, bouyer-xenpvh-base1, bouyer-xenpvh-base, ad-namecache-base3, ad-namecache-base2, ad-namecache-base1, ad-namecache-base, ad-namecache
Branch point for: phil-wifi, bouyer-xenpvh
Diff to: previous 1.3: preferred, colored
Changes since revision 1.3: +39 -7 lines
blkif_x86_{32,64}_* are not identical to blkif_*, internal fields have
different alignements and this change their sizes. Copy them back from
their netbsd-8 definitions.
Fixes PR port-xen/54099

Revision 1.3: download - view: text, markup, annotated - select for diffs
Sat Feb 2 15:09:32 2019 UTC (6 years ago) by cherry
Branches: MAIN
Diff to: previous 1.2: preferred, colored
Changes since revision 1.2: +2 -2 lines
Fix build. A multiline macro needs 'line continuation'.

Revision 1.2: download - view: text, markup, annotated - select for diffs
Sat Feb 2 14:50:15 2019 UTC (6 years ago) by cherry
Branches: MAIN
Diff to: previous 1.1: preferred, colored
Changes since revision 1.1: +22 -3 lines
Remove mb(), rmb() and wmb() from the kernel namespace.

These are introduced by external/bsd/common/include/asm/barrier.h

The purpose of barrier.h is to bridge the use of linux API calls
within code which uses them, such as drm code. The XEN api implicitly
uses these calls which are linuxisms within io/ring.h

This diff undos the damage.

The correct fix is to modify io/ring.h to not assume that all OSs that
XEN runs on has these functions, and to appropriately conditionally via
#ifdef __NetBSD__/#endif use the appropriate NetBSD functions. These
changes then need to be pushed upstream.

Revision 1.1: download - view: text, markup, annotated - select for diffs
Sat Feb 2 12:32:55 2019 UTC (6 years ago) by cherry
Branches: MAIN
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/

Diff request

This form allows you to request diffs between any two revisions of a file. You may select a symbolic revision name using the selection box or you may type in a numeric name using the type-in text box.

Log view options

CVSweb <webmaster@jp.NetBSD.org>