From nobody Wed Jan 03 19:16:24 2024 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T4zwW4JC6z56WFF; Wed, 3 Jan 2024 19:16:27 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T4zwW3dTpz4DQm; Wed, 3 Jan 2024 19:16:27 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704309387; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VeBfE+1DcJHIJAeEVIncJptgosbiY9JGdjeMPuuurLI=; b=IhOtTTGHQlMCU0uF4nGsZI7XinuZ/SMvEzsmUd9b9VOKE9ouDkj1Hrk7xvsUyNf39OqlTu yfbTUK1ODQoVl1ENufmWPDIZj2a0d8Q3cdYR3OmLxUVwlzvSjKHAhDAHTb/DRiBV9GfNbx KCXO4EWzhNfK7Ohkr0AkU6jgTxCJVjfy9yRMuyguxo36j90e2JuIuvTGXXsbKkfoy6d4nb EUSA3QKIDgwgEcW7o4loJ2C+LqJx4fNypTuHDJmWCeClk+MLSBzUHqrbW7uZn/825ZW+pE TDg32Dl/CappyVtCPKnQePSIaFrayJeKTzM1kKvYj+X3UduvL4ZOzWt9k5ZIHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704309387; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VeBfE+1DcJHIJAeEVIncJptgosbiY9JGdjeMPuuurLI=; b=vGOx3QNN2OyvMBu9nDsr8C/jkmIDszliVTZa/dpGLI0iJREtgnaDBKR/bmoOKT8m7WtMiH xkMcsVjBqlONzMl3V/9PMf/XQ9ZQiUdzcEqh/ro6B8WTVM8bhXgFt6OWGvCtb0yXTq7fpj gMFq37oAZOuEKJUUkEh2mMAf03bJgso5W2CB8CYh7BdiIJJ4p2DqBkMOB7WZ3/TnCYr1/h Pjynp6fVP58uh8XBT3xUT2AZUhB17lvGqoys/Dxx4BhX2iMiaMJl3sle6b7UUYnY5/z62+ ynRJwp6FJQZZly6ff/F3Aznrw/TdrbO3fOfBEVkVWpE/oGYi/riSvAJgkpYyBg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1704309387; a=rsa-sha256; cv=none; b=L97NmkP2EGJXu+dxs1uasgxx86Id6DHkTQjG3bfVIBWJd+2wKPKXuB8UYsbEszIJESujwn LS7MFqT8WMUoY3jMwFfoi6ii9iEjCPy7Sw2RVvfYbsOKaOtLeX52waHjBz4dED01KRIbkq Jq5qqPn8eF428NqZt0uuT3SKWz64mGjHHyo/CB1ZFJbHa8LnPODaVpjOyhFE76Cnl0TOdx IJy1NE7V9TLNbo/4J9eLK4Di8oYnwdmBB5yeCGei+gEdMC18gPvCf3Lk7iA0zSEv1s8IDc J//jbdJ18kt840map8gf0MqxCeC6g07QXc+5LFsUsijNVE0hIww2pjpMbFEV3w== Received: from [IPV6:2601:644:9381:f410:71db:fcca:3a29:6836] (unknown [IPv6:2601:644:9381:f410:71db:fcca:3a29:6836]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4T4zwV0Qw3z168R; Wed, 3 Jan 2024 19:16:25 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <9aa04ad6-1948-48f7-be1b-e87e9806349d@FreeBSD.org> Date: Wed, 3 Jan 2024 11:16:24 -0800 List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: git: b4efc6277634 - main - LinuxKPI: Do not use explicit context in FPU sections on powerpc64 Content-Language: en-US To: Vladimir Kondratyev Cc: Vladimir Kondratyev , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org, owner-src-committers@freebsd.org References: <202312241320.3BODK2DA076069@gitrepo.freebsd.org> <886e1a57-2e2e-4869-ae8d-0427ef771d41@FreeBSD.org> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/3/24 5:52 AM, Vladimir Kondratyev wrote: > On 2024-01-02 22:17, John Baldwin wrote: >> On 12/30/23 7:14 PM, Vladimir Kondratyev wrote: >>> On 27.12.2023 20:05, John Baldwin wrote: >>>> On 12/24/23 5:20 AM, Vladimir Kondratyev wrote: >>>>> The branch main has been updated by wulf: >>>>> >>>>> URL: >>>>> https://cgit.FreeBSD.org/src/commit/?id=b4efc62776344a9aaada5a0866e453e528a0e977 >>>>> >>>>> commit b4efc62776344a9aaada5a0866e453e528a0e977 >>>>> Author:     Vladimir Kondratyev >>>>> AuthorDate: 2023-12-24 12:48:06 +0000 >>>>> Commit:     Vladimir Kondratyev >>>>> CommitDate: 2023-12-24 12:48:06 +0000 >>>>> >>>>>      LinuxKPI: Do not use explicit context in FPU sections on >>>>> powerpc64 >>>>>      It is not supported yet. >>>>>      Sponsored by:   Serenity Cyber Security, LLC >>>>>      Fixes:  5a3bd281672b ("LinuxKPI: Add explicit software context >>>>> to >>>>> FPU sections") >>>>>      MFC after:      1 week >>>>> --- >>>>>   sys/compat/linuxkpi/common/include/linux/compat.h | 5 ----- >>>>>   sys/compat/linuxkpi/common/src/linux_current.c    | 9 ++++++--- >>>>>   sys/compat/linuxkpi/common/src/linux_fpu.c        | 3 ++- >>>>>   3 files changed, 8 insertions(+), 9 deletions(-) >>>> >>>> Do you need explicit contexts at all? >>> >>> Original version of https://reviews.freebsd.org/D42822 did not use >>> explicit contexts. >>> >>>   That is, can you not just >>>> use FPU_KERN_NOCTX all the time?  Most code in the tree now uses >>>> FPU_KERN_NOCTX now (all the crypto drivers for example), and I've >>>> been thinking about removing support for the !FPU_KERN_NOCTX case. >>>> Is there a reason drm-kmod can't use FPU_KERN_NOCTX?  Do you really >>>> need to save FPU registers in one block of code wrapped by fpu_kern_* >>>> and then use those register values in a future section wrapped by >>>> fpu_kern_*? >>>> >>> >>> I can revert current code end use previous version. Just give me some >>> time. >>> I will be AFK till the end of january. >> >> Hmm, well the review for that answers my question which is that >> there is GPU driver code that calls malloc() while in an FPU >> section. So the answer to my original question is, no, you can't >> just use FPU_KERN_NOCTX. Or if you did you would need to patch >> the driver code instead to narrow the FPU context usage so it >> wasn't enabled when malloc() is called. I don't know how feasible >> it would be to fix the drivers to narrow the FPU sections, but I >> think you would have to do that if you wanted to go back to always >> using FPU_KERN_NOCTX. > > FPU_KERN_NOCTX is what LKPI uses for years for FPU sections. > > Original version of revision changes LKPI kmalloc() to automatically > detect > and than temporarily exit from FPU section for FreeBSD malloc() > execution. That is only safe if the calling code is not relying on the value of FPU registers to be preserved across the call to malloc(). Probably that is true, but you'd want to check the calling code carefully to ensure it is. OTOH, since FPU_KERN_NOCTX disables preemption, it is desirable to narrow the scope when possible. Perhaps the GPU driver is making a tradeoff of trying to amortize the cost of XRSTOR at the start of an FPU section by entering the section across multiple FPU-using sections. -- John Baldwin