Michael Ellerman <m...@ellerman.id.au> writes: > "Nicholas Piggin" <npig...@gmail.com> writes: >> On Wed Jun 14, 2023 at 3:56 PM AEST, Michael Ellerman wrote: >>> Michael Ellerman <m...@ellerman.id.au> writes: >>> > Nicholas Piggin <npig...@gmail.com> writes: >>> >> The most expensive ordering for hwsync to provide is the store-load >>> >> barrier, because all prior stores have to be drained to the caches >>> >> before subsequent instructions can complete. >>> >> >>> >> stsync just orders stores which means it can just be a barrer that >>> >> goes down the store queue and orders draining, and does not prevent >>> >> completion of subsequent instructions. So it should be faster than >>> >> hwsync. >>> >> >>> >> Use stsync for wmb(). Older processors that don't recognise the SC >>> >> field should treat this as hwsync. >>> > >>> > qemu (7.1) emulating ppc64e does not :/ >>> > >>> > mpic: Setting up MPIC " OpenPIC " version 1.2 at fe0040000, max 1 CPUs >>> > mpic: ISU size: 256, shift: 8, mask: ff >>> > mpic: Initializing for 256 sources >>> > Oops: Exception in kernel mode, sig: 4 [#1] >>> .. >>> > >>> > I guess just put it behind an #ifdef 64S. >>> >>> That doesn't work because qemu emulating a G5 also doesn't accept it. >>> >>> So either we need to get qemu updated and wait a while for that to >>> percolate, or do some runtime patching of wmbs in the kernel >_< >> >> Gah, sorry. QEMU really should be ignoring reserved fields in >> instructions :( > > Yeah, it's an annoying discrepancy vs real hardware and the ISA. > >> I guess leave it out for now. Should fix QEMU but we probably also need >> to do patching so as not to break older QEMUs. > > I'll plan to take the first 3 patches, they seem OK as-is.
I didn't do that in the end, because patch 2 suffers from the same problem of not working on QEMU. cheers