On 03/17/16 09:42, Gerd Hoffmann wrote: > Hi, > >>> Having a mis-use of this feature become "institutionalized" over time was >>> seen as a low/negligible risk at the time. Do we have any new reasons >>> to worry about it ? >> >> OVMF uses this feature for a few flags. They are all called >> "opt/ovmf/...". I followed the advice in "docs/specs/fw_cfg.txt" (which >> shouldn't be surprising since I seem to have reviewed every patch for >> that file): > > seabios has a few flags too, in etc/. Some of them are supported > directly by qemu (such as setting the boot menu delay). Others are not, > and I'd like to be able to use -fw_cfg for them for testing/debugging > (any use cases beyond that should be supported by adding a less obscure > way to set them to qemu, similar to the boot delay). > > Oh, and that'll most likely be more seabios testing than qemu testing, > so why require me build a special qemu version for that?
+1 > On the ovmf flags: What kind of flags are there? Anything a normal > user might want to set? Occasionally, yes. - "opt/ovmf/PcdPropertiesTableEnable" controls whether the "properties table" UEFI feature is enabled. Some guest OSes support it, some others are broken by it. It defaults to false. - "opt/ovmf/PcdSetNxForStack" controls whether the stack is made non-executable at the start of the DXE phase. This is meant as a security feature in edk2 generally, it is not specific to OVMF; only the way it is exposed to users is specific to OVMF. It used to default to TRUE, but then people reported that a non-executable stack was breaking grub2-efi binaries that had been shipped on Debian installer ISOs sometime during the middle ages. So I was forced to change the default to FALSE (and I hate that compromise to this day). - "opt/ovmf/X-PciMmio64Mb" controls the size of the range from which the 64-bit MMIO BARs are allocated. It defaults to 32GB (and as you suggested, a natural alignment is also ensured, both for the default 32GB, and for the user's choice, if any). The "X-" prefix signals that this is an experimental knob without any promise of stability. There are two imporant use cases for this knob at the moment: (a) if a user has a bunch of MMIO-hungry assignable devices, allow him/her to experiment with this flag, and report his/her data to us, so we can come up with smart heuristics, (b) allow a user to disable the high allocation of 64-bit MMIO BARs entirely, by setting the value to 0. The edk2 BAR allocation code prefers to allocate 64-bit BARs actually high -- unlike SeaBIOS --, and this has already exposed problems. For example, such devices don't work -- at the moment -- behind PXBs, if you use OVMF. Marcel is going to enhance PXB to support this (thank you!), but even until then (and for yet unknown similar issues), this flag allows a user to force the edk2 allocator to keep those 64-bit BARs under 4GB, at least if there is enough room for them there.) In downstream, we have two more (same purpose but separately for ARM and x86): - opt/aavmf/PcdResizeXterm - opt/ovmf/PcdResizeXterm (These settings are downstream only because the underlying feature that they control was rejected by upstream.) The feature they control is the following: assume you are at the UEFI shell prompt, and you have at least two console devices (e.g., one serial console you are looking at in xterm, and one video display you are looking at with spice), with the text output being mirrored to both. The MODE command allows you to select various text resolutions that are supported by all of your console devices simultaneously. Let's say you change from the default 80x25 to 100x31. This will correctly resize your video display, and also change the textual resolution used on the serial console, but it will *not* resize your xterm. Which means the serial console output will be garbled when you scroll, when you use commands that print wide tables, and so on. If the user sets the above knob to Y, then the xterm will also be resized (via control sequences). Sometimes this feature is invaluable, sometimes it's very annoying. It defaults to N. - Another flag I might expose later is "PcdHiiOsRuntimeSupport". This would control whether various bits of UEFI configuration that are normally accessible through TUI forms in the UEFI setup are also exposed as a large binary blob to the runtime OS. As I understand it, this feature is meant to allow OS-level vendor applications to mess with various firmware settings. For now OVMF inherits the central default Y. It is somewhat costly, so I think I'll flip the default for OVMF to N, but expose the knob under "opt/ovmf/PcdHiiOsRuntimeSupport" to support people who want to experiment with this. -*- The X-... knob might go away at any time, the others are likely to stay. And, obviously, exposing this kind of knob with dedicated QEMU options is out of question. Thanks Laszlo
