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

[David Hildenbrand <david@redhat.com>]

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.

-- 
Cheers,

David / dhildenb