> On 30. May 2023, at 12:02, Ard Biesheuvel wrote: > > On Tue, 30 May 2023 at 11:53, Marvin Häuser > wrote: >> >> >> >> On 30. May 2023, at 11:48, Ard Biesheuvel wrote: >> >> On Tue, 30 May 2023 at 11:47, Ard Biesheuvel wrote: >> >> >> On Tue, 30 May 2023 at 11:42, Marvin Häuser wrote: >> >> >> I took a *very brief* look at the entire series now. Is this just to apply permissions before CpuDxe is loaded >> >> >> Yes. >> >> >> Well, actually, the first part of the series gets rid of some >> pointless memory copies, which is an improvement in itself. >> >> >> Sorry, I didn't mean the series, I meant the choice to handle things in DxeIpl over DxeCore in particular. >> >> Is there even a non-FOSS producer of the CpuArch protocol? To my understanding, all (common) Intel platforms use the one in UefiCpuPkg. ARM and friends feel a lot less proprietary to begin with, but I could be wrong. We were quite successful so far with just merging CpuArch into DxeCore and setting it up quite early, but of course not at an industry-wide scale. :) > > What about the dependencies of CpuArch protocol? On ARM, this is the > GIC driver (for the interrupt controller), which has its own platform > specific dependencies. Hmm, was that for the exception handler? I forgot that was in CpuDxe too, I specifically meant the memory permission related things, sorry! > > So this is not tractable in general, and the only options we have (imo) are > > - add memory permission attribute handling to DxeCore directly (via a > library with arch specific implementations) Yes, this. > - add a way to dispatch the CpuDxe *and its dependencies* without the > need to manipulate memory permissions That would be awful and I'd prefer your current solution over this. > > Clumping everything together into DxeCore does not appear to me as a > sustainable approach for this.