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

["Ard Biesheuvel" <ardb@kernel.org>]

On Wed, 17 Aug 2022 at 11:22, Laszlo Ersek <lersek@redhat.com> wrote:
>
> 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!
>

Yeah, I'll spin a v2 based on this idea.

> > 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.
>

Right, that is good to know. But I don't think the point here is to
make each individual driver controllable from the command line. The
goal here is really to make this work in a way that is generic (i.e.,
not specific to networking) that doesn't require changes to the other
packages.