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
