PR/57199 CVS commit: [netbsd-10] src

["Martin Husemann" <martin%netbsd.org@localhost>]

The following reply was made to PR kern/57199; it has been noted by GNATS.

From: "Martin Husemann" <martin%netbsd.org@localhost>
To: gnats-bugs%gnats.NetBSD.org@localhost
Cc: 
Subject: PR/57199 CVS commit: [netbsd-10] src
Date: Sat, 20 Jul 2024 16:11:27 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Sat Jul 20 16:11:27 UTC 2024
 
 Modified Files:
 	src/common/lib/libc/arch/i386/atomic [netbsd-10]: atomic.S
 	src/common/lib/libc/arch/x86_64/atomic [netbsd-10]: atomic.S
 	src/sys/arch/amd64/amd64 [netbsd-10]: cpufunc.S
 	src/sys/arch/i386/i386 [netbsd-10]: cpufunc.S
 	src/sys/arch/xen/include [netbsd-10]: hypervisor.h xenring.h
 
 Log Message:
 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
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.36 -r1.36.2.1 src/common/lib/libc/arch/i386/atomic/atomic.S
 cvs rdiff -u -r1.29 -r1.29.2.1 \
     src/common/lib/libc/arch/x86_64/atomic/atomic.S
 cvs rdiff -u -r1.65 -r1.65.18.1 src/sys/arch/amd64/amd64/cpufunc.S
 cvs rdiff -u -r1.49 -r1.49.20.1 src/sys/arch/i386/i386/cpufunc.S
 cvs rdiff -u -r1.55.4.3 -r1.55.4.4 src/sys/arch/xen/include/hypervisor.h
 cvs rdiff -u -r1.6.20.1 -r1.6.20.2 src/sys/arch/xen/include/xenring.h
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.