[PATCH v3] powerpc/pseries/vas: Use usleep_range() to support HCALL delay
VAS allocate, modify and deallocate HCALLs returns
H_LONG_BUSY_ORDER_1_MSEC or H_LONG_BUSY_ORDER_10_MSEC for busy
delay and expects OS to reissue HCALL after that delay. But using
msleep() will often sleep at least 20 msecs even though the
hypervisor suggests OS reissue these HCALLs after 1 or 10msecs.
The open and close VAS window functions hold mutex and then issue
these HCALLs. So these operations can take longer than the
necessary when multiple threads issue open or close window APIs
simultaneously.
So instead of msleep(), use usleep_range() to ensure sleep with
the expected value before issuing HCALL again.
Signed-off-by: Haren Myneni
Suggested-by: Nathan Lynch
---
v1 -> v2:
- Use usleep_range instead of using RTAS sleep routine as
suggested by Nathan
v2 -> v3:
- Sleep 10MSecs even for HCALL delay > 10MSecs and the other
commit / comemnt changes as suggested by Nathan and Ellerman.
---
arch/powerpc/platforms/pseries/vas.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/vas.c
b/arch/powerpc/platforms/pseries/vas.c
index 71d52a670d95..5cf81c564d4b 100644
--- a/arch/powerpc/platforms/pseries/vas.c
+++ b/arch/powerpc/platforms/pseries/vas.c
@@ -38,7 +38,30 @@ static long hcall_return_busy_check(long rc)
{
/* Check if we are stalled for some time */
if (H_IS_LONG_BUSY(rc)) {
- msleep(get_longbusy_msecs(rc));
+ unsigned int ms;
+ /*
+* Allocate, Modify and Deallocate HCALLs returns
+* H_LONG_BUSY_ORDER_1_MSEC or H_LONG_BUSY_ORDER_10_MSEC
+* for the long delay. So the sleep time should always
+* be either 1 or 10msecs, but in case if the HCALL
+* returns the long delay > 10 msecs, clamp the sleep
+* time to 10msecs.
+*/
+ ms = clamp(get_longbusy_msecs(rc), 1, 10);
+
+ /*
+* msleep() will often sleep at least 20 msecs even
+* though the hypervisor suggests that the OS reissue
+* HCALLs after 1 or 10msecs. Also the delay hint from
+* the HCALL is just a suggestion. So OK to pause for
+* less time than the hinted delay. Use usleep_range()
+* to ensure we don't sleep much longer than actually
+* needed.
+*
+* See Documentation/timers/timers-howto.rst for
+* explanation of the range used here.
+*/
+ usleep_range(ms * 100, ms * 1000);
rc = H_BUSY;
} else if (rc == H_BUSY) {
cond_resched();
--
2.26.3
Re: [GIT PULL] Please pull powerpc/linux.git powerpc-6.7-3 tag
The pull request you sent on Sun, 03 Dec 2023 10:12:23 +1100: > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git > tags/powerpc-6.7-3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/1b8af6552cb7c9bf1194e871f8d733a19b113230 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
[GIT PULL] Please pull powerpc/linux.git powerpc-6.7-3 tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Linus, Please pull some powerpc fixes for 6.7: The following changes since commit 98b1cc82c4affc16f5598d4fa14b1858671b2263: Linux 6.7-rc2 (2023-11-19 15:02:14 -0800) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-6.7-3 for you to fetch changes up to dc158d23b33df9033bcc8e7117e8591dd2f9d125: KVM: PPC: Book3S HV: Fix KVM_RUN clobbering FP/VEC user registers (2023-11-29 22:24:21 +1100) - -- powerpc fixes for 6.7 #3 - Fix corruption of f0/vs0 during FP/Vector save, seen as userspace crashes when using io-uring workers (in particular with MariaDB). - Fix KVM_RUN potentially clobbering all host userspace FP/Vector registers. Thanks to: Timothy Pearson, Jens Axboe, Nicholas Piggin. - -- Nicholas Piggin (1): KVM: PPC: Book3S HV: Fix KVM_RUN clobbering FP/VEC user registers Timothy Pearson (1): powerpc: Don't clobber f0/vs0 during fp|altivec register save arch/powerpc/kernel/fpu.S | 13 + arch/powerpc/kernel/process.c | 6 +++--- arch/powerpc/kernel/vector.S | 2 ++ 3 files changed, 18 insertions(+), 3 deletions(-) -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAmVruPoACgkQUevqPMjh pYBdlg//cW9CHahWFix93X5k3b+5LluRynR63BN4FnY+qVni95ihTxRC56rRpmUE JfbgADz3fFgPdX4/XXnpkrMY7rDyrwTelNT1X5Dl6nwounrqBRvCvplfHrlAPZqR C12ZBgbdJJmLucAtZv0mXsJ1NMiay9QZK7qIS7xJ22F7nEmnb5/BWs908hH6IwP0 pPOoi0AwiLqtsi6caIXr4GV1qoUbhfNOihZdXObCKetaOpEdcHUfu/vcNOhsVfgS f8NbyOKZ+dLasCB5ifa5gVw7MQfj++ljLive5C2t51Y1v2I1C3KRhQdoZmTFvWZD CXxRdCVfgrG5KWGXflG43pypYhmPcJSplDrP2Rg7EGFdasgl7Duc5VGh1l40p84k Via0iNCJBzL+j6heq47a4TA+oJRAK1HtPjd+ZrP4Rx3sxlIR9IiKAO3i2s8i3Djh nbK+BAxDBRlmE1+xOeplOsW5ZfjUVjv+mXHycGIGU//RGD8xOaX90USu1uBq2xbQ UKEpAMwrgpuZpCj/+nWaaEj/SuorkfyZeSoIce3l70LpBZTEJFT5cNNexFW63q2p QWcnnOxm3flS9tU+GOd/lFjAfV4AJSRKiagUk3JrIjGezl4HyXj6NXulZIIKvgVD zzDTDEL4trP/Eh8x9JEAKs0qmoMHoqe0hBCsnKS9qSoBoUZQvkI= =d6c4 -END PGP SIGNATURE-
Re: [PATCH v2] powerpc: Don't clobber fr0/vs0 during fp|altivec register save
On Sun, 19 Nov 2023 09:18:02 -0600, Timothy Pearson wrote: > During floating point and vector save to thread data fr0/vs0 are clobbered > by the FPSCR/VSCR store routine. > > [...] Applied to powerpc/fixes. [1/1] powerpc: Don't clobber fr0/vs0 during fp|altivec register save https://git.kernel.org/powerpc/c/5e1d824f9a283cbf90f25241b66d1f69adb3835b cheers
Re: [PATCH] KVM: PPC: Book3S HV: Fix KVM_RUN clobbering FP/VEC user registers
On Wed, 22 Nov 2023 12:58:11 +1000, Nicholas Piggin wrote: > Before running a guest, the host process (e.g., QEMU) FP/VEC registers > are saved if they were being used, similarly to when the kernel uses FP > registers. The guest values are then be loaded into regs, and the host > process registers will be restored lazily when it uses FP/VEC. > > KVM HV has a bug here: the host process registers do get saved, but the > user MSR bits remain enabled, which indicates the registers are valid > for the process. After they are clobbered by running the guest, this > valid indication causes the host process to take on the FP/VEC regiter > values of the guest. > > [...] Applied to powerpc/fixes. [1/1] KVM: PPC: Book3S HV: Fix KVM_RUN clobbering FP/VEC user registers https://git.kernel.org/powerpc/c/dc158d23b33df9033bcc8e7117e8591dd2f9d125 cheers
