From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web09.27086.1660728128537999137 for ; Wed, 17 Aug 2022 02:22:09 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=A2eUCicH; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1660728127; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HOIMOVSfE7A7BuPKkPPvLm/iPmksFYKHQvmd4L6CVd8=; b=A2eUCicHS76+UMytMWZVpT+G+w+ZkKAGIcjdP3NRePPNxIGuKuFvhsClTqgOPyQey+Ou7C rPiNswZBlMxcKTp9oNgfVt+RO54mNq/iAVWU5zkl7E2BoF5wdBmPArZMb3zjmNh5HEz2Cb G/XpBICjWt7tv1LQU09mRfjgmOORuHc= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-450-vodQHtAZM3Gn_x-ne4cFvg-1; Wed, 17 Aug 2022 05:22:03 -0400 X-MC-Unique: vodQHtAZM3Gn_x-ne4cFvg-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 2BA8B85A581; Wed, 17 Aug 2022 09:22:03 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (unknown [10.39.193.174]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A4D97141512E; Wed, 17 Aug 2022 09:22:01 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH 1/2] OvmfPkg: Introduce NULL class library to inhibit driver load To: Ard Biesheuvel , devel@edk2.groups.io, brian.johnson@hpe.com Cc: Yuan Yu , Gerd Hoffmann , Pawel Polawski , Oliver Steffen , Jiewen Yao 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> From: "Laszlo Ersek" Message-ID: <430f98a2-a95d-f2f4-36ef-1d1877c0dda7@redhat.com> Date: Wed, 17 Aug 2022 11:22:00 +0200 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.85 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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 > 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.