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.web11.2425.1660572372935894633 for ; Mon, 15 Aug 2022 07:06:13 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=KOk1TC73; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1660572371; 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: in-reply-to:in-reply-to:references:references; bh=esWfrD3olPN0rqTsFw4az5njkAll06lpSo8cDlMkKR8=; b=KOk1TC734pwWut6o6jdhx9cNLb/U/5Hc2S26WHbZ9wVy0ybv2k/p5e8K4OIRVkK6Mngrsu RoAnw1USH9Hl8EKCwpspwCPyjXG0LfwndxuzJSJKgi9PGDwHUrTqVsdJAUrx0wNxNhTLn0 Lqu4jW2+Razm5uYgi97EWMbjx2SlvEI= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-558-VpMiD2DkOTOZn3ZjW1QEhA-1; Mon, 15 Aug 2022 10:06:07 -0400 X-MC-Unique: VpMiD2DkOTOZn3ZjW1QEhA-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 551543810D2D; Mon, 15 Aug 2022 14:06:06 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.6]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A7668492C3B; Mon, 15 Aug 2022 14:06:04 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 3CDB61800082; Mon, 15 Aug 2022 16:06:03 +0200 (CEST) Date: Mon, 15 Aug 2022 16:06:03 +0200 From: "Gerd Hoffmann" To: Ard Biesheuvel Cc: devel@edk2.groups.io, Yuan Yu , Laszlo Ersek , Pawel Polawski , Oliver Steffen , Jiewen Yao Subject: Re: [PATCH 2/2] OvmfPkg/OvmfPkgX64: Allow runtime control of IPv4 and IPv6 support Message-ID: <20220815140603.q2ggx47atcj3wnfp@sirius.home.kraxel.org> References: <20220815094030.465587-1-ardb@kernel.org> <20220815094030.465587-3-ardb@kernel.org> MIME-Version: 1.0 In-Reply-To: <20220815094030.465587-3-ardb@kernel.org> X-Scanned-By: MIMEDefang 2.85 on 10.11.54.10 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Aug 15, 2022 at 11:40:30AM +0200, Ard Biesheuvel wrote: > Wire up the newly added DriverLoadInhibitorLib in a way that ties > dispatch of the Ip4Dxe and Ip6Dxe drivers to QEMU fw_cfg variables > 'opt/org.tianocore/IPv4Support' and 'opt/org.tianocore/IPv6Support' > respectively. > > Setting both variables to 'n' disables IP based networking entirely, > without the need for additional code changes at the NIC driver or > network boot protocol level. > > Signed-off-by: Ard Biesheuvel > --- > OvmfPkg/OvmfPkgX64.dsc | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc > index 6e68f60dc90f..0c0ded88f86e 100644 > --- a/OvmfPkg/OvmfPkgX64.dsc > +++ b/OvmfPkg/OvmfPkgX64.dsc > @@ -947,6 +947,20 @@ [Components] > NULL|OvmfPkg/Library/PxeBcPcdProducerLib/PxeBcPcdProducerLib.inf > } > > + NetworkPkg/Ip4Dxe/Ip4Dxe.inf { > + > + NULL|OvmfPkg/Library/DriverLoadInhibitorLib/DriverLoadInhibitorLib.inf > + > + gUefiOvmfPkgTokenSpaceGuid.PcdDriverInhibitorFwCfgVarName|"opt/org.tianocore/IPv4Support" > + } > + > + NetworkPkg/Ip6Dxe/Ip6Dxe.inf { > + > + NULL|OvmfPkg/Library/DriverLoadInhibitorLib/DriverLoadInhibitorLib.inf > + > + gUefiOvmfPkgTokenSpaceGuid.PcdDriverInhibitorFwCfgVarName|"opt/org.tianocore/IPv6Support" > + } > + Hmm. Not a comment to this specifically, but more to the OVMF *.dsc and *.fdf files in general. We have a lot of duplication here. I've already moved some bits to include files (OvmfPkg/OvmfTpm*.inc for example) to reduce that. Makes maintainance easier and builds more consistent. This looks like a prime candidate for a new OvmfNetwork.dsc.inc file, so we can easily get that for all build variants and not only X64. And there is more which we can split out. crypto (have an experimental branch doing that as part of my CryptoPkg/Driver experiments). drivers (usb / virtio / ...). Shell.efi Maybe it makes sense to move those include snippets into a subdirectory so they don't pile up in OvmfPkg/ when we move more stuff to includes? take care, Gerd