On 08/17/22 10:39, Ard Biesheuvel wrote: > Agree with all of the above. At this point, I think the only way to do > this properly is to create an alternative UefiDriverEntrypoint library > with the fw_cfg check folded into it. This is easy to do and addresses > all the concerns raised here (as it can force the driver entry point > function to return any value at any point) but the code duplication is > unfortunate.
Ah, that's very creative. I didn't think of duplicating and customizing the entry point library! > On Tue, 16 Aug 2022 at 23:10, Brian J. Johnson <[email protected]> > wrote: >> I don't know how any physical machine handles that particular option. >> But one approach would be to add a GUID to the depex of the module >> you want to control, and install it only when you want the module to >> be dispatched. That's pretty straightforward, although it does >> result in "Driver %g was discovered but not loaded!!" messages from >> CoreDisplayDiscoveredNotDispatched() if sufficient debugging is >> enabled. >> > > I think the diagnostic is fine. But I don't think adding DEPEXes to > UEFI drivers (as opposed to DXE drivers) is proper, or even supported. > It would also require the drivers in other packages to be updated. Sigh, I'm totally getting rusty on all this (which is quite expected). You are right about the difference between DXE and UEFI drivers wrt. depexes. :/ > What i i like about the current approach is that the library can tie > any driver or app dispatch to any fw_cfg variable in QEMU (provided > that its build is directed by the .dsc in question). Switching to an > alternate UefiDriverEntrypoint implementation would limit this to > drivers, but this is fine for the purpose at hand. Just don't forget that the number of fw_cfg slots in QEMU is limited. It is exposed as an experimental property (x-file-slots) of the fw_cfg_io and fw_cfg_mem on-board devices. It matters for migration, and so it is versioned. It used to be 0x10, for the 2.8 and earlier machine types, and has been 0x20 for later machine types. See QEMU commit a5b3ebfd23bc. IOW, while the mechanism in edk2 could scale "indefinitely", QEMU will in effect limit the number of fw_cfg files that can be used for this purpose too. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#92511): https://edk2.groups.io/g/devel/message/92511 Mute This Topic: https://groups.io/mt/93032846/21656 Group Owner: [email protected] Unsubscribe: https://edk2.groups.io/g/devel/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
