| Message ID | 504170a4a195551072c14141e28ef554ac1cad2c.1736937491.git.bernhard.kaindl@cloud.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | docs: Improve spelling of few cases in the documentation | expand |
On 15.01.2025 11:42, Bernhard Kaindl wrote: > --- a/docs/admin-guide/microcode-loading.rst > +++ b/docs/admin-guide/microcode-loading.rst > @@ -20,7 +20,7 @@ distro guidance for microcode loading. > Microcode can make almost arbitrary changes to the processor, including to > software visible features. This includes removing features (e.g. the Haswell > TSX errata which necessitated disabling the feature entirely), or the addition > -of brand new features (e.g. the Spectre v2 controls to work around speculative > +of brand-new features (e.g. the Spectre v2 controls to work around speculative > execution vulnerabilities). This having been written by a native speaker, I'm uncertain of the strict need for a dash (also in one or two further places you touch). > @@ -40,7 +40,7 @@ Xen will report during boot if it performed a microcode update:: > (XEN) microcode: CPU6 updated from revision 0x1a to 0x25, date = 2018-04-02 > > The exact details printed are system and microcode specific. After boot, the > -current microcode version can obtained from with dom0:: > +current microcode version can be obtained from with dom0:: Pretty certainly then also s/with/within/ ? Jan
On 15/01/2025 11:27 am, Jan Beulich wrote: > On 15.01.2025 11:42, Bernhard Kaindl wrote: >> --- a/docs/admin-guide/microcode-loading.rst >> +++ b/docs/admin-guide/microcode-loading.rst >> @@ -20,7 +20,7 @@ distro guidance for microcode loading. >> Microcode can make almost arbitrary changes to the processor, including to >> software visible features. This includes removing features (e.g. the Haswell >> TSX errata which necessitated disabling the feature entirely), or the addition >> -of brand new features (e.g. the Spectre v2 controls to work around speculative >> +of brand-new features (e.g. the Spectre v2 controls to work around speculative >> execution vulnerabilities). > This having been written by a native speaker, I'm uncertain of the strict need > for a dash (also in one or two further places you touch). Both are fine, but without a dash is more common. I'd leave it as it was. > >> @@ -40,7 +40,7 @@ Xen will report during boot if it performed a microcode update:: >> (XEN) microcode: CPU6 updated from revision 0x1a to 0x25, date = 2018-04-02 >> >> The exact details printed are system and microcode specific. After boot, the >> -current microcode version can obtained from with dom0:: >> +current microcode version can be obtained from with dom0:: > Pretty certainly then also s/with/within/ ? Oh, this is slightly stale now we print the BSP microcode version on boot, and also since xen-ucode can be used to find the revision. I'll do a larger update to this paragraph, including both fixes on this line. ~Andrew
diff --git a/docs/admin-guide/microcode-loading.rst b/docs/admin-guide/microcode-loading.rst index a07e25802f..f9b2b73d17 100644 --- a/docs/admin-guide/microcode-loading.rst +++ b/docs/admin-guide/microcode-loading.rst @@ -20,7 +20,7 @@ distro guidance for microcode loading. Microcode can make almost arbitrary changes to the processor, including to software visible features. This includes removing features (e.g. the Haswell TSX errata which necessitated disabling the feature entirely), or the addition -of brand new features (e.g. the Spectre v2 controls to work around speculative +of brand-new features (e.g. the Spectre v2 controls to work around speculative execution vulnerabilities). @@ -40,7 +40,7 @@ Xen will report during boot if it performed a microcode update:: (XEN) microcode: CPU6 updated from revision 0x1a to 0x25, date = 2018-04-02 The exact details printed are system and microcode specific. After boot, the -current microcode version can obtained from with dom0:: +current microcode version can be obtained from with dom0:: [root@host ~]# head /proc/cpuinfo processor : 0 diff --git a/docs/designs/non-cooperative-migration.md b/docs/designs/non-cooperative-migration.md index 4b876d809f..54496892ed 100644 --- a/docs/designs/non-cooperative-migration.md +++ b/docs/designs/non-cooperative-migration.md @@ -112,7 +112,7 @@ because the guest can sample its own domid from the frontend area and use it in hypercalls (e.g. HVMOP_set_param) rather than DOMID_SELF, the guest domid must also be preserved to maintain the ABI. -Furthermore, it will necessary to modify backend drivers to re-establish +Furthermore, it will be necessary to modify backend drivers to re-establish communication with frontend drivers without perturbing the content of the backend area or requiring any changes to the values of the xenstore state nodes. @@ -259,7 +259,7 @@ Essentially this should skip the check to see if PV drivers and migrate as if there are none present, but also enabling the extra save records. Note that at least some of the extra records should only form part of a non-cooperative migration stream. For example, migrating event channel -state would be counter productive in a normal migration as this will +state would be counter-productive in a normal migration as this will essentially leak event channel objects at the receiving end. Others, such as grant table state, could potentially harmlessly form part of a normal migration stream. diff --git a/docs/designs/qemu-deprivilege.md b/docs/designs/qemu-deprivilege.md index 81a5f5c05d..f12b1a3ae3 100644 --- a/docs/designs/qemu-deprivilege.md +++ b/docs/designs/qemu-deprivilege.md @@ -3,7 +3,7 @@ The goal of deprilvileging qemu is this: Even if there is a bug (for example in qemu) which permits a domain to gain control of the device model, the compromised device model process is prevented from -violating the system's overall security properties. Ie, a guest +violating the system's overall security properties. I.e., a guest cannot "escape" from the virtualisation by using a qemu bug. This document lists the various technical measures which we either diff --git a/docs/guest-guide/x86/hypercall-abi.rst b/docs/guest-guide/x86/hypercall-abi.rst index 745fbbb64a..e52ed453bc 100644 --- a/docs/guest-guide/x86/hypercall-abi.rst +++ b/docs/guest-guide/x86/hypercall-abi.rst @@ -109,7 +109,7 @@ abstracting away the details of how it is currently running. Creating Hypercall Pages ------------------------ -Guests which are started using the PV boot protocol may set set +Guests which are started using the PV boot protocol may set ``XEN_ELFNOTE_HYPERCALL_PAGE`` to have the nominated page written as a hypercall page during construction. This mechanism is common for PV guests, and allows hypercalls to be issued with no additional setup. diff --git a/docs/man/xl.conf.5.pod.in b/docs/man/xl.conf.5.pod.in index 44738b80bf..0cfec8587c 100644 --- a/docs/man/xl.conf.5.pod.in +++ b/docs/man/xl.conf.5.pod.in @@ -4,7 +4,7 @@ =head1 DESCRIPTION -The F<xl.conf> file allows configuration of hostwide C<xl> toolstack +The F<xl.conf> file allows configuration of host-wide C<xl> toolstack options. For details of per-domain configuration options please see diff --git a/docs/misc/livepatch.pandoc b/docs/misc/livepatch.pandoc index a94fb57eb5..43010227e5 100644 --- a/docs/misc/livepatch.pandoc +++ b/docs/misc/livepatch.pandoc @@ -2,7 +2,7 @@ ## Rationale -A mechanism is required to binarily patch the running hypervisor with new +A mechanism is required to binary-patch the running hypervisor with new opcodes that have come about due to primarily security updates. This document describes the design of the API that would allow us to
Skimming the docs, I came across a few places for spelling improvements. I checked using dictionaries to be sure. Signed-off-by: Bernhard Kaindl <bernhard.kaindl@cloud.com> --- docs/admin-guide/microcode-loading.rst | 4 ++-- docs/designs/non-cooperative-migration.md | 4 ++-- docs/designs/qemu-deprivilege.md | 2 +- docs/guest-guide/x86/hypercall-abi.rst | 2 +- docs/man/xl.conf.5.pod.in | 2 +- docs/misc/livepatch.pandoc | 2 +- 6 files changed, 8 insertions(+), 8 deletions(-)