Re: [PATCH v2 1/4] kernel/resource: Introduce managed SOFT RESERVED resources

["Fontenot, Nathan" <nafonten@amd.com>]

On 1/27/2025 8:40 AM, David Hildenbrand wrote:
> On 23.01.25 16:49, Fontenot, Nathan wrote:
>> On 1/22/2025 12:03 AM, Fan Ni wrote:
>>> On Tue, Jan 21, 2025 at 12:57:19PM -0600, Fontenot, Nathan wrote:
>>>>
>>>>
>>>> On 1/21/2025 2:19 AM, David Hildenbrand wrote:
>>>>> On 16.01.25 18:42, Nathan Fontenot wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>>> Introduce the ability to manage SOFT RESERVED kernel resources prior to
>>>>>> these resources being  placed in the iomem resource tree. This provides
>>>>>> the ability for drivers to update SOFT RESERVED resources that intersect
>>>>>> with their memory resources.
>>>>>>
>>>>>> During boot, any resources marked as IORES_DESC_SOFT_RESERVED are placed
>>>>>> on the soft reserve resource tree. Once boot completes all resources
>>>>>> are placed on the iomem resource tree. This behavior is gated by a new
>>>>>> kernel option CONFIG_SOFT_RESERVED_MANAGED.
>>>>>>
>>>>>
>>>>> I'm missing a bit of context here.
>>>>>
>>>>> Why can't we flag these regions in the existing iomem tree, where they can be fixed up (even after boot?)?
>>>>>
>>>>> Especially, what about deferred driver loading after boot? Why is that not a concern or why can we reliably handle everything "during boot" ?
>>>>
>>>> That's a good question and one I should have addressed.
>>>>
> 
> Sorry for the late reply.
> 
>>>> The goal is to prevent the dax driver from creating dax devices for soft reserve
>>>> resources prior to the soft reserve resources being updated for any intersecting
>>>> cxl regions.
>>>
>>> Not an export. Can you explain a little more here?
>>> What is the problem if we only flag the resources as "soft
>>> reserved" in the iomem tree without creating a separate tree, and
>>> process the "soft reserved" resources only when needed?
>>
>> The issue we currently encounter is that the dax driver consumes these soft reserve
>> resources and creates dax devices for the soft reserve resources before the cxl driver
>> comnpletes device probe and can update the soft reserve resources to remove any
>> intersections with cxl regions. We do not want these soft reserves consumed prior
>> to them being updated.
>>
>> If we were to put the soft reserves on the iomem tree we would need to have the
>> cxl driver provide a notification that it has completed updates and others (i.e. dax)
>> can them go process the soft reserve resources.
> 
> Would there be any blocker to that approach?
> 
> Adding them all to the resource tree and flagging them as soft-reserved, to then have a signal that allows DAX to work on these, sounds cleaner to me.
> 

You're correct that this does sound cleaner. I've been thinking about how this could be done
and have started working on a version of the patch that takes this approach. If this works
I'll make it part of the next version of the patch set.

-Nathan