docs: Rename "BIOS bootloader" section to "guest firmware"

The new name is much more accurate since the documentation is
applicable to firmware other than BIOS, notably UEFI.

An empty container is used to keep old links working.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>

docs/formatcaps.rst

@@ -172,7 +172,7 @@ The ``<guest/>`` element will typically wrap up the following elements:
       Emulator (device model) path, for use in
       `emulator <formatdomain.html#devices>`__ element of domain XML.
    ``loader``
-      Loader path, for use in `loader <formatdomain.html#bios-bootloader>`__
+      Loader path, for use in `loader <formatdomain.html#guest-firmware>`__
       element of domain XML.
    ``machine``
       Machine type, for use in

docs/formatdomain.rst

@@ -103,12 +103,16 @@ Operating system booting
 There are a number of different ways to boot virtual machines each with their
 own pros and cons.
 
+Guest firmware
+~~~~~~~~~~~~~~
 
-BIOS bootloader
-~~~~~~~~~~~~~~~
+.. container::
+   :name: bios-bootloader
 
-Booting via the BIOS is available for hypervisors supporting full
-virtualization. In this case the BIOS has a boot order priority (floppy,
+   .. this container only exists to keep old links working
+
+Booting via a guest firmware is available for hypervisors supporting full
+virtualization. In this case the firmware has a boot order priority (floppy,
 harddisk, cdrom, network) determining where to obtain/find the boot image.
 
 ::
@@ -411,10 +415,10 @@ and full virtualized guests.
 
 ``type``
    This element has the same semantics as described earlier in the
-   `BIOS bootloader`_ section.
+   `guest firmware`_ section.
 ``loader``
    This element has the same semantics as described earlier in the
-   `BIOS bootloader`_ section.
+   `guest firmware`_ section.
 ``kernel``
    The contents of this element specify the fully-qualified path to the kernel
    image in the host OS.
@@ -3752,7 +3756,7 @@ paravirtualized driver is specified via the ``disk`` element.
    attribute is an 8 character string which can be queried by guests on S390 via
    sclp or diag 308. Linux guests on S390 can use ``loadparm`` to select a boot
    entry. :since:`Since 3.5.0` The per-device ``boot`` elements cannot be used
-   together with general boot elements in `BIOS bootloader`_
+   together with general boot elements in `guest firmware`_
    section. :since:`Since 0.8.8`
 ``encryption``
    since:`Since 3.9.0` the ``encryption`` element is preferred
@@ -4917,7 +4921,7 @@ or:
    Specifies that the device is bootable. The ``order`` attribute determines the
    order in which devices will be tried during boot sequence. The per-device
    ``boot`` elements cannot be used together with general boot elements in
-   `BIOS bootloader`_ section. :since:`Since 0.8.8` for PCI
+   `guest firmware`_ section. :since:`Since 0.8.8` for PCI
    devices, :since:`Since 1.0.1` for USB devices.
 ``rom``
    The ``rom`` element is used to change how a PCI device's ROM is presented to
@@ -5144,7 +5148,7 @@ USB device redirection through a character device is supported
    Specifies that the device is bootable. The ``order`` attribute determines the
    order in which devices will be tried during boot sequence. The per-device
    ``boot`` elements cannot be used together with general boot elements in
-   `BIOS bootloader`_ section. ( :since:`Since 1.0.1` )
+   `guest firmware`_ section. ( :since:`Since 1.0.1` )
 ``redirfilter``
    The\ ``redirfilter``\ element is used for creating the filter rule to filter
    out certain devices from redirection. It uses sub-element ``<usbdev>`` to
@@ -6400,7 +6404,7 @@ Specifying boot order
 For hypervisors which support this, you can set a specific NIC to be used for
 network boot. The ``order`` attribute determines the order in which devices will
 be tried during boot sequence. The per-device ``boot`` elements cannot be used
-together with general boot elements in `BIOS bootloader`_
+together with general boot elements in `guest firmware`_
 section. :since:`Since 0.8.8`
 
 Interface ROM BIOS configuration

docs/formatdomaincaps.rst

@@ -72,11 +72,11 @@ The root element that emulator capability XML document starts with has name
    Describes the `virtualization type <formatdomain.html#element-and-attribute-overview>`__ (or so
    called domain type).
 ``machine``
-   The domain's `machine type <formatdomain.html#bios-bootloader>`__. Since not
+   The domain's `machine type <formatdomain.html#guest-firmware>`__. Since not
    every hypervisor has a sense of machine types this element might be omitted
    in such drivers.
 ``arch``
-   The domain's `architecture <formatdomain.html#bios-bootloader>`__.
+   The domain's `architecture <formatdomain.html#guest-firmware>`__.
 
 CPU Allocation
 ~~~~~~~~~~~~~~
@@ -95,12 +95,17 @@ capabilities, e.g. virtual CPUs:
 ``vcpu``
    The maximum number of supported virtual CPUs
 
-BIOS bootloader
-~~~~~~~~~~~~~~~
+Guest firmware
+~~~~~~~~~~~~~~
 
-Sometimes users might want to tweak some BIOS knobs or use UEFI. For cases like
-that, `os <formatdomain.html#bios-bootloader>`__ element exposes what values can
-be passed to its children.
+.. container::
+   :name: bios-bootloader
+
+   .. this container only exists to keep old links working
+
+Exposes information about supported
+`guest firmware <formatdomain.html#guest-firmware>`__ configurations for
+domains.
 
 ::