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>
---
docs/formatcaps.rst | 2 +-
docs/formatdomain.rst | 24 ++++++++++++++----------
docs/formatdomaincaps.rst | 19 ++++++++++++-------
3 files changed, 27 insertions(+), 18 deletions(-)
diff --git a/docs/formatcaps.rst b/docs/formatcaps.rst
index fa8ab5197f..9458e1289a 100644
--- a/docs/formatcaps.rst
+++ b/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
diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
index 82788c15a2..db664857af 100644
--- a/docs/formatdomain.rst
+++ b/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
+
+ .. this container only exists to keep old links working
-Booting via the BIOS is available for hypervisors supporting full
-virtualization. In this case the BIOS has a boot order priority (floppy,
+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
diff --git a/docs/formatdomaincaps.rst b/docs/formatdomaincaps.rst
index cca827923c..22a6d5d067 100644
--- a/docs/formatdomaincaps.rst
+++ b/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
+~~~~~~~~~~~~~~
+
+.. container::
+ :name: bios-bootloader
+
+ .. this container only exists to keep old links working
-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.
+Exposes information about supported
+`guest firmware <formatdomain.html#guest-firmware>`__ configurations for
+domains.
::
--
2.53.0