Re: [edk2-devel] [PATCH 1/2] OvmfPkg: Introduce NULL class library to inhibit driver load

["Laszlo Ersek" <lersek@redhat.com>]

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 <brian.johnson@hpe.com>
> 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.