Hello Fontenot, I hope this email finds you well. Thank you very much for this patch. We've encountered the same issue in our product, and your patch works. We do hope this issue will be resolved in the upstream kernel soon. On 28/01/2025 02:46, Fontenot, Nathan wrote: >>>>>> 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. I noticed your earlier discussions about designing a new approach to solve this problem, which I'm pretty excited about. Do you have any idea when you might post the updated version? We'd love to help out with reviewing and testing.. If you run into any roadblocks and need a hand, just let us know. we'd be delighted to help. As far as I know, this issue usually arises on Real CXL machines, but for ease of testing and validation, we modified QEMU to simulate the intersection of 'Soft Reserved' and the CXL region, which would aid in verification. Thanks Zhijian
