Re: port-xen/57199: Pure PVH i386 guests hang on disk activity

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

I can think of two ways this patch could have an impact:

1. Some Xen driver relies on write-combining memory (i.e.,
   `prefetchable' in PCIese and bus_dmaese), or on non-temporal
   stores.  This seems unlikely.

2. This is a single-(v)CPU system which has patched out the lock
   prefix in membar_sync.

Unless (1) is happening, I doubt there's any reason to need mfence,
lfence, or sfence -- except in the circumstances of (1), mfence is
just a more expensive version of a locked-add for store-before-load
ordering, and lfence and sfence are never necessary.  See, e.g., the
AMD memory access ordering rules table:

AMD64 Architecture Programmer's Manual, Volume 2: System Programming,
24593--Rev. 3.38--November 2021, Sec. 7.4.2 Memory Barrier Interaction
with Memory Types, Table 7-3, p. 196.
https://web.archive.org/web/20220625040004/https://www.amd.com/system/files/TechDocs/24593.pdf#page=256


Is this a single-(v)CPU system?  Can you enter crash(8) or drop into
ddb and disassemble the membar_sync function?  I bet you'll find no
lock prefix there, which would explain the hangs.

If my hypothesis about (2) is correct, the right thing is probably
either to make xen_mb be an assembly stub that does

	lock
	addq $0,-8(%rsp)

(without the membar_sync hotpatching), or to make xen_mb be inline asm
to do the same.