Re: [PATCH-for-6.2?] docs: Spell QEMU all caps

[Darren Kenny]

On Thursday, 2021-11-18 at 15:34:01 +01, Philippe Mathieu-Daudé wrote:
> Replace Qemu -> QEMU.
>
> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>

Reviewed-by: Darren Kenny <darren.kenny@oracle.com>

> ---
>  docs/devel/modules.rst                |  2 +-
>  docs/devel/multi-thread-tcg.rst       |  2 +-
>  docs/devel/style.rst                  |  2 +-
>  docs/devel/ui.rst                     |  4 ++--
>  docs/interop/nbd.txt                  |  6 +++---
>  docs/interop/qcow2.txt                |  8 ++++----
>  docs/multiseat.txt                    |  2 +-
>  docs/system/device-url-syntax.rst.inc |  2 +-
>  docs/system/i386/sgx.rst              | 26 +++++++++++++-------------
>  docs/u2f.txt                          |  2 +-
>  10 files changed, 28 insertions(+), 28 deletions(-)
>
> diff --git a/docs/devel/modules.rst b/docs/devel/modules.rst
> index 066f347b89b..8e999c4fa48 100644
> --- a/docs/devel/modules.rst
> +++ b/docs/devel/modules.rst
> @@ -1,5 +1,5 @@
>  ============
> -Qemu modules
> +QEMU modules
>  ============
>  
>  .. kernel-doc:: include/qemu/module.h
> diff --git a/docs/devel/multi-thread-tcg.rst b/docs/devel/multi-thread-tcg.rst
> index 5b446ee08b6..c9541a7b20a 100644
> --- a/docs/devel/multi-thread-tcg.rst
> +++ b/docs/devel/multi-thread-tcg.rst
> @@ -228,7 +228,7 @@ Emulated hardware state
>  
>  Currently thanks to KVM work any access to IO memory is automatically
>  protected by the global iothread mutex, also known as the BQL (Big
> -Qemu Lock). Any IO region that doesn't use global mutex is expected to
> +QEMU Lock). Any IO region that doesn't use global mutex is expected to
>  do its own locking.
>  
>  However IO memory isn't the only way emulated hardware state can be
> diff --git a/docs/devel/style.rst b/docs/devel/style.rst
> index 260e3263fa0..e00af62e763 100644
> --- a/docs/devel/style.rst
> +++ b/docs/devel/style.rst
> @@ -686,7 +686,7 @@ Rationale: hex numbers are hard to read in logs when 
> there is no 0x prefix,
>  especially when (occasionally) the representation doesn't contain any letters
>  and especially in one line with other decimal numbers. Number groups are 
> allowed
>  to not use '0x' because for some things notations like %x.%x.%x are used not
> -only in Qemu. Also dumping raw data bytes with '0x' is less readable.
> +only in QEMU. Also dumping raw data bytes with '0x' is less readable.
>  
>  '#' printf flag
>  ---------------
> diff --git a/docs/devel/ui.rst b/docs/devel/ui.rst
> index 06c7d622ce7..17fb667dec4 100644
> --- a/docs/devel/ui.rst
> +++ b/docs/devel/ui.rst
> @@ -1,8 +1,8 @@
>  =================
> -Qemu UI subsystem
> +QEMU UI subsystem
>  =================
>  
> -Qemu Clipboard
> +QEMU Clipboard
>  --------------
>  
>  .. kernel-doc:: include/ui/clipboard.h
> diff --git a/docs/interop/nbd.txt b/docs/interop/nbd.txt
> index 10ce098a29b..bdb0f2a41ac 100644
> --- a/docs/interop/nbd.txt
> +++ b/docs/interop/nbd.txt
> @@ -1,4 +1,4 @@
> -Qemu supports the NBD protocol, and has an internal NBD client (see
> +QEMU supports the NBD protocol, and has an internal NBD client (see
>  block/nbd.c), an internal NBD server (see blockdev-nbd.c), and an
>  external NBD server tool (see qemu-nbd.c). The common code is placed
>  in nbd/*.
> @@ -7,11 +7,11 @@ The NBD protocol is specified here:
>  https://github.com/NetworkBlockDevice/nbd/blob/master/doc/proto.md
>  
>  The following paragraphs describe some specific properties of NBD
> -protocol realization in Qemu.
> +protocol realization in QEMU.
>  
>  = Metadata namespaces =
>  
> -Qemu supports the "base:allocation" metadata context as defined in the
> +QEMU supports the "base:allocation" metadata context as defined in the
>  NBD protocol specification, and also defines an additional metadata
>  namespace "qemu".
>  
> diff --git a/docs/interop/qcow2.txt b/docs/interop/qcow2.txt
> index 0463f761efb..f7dc304ff69 100644
> --- a/docs/interop/qcow2.txt
> +++ b/docs/interop/qcow2.txt
> @@ -313,7 +313,7 @@ The fields of the bitmaps extension are:
>                     The number of bitmaps contained in the image. Must be
>                     greater than or equal to 1.
>  
> -                   Note: Qemu currently only supports up to 65535 bitmaps per
> +                   Note: QEMU currently only supports up to 65535 bitmaps per
>                     image.
>  
>            4 -  7:  Reserved, must be zero.
> @@ -775,7 +775,7 @@ Structure of a bitmap directory entry:
>                        2: extra_data_compatible
>                           This flags is meaningful when the extra data is
>                           unknown to the software (currently any extra data is
> -                         unknown to Qemu).
> +                         unknown to QEMU).
>                           If it is set, the bitmap may be used as expected, 
> extra
>                           data must be left as is.
>                           If it is not set, the bitmap must not be used, but
> @@ -793,7 +793,7 @@ Structure of a bitmap directory entry:
>               17:    granularity_bits
>                      Granularity bits. Valid values: 0 - 63.
>  
> -                    Note: Qemu currently supports only values 9 - 31.
> +                    Note: QEMU currently supports only values 9 - 31.
>  
>                      Granularity is calculated as
>                          granularity = 1 << granularity_bits
> @@ -804,7 +804,7 @@ Structure of a bitmap directory entry:
>          18 - 19:    name_size
>                      Size of the bitmap name. Must be non-zero.
>  
> -                    Note: Qemu currently doesn't support values greater than
> +                    Note: QEMU currently doesn't support values greater than
>                      1023.
>  
>          20 - 23:    extra_data_size
> diff --git a/docs/multiseat.txt b/docs/multiseat.txt
> index 11850c96ff8..2b297e979d6 100644
> --- a/docs/multiseat.txt
> +++ b/docs/multiseat.txt
> @@ -123,7 +123,7 @@ Background info is here:
>  guest side with pci-bridge-seat
>  -------------------------------
>  
> -Qemu version 2.4 and newer has a new pci-bridge-seat device which
> +QEMU version 2.4 and newer has a new pci-bridge-seat device which
>  can be used instead of pci-bridge.  Just swap the device name in the
>  qemu command line above.  The only difference between the two devices
>  is the pci id.  We can match the pci id instead of the device path
> diff --git a/docs/system/device-url-syntax.rst.inc 
> b/docs/system/device-url-syntax.rst.inc
> index d15a0215087..7dbc525fa80 100644
> --- a/docs/system/device-url-syntax.rst.inc
> +++ b/docs/system/device-url-syntax.rst.inc
> @@ -15,7 +15,7 @@ These are specified using a special URL syntax.
>     'iqn.2008-11.org.linux-kvm[:<name>]' but this can also be set from
>     the command line or a configuration file.
>  
> -   Since version Qemu 2.4 it is possible to specify a iSCSI request
> +   Since version QEMU 2.4 it is possible to specify a iSCSI request
>     timeout to detect stalled requests and force a reestablishment of the
>     session. The timeout is specified in seconds. The default is 0 which
>     means no timeout. Libiscsi 1.15.0 or greater is required for this
> diff --git a/docs/system/i386/sgx.rst b/docs/system/i386/sgx.rst
> index 9aa161af1a1..f8fade5ac2d 100644
> --- a/docs/system/i386/sgx.rst
> +++ b/docs/system/i386/sgx.rst
> @@ -20,13 +20,13 @@ report the same CPUID info to guest as on host for most 
> of SGX CPUID. With
>  reporting the same CPUID guest is able to use full capacity of SGX, and KVM
>  doesn't need to emulate those info.
>  
> -The guest's EPC base and size are determined by Qemu, and KVM needs Qemu to
> +The guest's EPC base and size are determined by QEMU, and KVM needs QEMU to
>  notify such info to it before it can initialize SGX for guest.
>  
>  Virtual EPC
>  ~~~~~~~~~~~
>  
> -By default, Qemu does not assign EPC to a VM, i.e. fully enabling SGX in a VM
> +By default, QEMU does not assign EPC to a VM, i.e. fully enabling SGX in a VM
>  requires explicit allocation of EPC to the VM. Similar to other specialized
>  memory types, e.g. hugetlbfs, EPC is exposed as a memory backend.
>  
> @@ -35,12 +35,12 @@ prior to realizing the vCPUs themselves, which occurs 
> long before generic
>  devices are parsed and realized.  This limitation means that EPC does not
>  require -maxmem as EPC is not treated as {cold,hot}plugged memory.
>  
> -Qemu does not artificially restrict the number of EPC sections exposed to a
> -guest, e.g. Qemu will happily allow you to create 64 1M EPC sections. Be 
> aware
> +QEMU does not artificially restrict the number of EPC sections exposed to a
> +guest, e.g. QEMU will happily allow you to create 64 1M EPC sections. Be 
> aware
>  that some kernels may not recognize all EPC sections, e.g. the Linux SGX 
> driver
>  is hardwired to support only 8 EPC sections.
>  
> -The following Qemu snippet creates two EPC sections, with 64M pre-allocated
> +The following QEMU snippet creates two EPC sections, with 64M pre-allocated
>  to the VM and an additional 28M mapped but not allocated::
>  
>   -object memory-backend-epc,id=mem1,size=64M,prealloc=on \
> @@ -54,7 +54,7 @@ to physical EPC. Because physical EPC is protected via 
> range registers,
>  the size of the physical EPC must be a power of two (though software sees
>  a subset of the full EPC, e.g. 92M or 128M) and the EPC must be naturally
>  aligned.  KVM SGX's virtual EPC is purely a software construct and only
> -requires the size and location to be page aligned. Qemu enforces the EPC
> +requires the size and location to be page aligned. QEMU enforces the EPC
>  size is a multiple of 4k and will ensure the base of the EPC is 4k aligned.
>  To simplify the implementation, EPC is always located above 4g in the guest
>  physical address space.
> @@ -62,7 +62,7 @@ physical address space.
>  Migration
>  ~~~~~~~~~
>  
> -Qemu/KVM doesn't prevent live migrating SGX VMs, although from hardware's
> +QEMU/KVM doesn't prevent live migrating SGX VMs, although from hardware's
>  perspective, SGX doesn't support live migration, since both EPC and the SGX
>  key hierarchy are bound to the physical platform. However live migration
>  can be supported in the sense if guest software stack can support recreating
> @@ -76,7 +76,7 @@ CPUID
>  ~~~~~
>  
>  Due to its myriad dependencies, SGX is currently not listed as supported
> -in any of Qemu's built-in CPU configuration. To expose SGX (and SGX Launch
> +in any of QEMU's built-in CPU configuration. To expose SGX (and SGX Launch
>  Control) to a guest, you must either use ``-cpu host`` to pass-through the
>  host CPU model, or explicitly enable SGX when using a built-in CPU model,
>  e.g. via ``-cpu <model>,+sgx`` or ``-cpu <model>,+sgx,+sgxlc``.
> @@ -101,7 +101,7 @@ controlled via -cpu are prefixed with "sgx", e.g.::
>    sgx2
>    sgxlc
>  
> -The following Qemu snippet passes through the host CPU but restricts access 
> to
> +The following QEMU snippet passes through the host CPU but restricts access 
> to
>  the provision and EINIT token keys::
>  
>   -cpu host,-sgx-provisionkey,-sgx-tokenkey
> @@ -112,11 +112,11 @@ in hardware cannot be forced on via '-cpu'.
>  Virtualize SGX Launch Control
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  
> -Qemu SGX support for Launch Control (LC) is passive, in the sense that it
> -does not actively change the LC configuration.  Qemu SGX provides the user
> +QEMU SGX support for Launch Control (LC) is passive, in the sense that it
> +does not actively change the LC configuration.  QEMU SGX provides the user
>  the ability to set/clear the CPUID flag (and by extension the associated
>  IA32_FEATURE_CONTROL MSR bit in fw_cfg) and saves/restores the LE Hash MSRs
> -when getting/putting guest state, but Qemu does not add new controls to
> +when getting/putting guest state, but QEMU does not add new controls to
>  directly modify the LC configuration.  Similar to hardware behavior, locking
>  the LC configuration to a non-Intel value is left to guest firmware.  Unlike
>  host bios setting for SGX launch control(LC), there is no special bios 
> setting
> @@ -126,7 +126,7 @@ creating VM with SGX.
>  Feature Control
>  ~~~~~~~~~~~~~~~
>  
> -Qemu SGX updates the ``etc/msr_feature_control`` fw_cfg entry to set the SGX
> +QEMU SGX updates the ``etc/msr_feature_control`` fw_cfg entry to set the SGX
>  (bit 18) and SGX LC (bit 17) flags based on their respective CPUID support,
>  i.e. existing guest firmware will automatically set SGX and SGX LC 
> accordingly,
>  assuming said firmware supports fw_cfg.msr_feature_control.
> diff --git a/docs/u2f.txt b/docs/u2f.txt
> index 8f44994818a..7f5813a0b72 100644
> --- a/docs/u2f.txt
> +++ b/docs/u2f.txt
> @@ -21,7 +21,7 @@ The second factor is materialized by a device implementing 
> the U2F
>  protocol. In case of a USB U2F security key, it is a USB HID device
>  that implements the U2F protocol.
>  
> -In Qemu, the USB U2F key device offers a dedicated support of U2F, allowing
> +In QEMU, the USB U2F key device offers a dedicated support of U2F, allowing
>  guest USB FIDO/U2F security keys operating in two possible modes:
>  pass-through and emulated.
>  
> -- 
> 2.31.1