CVS commit: [netbsd-10] src

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

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.