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: Taylor R Campbell <riastradh%NetBSD.org@localhost>
Cc: bouyer%antioche.eu.org@localhost, 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 14:31:41 -0400

 Taylor R Campbell <riastradh%NetBSD.org@localhost> writes:
 
 > [1:text/plain Hide]
 >
 >> Date: Mon, 15 Jul 2024 17:33:17 +0000
 >> From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
 >> 
 >> 2. This is a single-(v)CPU system which has patched out the lock
 >>    prefix in membar_sync.
 >> [...]
 >> 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.
 >
 > The attached patch implements this approach, and leaves extensive
 > comments explaining what's going on, without issuing any unnecessary
 > mfence/lfence/sfence instructions.  Can you try it out?
 >
 > Under my hypothesis, the domU kernel certainly needs this change.  And
 > the dom0 kernel may also need it, because I believe it uses
 > RING_PUSH_RESPONSES_AND_CHECK_NOTIFY and RING_FINAL_CHECK_FOR_REQUESTS
 > which rely on xen_mb too.
 
 
 a) Manuel's patch allowed the 32-bit PVH DOMU to do the untar without
 hanging.
 
 b) I will test Taylor's patch on the DOMU.  Doing that on the DOM0 is
 probably not something I can manage right now.
 
 
 -- 
 Brad Spencer - brad%anduin.eldar.org@localhost - KC8VKS - http://anduin.eldar.org