From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web10.29886.1660748838144688396 for ; Wed, 17 Aug 2022 08:07:18 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=P8hqUPTE; spf=pass (domain: kernel.org, ip: 139.178.84.217, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 847556154E for ; Wed, 17 Aug 2022 15:07:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E25B3C433B5 for ; Wed, 17 Aug 2022 15:07:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1660748836; bh=XBdmOGs3JjSIssp4gV2+lglFHE5gCbgUi3ZIyfJfAWw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=P8hqUPTEoVz2OuV2yqDfQssn/a4L8oFehrURvhqd76Y3v146wnkl65Pqqgy1fy7PJ 3tvUvA9j99xx538Z5GPxTVRvcfdrnUlty0NqUZsCB1Z6QTVQcTSY1wqUDgL2LPHITo 7j90Q6cNDTTEzUluLU+v5XXgY6pPfhyje4QjbisnL8bj4gbhUMqVjS4uV8kSWzsxjK ZvIR4U6YHvCLbAH8eiR+cBLKsO+lswNE3TgeO3f9pH9wUiRkjFweF+++9cprGiigHj cgc9256IGZXig2FVatJWssGLpJAaAt8v5wvd+fNuyviPNWdUdligTJPdOKcLlILDv1 jL6z09xj5XPdg== Received: by mail-wr1-f48.google.com with SMTP id bs25so16577593wrb.2 for ; Wed, 17 Aug 2022 08:07:16 -0700 (PDT) X-Gm-Message-State: ACgBeo24ZY6VdHJE5k+MrKJT6YRURllUrikK3B8zTotKqJ2Cqh6zGfUM wSzRigm8Lam0tFQnxpoGoWtdj+dRoKf4vvdeofs= X-Google-Smtp-Source: AA6agR5jwBc1uJ3Jw8HhOcNUiU4U5XndUmqauVM0GoRSn3+m8qg2qfFwyDSnyYMuWj6RoT5I2JRW+oyCU/gbm2FRrMs= X-Received: by 2002:adf:ebd2:0:b0:222:cd3f:cf9 with SMTP id v18-20020adfebd2000000b00222cd3f0cf9mr14706100wrn.598.1660748835106; Wed, 17 Aug 2022 08:07:15 -0700 (PDT) MIME-Version: 1.0 References: <20220815094030.465587-1-ardb@kernel.org> <20220815094030.465587-2-ardb@kernel.org> <3cc22b45-149b-15c5-257d-347d1a13cd96@redhat.com> <8a033ba8-967e-002d-2d39-6d19273403d2@hpe.com> <430f98a2-a95d-f2f4-36ef-1d1877c0dda7@redhat.com> In-Reply-To: <430f98a2-a95d-f2f4-36ef-1d1877c0dda7@redhat.com> From: "Ard Biesheuvel" Date: Wed, 17 Aug 2022 17:07:03 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH 1/2] OvmfPkg: Introduce NULL class library to inhibit driver load To: Laszlo Ersek Cc: devel@edk2.groups.io, brian.johnson@hpe.com, Yuan Yu , Gerd Hoffmann , Pawel Polawski , Oliver Steffen , Jiewen Yao Content-Type: text/plain; charset="UTF-8" On Wed, 17 Aug 2022 at 11:22, Laszlo Ersek 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 > > 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.