From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-74.mimecast.com (us-smtp-delivery-74.mimecast.com [216.205.24.74]) by mx.groups.io with SMTP id smtpd.web10.344.1585350129551449875 for ; Fri, 27 Mar 2020 16:02:09 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=LfFPDwsP; spf=pass (domain: redhat.com, ip: 216.205.24.74, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1585350128; 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=6ouPNrPfbbrEOOUs96k8y2Gm3R6FftTxQgBxp2HnncA=; b=LfFPDwsP9VY0qKi3QH2/nfcA35pmT4UF5ULZQMscsRgrYZeCnFlT6tt6ee9eedY1I7kAHv t0S+n8oLuO+GjWhU+A/CXJS+sV3z4ks0e2KZrFjCEouvwTxo4r03ULtJmrxEjIJsKgXZp2 u2EkWvRJZFZRp1U6yPrArpmUrJ1LWxk= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-265-9EZ-CfQ_NV2ajtHlvRxtNA-1; Fri, 27 Mar 2020 19:02:03 -0400 X-MC-Unique: 9EZ-CfQ_NV2ajtHlvRxtNA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id BE2B31005512; Fri, 27 Mar 2020 23:02:01 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-114-36.ams2.redhat.com [10.36.114.36]) by smtp.corp.redhat.com (Postfix) with ESMTP id BA8507E303; Fri, 27 Mar 2020 23:02:00 +0000 (UTC) Subject: Re: [edk2-devel] Initial PXE boot over IPv6 To: per_sundstrom@yahoo.com References: <15C7FD98-549E-43B7-93B3-EA71F88F393E@apple.com> From: "Laszlo Ersek" Cc: devel@edk2.groups.io, afish@apple.com Message-ID: <1fc582e2-5c62-76d9-a5ff-571d0e21a694@redhat.com> Date: Sat, 28 Mar 2020 00:01:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <15C7FD98-549E-43B7-93B3-EA71F88F393E@apple.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Hello Per, unfortunately, due to the spectacularly broken threading in this discussion, I have to reconstruct the history manually first: On Mar 27, 2020, at 8:51 AM, per_sundstrom via Groups.Io wrote: > I want to exclusively use PXE/IPv6 when deploying a set of physical > machines with some QEMU/KVM virtual machines on top. > > So far, the only [hacky] way I have managed to do this is to: > 1) Bring up a VM with OVMF > 2) Set the wanted boot-order with PXE over IPv6 at the top > 3) Save this to the NVRAM > 4) Repete the above for a set of VMs with different MAC addresse > 5) Keep these NVRAMs as "canned" templates (with associated fixed > MACs) > 4) Later use one of these NVRAM as a template for VMs with the > associated MAC > > Obviously this does not scale to hundreds of VMs > > Reading through the code is seems that it might be possible to disable > PXE over IPv4 with the PCD variable "IPv4PXESupport" = binary zero>. > > I have tried with > > > > where the file is a one byte binary zero and I have verified that it > shows up in /sys/firmware/qemu_fw_cfg. > linux-u7u9:/sys/firmware/qemu_fw_cfg/by_name # ls opt/ovmf/X-PcdIPv4PXESupport/ > key name raw size > linux-u7u9:/sys/firmware/qemu_fw_cfg/by_name # cat opt/ovmf/X-PcdIPv4PXESupport/size > 1 > linux-u7u9:/sys/firmware/qemu_fw_cfg/by_name # od -b opt/ovmf/X-PcdIPv4PXESupport/raw > 0000000 000 > Is this something that should work, or is this variable compiled in ? > Are there other ways of acomplishing what I try to do ? On 03/27/20 18:05, Andrew Fish via Groups.Io wrote: > PCD's are a Platform Configuration Database that is used in the edk2. > Values can be compiled in, patched in binaries, or looked up > dynamically in a database. The idea is the consuming code, like the > UefiPxeBcDxe driver, codes stays the same and the platform sets the > mechanism that is used. It looks like value you care about is > resolving to a compiled in constant. > > If you want to change the value in the build go to > OvmfPkg/OvmfPkgX64.dsc (or the platform build DSC file you are using) > under the [PcdsFixedAtBuild] section add this line: > gEfiNetworkPkgTokenSpaceGuid.PcdIPv4PXESupport|0 > > This PCD value is defined here: NetworkPkg/NetworkPkg.dec > [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx] > ... > ## IPv4 PXE support > # 0x01 = PXE Enabled > # 0x00 = PXE Disabled > gEfiNetworkPkgTokenSpaceGuid.PcdIPv4PXESupport|0x01|UINT8|0x10000009 > > The list of types define (DEClare) the legal PCD types and the default > value. Adding the info to the OVMF DSC file lets the platform build > control the PCD type and the default value. > > Feel free to file a bugzilla and ask for a command line build option > to control this feature. On 03/27/20 18:38, per_sundstrom via Groups.Io wrote: > Thanks for the quick reply. > I sort of suspected that it was compiled in :-( > > How hard would it be to have it configured through fw_cfg ? > We are on a supported distro and are not allowed homebrewed binaries. > > And, [more importantly] are there any other ways of persuading OVMF to > boot from IPv6 without manually updating the boot order ? Please file a TianoCore Feature Request here: https://bugzilla.tianocore.org/ Upon reading this thread, I was initially *very* opposed to exposing this PCD via fw_cfg. Every PCD we expose like that ends up being a "contract" between users of OVMF and the internals of edk2, even if we carefully use the "X-" prefix ("experimental"). In particular, you seem to want to use this config knob in a production environment -- I'm sure you wouldn't appreciate if, after an OVMF package upgrade, the knob simply disappeared, and we'd justify that with "we told you so, the name was X-whatever!". ... However, based on , and the corresponding commit b29e6365c37f ("NetworkPkg/UefiPxeBcDxe:Add two PCD to control PXE.", 2019-04-22), exposing this particular PCD feels a tiny bit safer. It appears to be exposed through HII on some (undisclosed) physical platforms as of this moment. That suggests the PCD is here to stay in the long run (also I note the DEC file permits dynamic access at once). So I guess we could investigate something similar to commit ab081a50e565 ("OvmfPkg: PlatformPei: take no-exec DXE settings from the QEMU command line", 2015-09-15). Hence my suggestion to file a Feature Request. I'm not happy about this (this control knob is coarse-grained, and it doesn't cover other aspects -- what about ordering HTTP(S) boot versus PXE? what about ordering IPv4 vs. IPv6 in HTTPS?), but given that the PCD exists, and is arguably exposed on physical platforms via HII, I guess I won't program myself into a corner when exposing the PCD through fw_cfg. :/ No promises. I might be able to look into it, as time allows. And no, I don't have any other suggestion, especially if the feature is desired for virtual machines that already have Secure Boot enabled when they PXE-boot. BTW, the following QEMU syntax exists too: -fw_cfg [name=],string= That is, simple string content can be placed into externally provided fw_cfg files directly on the QEMU cmdline; no host-side file is needed. See section "Externally Provided Items" in "docs/specs/fw_cfg.txt" in the QEMU tree. (Mentioning this in case we end up with a "y/n" user interface or some such.) Thanks Laszlo