Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 3 Jan 2024 11:16:24 -0800
From:      John Baldwin <jhb@FreeBSD.org>
To:        Vladimir Kondratyev <vladimir@kondratyev.su>
Cc:        Vladimir Kondratyev <wulf@freebsd.org>, src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org, owner-src-committers@freebsd.org
Subject:   Re: git: b4efc6277634 - main - LinuxKPI: Do not use explicit context in FPU sections on powerpc64
Message-ID:  <9aa04ad6-1948-48f7-be1b-e87e9806349d@FreeBSD.org>
In-Reply-To: <ee82e2b10ad8679ac43ba3be2e651095@kondratyev.su>
References:  <202312241320.3BODK2DA076069@gitrepo.freebsd.org> <e2cbddfc-0646-41b7-a8c3-d25ea60dda66@FreeBSD.org> <d00e79fb-29de-4bb3-a5e4-6b79e03191e1@kondratyev.su> <886e1a57-2e2e-4869-ae8d-0427ef771d41@FreeBSD.org> <ee82e2b10ad8679ac43ba3be2e651095@kondratyev.su>

next in thread | previous in thread | raw e-mail | index | archive | help
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 <wulf@FreeBSD.org>
>>>>> AuthorDate: 2023-12-24 12:48:06 +0000
>>>>> Commit:     Vladimir Kondratyev <wulf@FreeBSD.org>
>>>>> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9aa04ad6-1948-48f7-be1b-e87e9806349d>