On Mon, Sep 07, 2020 at 03:48:16PM +0200, Michal Privoznik wrote:
Even though this was brought up in upstream discussion [1] it missed my patches: users should prefer <oemStrings/> over fwcfg. The reason is that fwcfg is considered somewhat internal to QEMU and it has limited number of slots and neither of these applies to <oemStrings/>.While I'm at it, I'm fixing the example too (because it contains incorrect element name) and clarifying sysfs/ exposure. 1: https://www.redhat.com/archives/libvir-list/2020-May/msg00957.html Reported-by: Laszlo Ersek <ler...@redhat.com> Signed-off-by: Michal Privoznik <mpriv...@redhat.com> --- docs/formatdomain.rst | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index 1979dfb8d3..821ffe8d60 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -509,18 +509,22 @@ layout of sub-elements, with supported values of: Some hypervisors provide unified way to tweak how firmware configures itself, or may contain tables to be installed for the guest OS, for instance boot order, ACPI, SMBIOS, etc. It even allows users to define their own config - blobs. In case of QEMU, these then appear under domain's sysfs, under + blobs. In case of QEMU, these then appear under domain's sysfs (if the guest + kernel has FW_CFG_SYSFS config option enabled), under ``/sys/firmware/qemu_fw_cfg``. Note, that these values apply regardless the <smbios/> mode under <os/>. :since:`Since 6.5.0` + **Please note that because of limited number of data slots use of fwcfg is + strongly discouraged and <oemStrings/> should be used instead**. +
It's nice that you say that, but people who would like to use fw_cfg for passing in a huge blob, which is saved in a file, will read this, go to <oemStrings/> and see that there is no way to pass a file as an input. Should that be dealt with somehow? Or would that be discouraged as well?
signature.asc
Description: PGP signature
