17:21 <sjg1> Tartarus: The point of co-operation (as I think we agreed to call it) is the end of any image loading via lmb, and the start of any memory allocation by EFI. This is the whole key to solving this problem without a complex set of bidirectional logic

17:22 <sjg1> Tartarus: Images are loaded via lmb, then EFI takes over and adds lmb to its memory map, then carries on as today

17:22 <Tartarus> sjg1: I had a thought about this last night that may make objections clearer. Why are you not making some similar flag for "bootelf" and "go" ?

17:23 <Tartarus> But, what do you mean images loaded via lmb?

17:23 <sjg1> Tartarus: I wouldn't worry so much but it is quite difficult to get any changes in with the EFI subsystem, so if we go ahead with this scheme, it will be very difficult to back out

17:23 <Tartarus> With Sughosh's v3, yes, everything loaded is covered by an lmb

17:23 <Tartarus> and, electrician msging me, brb'ish

17:25 <sjg1> The latest series doesn't have a flag actually. For bootelf and go, we don't have callbacks, so they cannot allocation memory, so lmb is the final word. It is only EFI where things are more complicated

17:26 <sjg1> I mean, images are loaded via lmb today, so we don't need to change that. It works fine

17:28 <Tartarus> Right, bootelf and go can fiddle whatever they want in memory and not bother setting an lmb over what they load since we won't know

17:28 <Tartarus> EFI is more complicated in that we do know what's going on and so... why does it need some special treatment? That's what's confusing

17:29 <Tartarus> The app we launch can say I need $this hunk of memory and we know about it, rather than not knowing about it

17:30 <sjg1> Yes

17:30 <sjg1> But all that is needed is for EFI to add the lmb records to its memory map. Everything else can stay the same, right?

17:33 <Tartarus> To be clear, before all of this rework, EFI only was doing LMB checks because I noticed it wasn't and wanted to avoid an easy-and-stupid CVE being assigned. Today there's gaps because Sughosh's initial series that did cover EFI was split in two, leaving the EFI part out to not block the rest of the rework going in. "Tomorrow" (not literally, I had a small comment for v3 and will fully review Monday) EFI will be fully integrated with

17:33 <Tartarus> LMB as his series looks to be basically ready and done

17:34 <Tartarus> iirc the "event" mechanism that was in earlier series was dropped

17:35 <Tartarus> We now just make the calls as needed, and have a CONFIG symbol for that being the case. The only change I've asked for is that the symbol needs to be select'd and not prompted for

17:35 <Tartarus> (Which to be clear, is a common problem with our Kconfig symbols, many things are prompted over when there's no real choice, you either enable $X or you have broken software)

17:42 <sjg1> I still see 'notify of any changes to the LMB memory map' although I see that it simply adds to the EFI memory map. I still see LMB_NONOTIFY.

17:42 <sjg1> Do you understand what I am saying about the point of co-operation?

17:52 <Tartarus> I've just now asked sng to elaborate on the use case and update the documentation as to what LMB_NONOTIFY is for exactly

17:53 <sjg1> It's to break the deadlock on the circular dependency, which it what my series avoids

17:53 <Tartarus> That said, I _think_ the flag is used so that we can add the whole of unused memory to the EFI memory map without inadvertently making an LMB that covers all of the rest of memory

17:53 <Tartarus> Nothing nefarious

18:20 <Tartarus> afk no power for a while