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

[Brad Spencer <brad%anduin.eldar.org@localhost>]

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

From: Brad Spencer <brad%anduin.eldar.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: port-xen/57199: Pure PVH i386 guests hang on disk activity
Date: Mon, 15 Jul 2024 13:55:10 -0400

 Taylor R Campbell <riastradh%NetBSD.org@localhost> writes:
 
 > The following reply was made to PR kern/57199; it has been noted by GNATS.
 >
 > From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
 > To: Brad Spencer <brad%anduin.eldar.org@localhost>,
 > 	Manuel Bouyer <bouyer%antioche.eu.org@localhost>
 > Cc: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost, gdt%lexort.com@localhost
 > Subject: Re: port-xen/57199: Pure PVH i386 guests hang on disk activity
 > Date: Mon, 15 Jul 2024 17:33:17 +0000
 >
 >  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=3D256
 >  
 >  
 >  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.
 
 Yes, it is a single vcpu DOMU.  I can get into ddb without any problems
 but would need the commands to do the disassembly.
 
 Context reminder.. this is a 32 bit i386 DOMU running PVH mode that
 hangs up.  For reasons that are not clear to me, a i386 guest running
 PV+PVSHIM does not hang.  A 64 bit PVH DOMU does not hang.
 
 >  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.
 >  
 
 
 -- 
 Brad Spencer - brad%anduin.eldar.org@localhost - KC8VKS - http://anduin.eldar.org