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
