* Initial PXE boot over IPv6 @ 2020-03-27 15:51 per_sundstrom 2020-03-27 17:05 ` [edk2-devel] " Andrew Fish 0 siblings, 1 reply; 4+ messages in thread From: per_sundstrom @ 2020-03-27 15:51 UTC (permalink / raw) To: devel [-- Attachment #1: Type: text/plain, Size: 1421 bytes --] Hi, 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" = <one byte binary zero>. I have tried with <qemu:arg value='-fw_cfg'/> <qemu:arg value='opt/ovmf/X-PcdIPv4PXESupport,file=/var/lib/libvirt/qemu/nvram/zero'/> 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 ? Thanks, /Per [-- Attachment #2: Type: text/html, Size: 1872 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [edk2-devel] Initial PXE boot over IPv6 2020-03-27 15:51 Initial PXE boot over IPv6 per_sundstrom @ 2020-03-27 17:05 ` Andrew Fish 2020-03-27 17:38 ` per_sundstrom 2020-03-27 23:01 ` Laszlo Ersek 0 siblings, 2 replies; 4+ messages in thread From: Andrew Fish @ 2020-03-27 17:05 UTC (permalink / raw) To: devel, per_sundstrom [-- Attachment #1: Type: text/plain, Size: 2813 bytes --] /Per, 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. Thanks, Andrew Fish > On Mar 27, 2020, at 8:51 AM, per_sundstrom via Groups.Io <per_sundstrom=yahoo.com@groups.io> wrote: > > Hi, > 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" = <one byte binary zero>. > > I have tried with > <qemu:arg value='-fw_cfg'/> > <qemu:arg value='opt/ovmf/X-PcdIPv4PXESupport,file=/var/lib/libvirt/qemu/nvram/zero'/> > > 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 ? > > Thanks, > > /Per > [-- Attachment #2: Type: text/html, Size: 4458 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [edk2-devel] Initial PXE boot over IPv6 2020-03-27 17:05 ` [edk2-devel] " Andrew Fish @ 2020-03-27 17:38 ` per_sundstrom 2020-03-27 23:01 ` Laszlo Ersek 1 sibling, 0 replies; 4+ messages in thread From: per_sundstrom @ 2020-03-27 17:38 UTC (permalink / raw) To: Andrew Fish, devel [-- Attachment #1: Type: text/plain, Size: 352 bytes --] 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 ? /Per [-- Attachment #2: Type: text/html, Size: 391 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [edk2-devel] Initial PXE boot over IPv6 2020-03-27 17:05 ` [edk2-devel] " Andrew Fish 2020-03-27 17:38 ` per_sundstrom @ 2020-03-27 23:01 ` Laszlo Ersek 1 sibling, 0 replies; 4+ messages in thread From: Laszlo Ersek @ 2020-03-27 23:01 UTC (permalink / raw) To: per_sundstrom; +Cc: devel, afish 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 <per_sundstrom=yahoo.com@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" = <one byte > binary zero>. > > I have tried with > <qemu:arg value='-fw_cfg'/> > <qemu:arg value='opt/ovmf/X-PcdIPv4PXESupport,file=/var/lib/libvirt/qemu/nvram/zero'/> > > 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 <https://bugzilla.tianocore.org/show_bug.cgi?id=1695>, 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=]<item_name>,string=<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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-03-27 23:02 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-03-27 15:51 Initial PXE boot over IPv6 per_sundstrom 2020-03-27 17:05 ` [edk2-devel] " Andrew Fish 2020-03-27 17:38 ` per_sundstrom 2020-03-27 23:01 ` Laszlo Ersek
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox