On Tue, Nov 17, 2020 at 08:34:48PM +0100, Stefan Weil wrote: > Fix also a similar typo in a code comment. > > Signed-off-by: Stefan Weil <sw@xxxxxxxxxxx> Reviewed-by: Michael S. Tsirkin <mst@xxxxxxxxxx> > --- > docs/can.txt | 8 ++++---- > docs/interop/vhost-user.rst | 2 +- > docs/replay.txt | 2 +- > docs/specs/ppc-spapr-numa.rst | 2 +- > docs/system/deprecated.rst | 4 ++-- > docs/tools/virtiofsd.rst | 2 +- > hw/vfio/igd.c | 2 +- > 7 files changed, 11 insertions(+), 11 deletions(-) > > diff --git a/docs/can.txt b/docs/can.txt > index 5838f6620c..0d310237df 100644 > --- a/docs/can.txt > +++ b/docs/can.txt > @@ -19,7 +19,7 @@ interface to implement because such device can be easily connected > to systems with different CPU architectures (x86, PowerPC, Arm, etc.). > > In 2020, CTU CAN FD controller model has been added as part > -of the bachelor theses of Jan Charvat. This controller is complete > +of the bachelor thesis of Jan Charvat. This controller is complete > open-source/design/hardware solution. The core designer > of the project is Ondrej Ille, the financial support has been > provided by CTU, and more companies including Volkswagen subsidiaries. > @@ -31,7 +31,7 @@ testing lead to goal change to provide environment which provides complete > emulated environment for testing and RTEMS GSoC slot has been donated > to work on CAN hardware emulation on QEMU. > > -Examples how to use CAN emulation for SJA1000 based borads > +Examples how to use CAN emulation for SJA1000 based boards > ========================================================== > > When QEMU with CAN PCI support is compiled then one of the next > @@ -106,8 +106,8 @@ This open-source core provides CAN FD support. CAN FD drames are > delivered even to the host systems when SocketCAN interface is found > CAN FD capable. > > -The PCIe borad emulation is provided for now (the device identifier is > -ctucan_pci). The defauld build defines two CTU CAN FD cores > +The PCIe board emulation is provided for now (the device identifier is > +ctucan_pci). The default build defines two CTU CAN FD cores > on the board. > > Example how to connect the canbus0-bus (virtual wire) to the host > diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst > index 988f154144..72b2e8c7ba 100644 > --- a/docs/interop/vhost-user.rst > +++ b/docs/interop/vhost-user.rst > @@ -513,7 +513,7 @@ descriptor table (split virtqueue) or descriptor ring (packed > virtqueue). However, it can't work when we process descriptors > out-of-order because some entries which store the information of > inflight descriptors in available ring (split virtqueue) or descriptor > -ring (packed virtqueue) might be overrided by new entries. To solve > +ring (packed virtqueue) might be overridden by new entries. To solve > this problem, slave need to allocate an extra buffer to store this > information of inflight descriptors and share it with master for > persistent. ``VHOST_USER_GET_INFLIGHT_FD`` and > diff --git a/docs/replay.txt b/docs/replay.txt > index 87a64ae068..5b008ca491 100644 > --- a/docs/replay.txt > +++ b/docs/replay.txt > @@ -328,7 +328,7 @@ between the snapshots. Each of the passes include the following steps: > 1. loading the snapshot > 2. replaying to examine the breakpoints > 3. if breakpoint or watchpoint was met > - - loading the snaphot again > + - loading the snapshot again > - replaying to the required breakpoint > 4. else > - proceeding to the p.1 with the earlier snapshot > diff --git a/docs/specs/ppc-spapr-numa.rst b/docs/specs/ppc-spapr-numa.rst > index 5fca2bdd8e..ffa687dc89 100644 > --- a/docs/specs/ppc-spapr-numa.rst > +++ b/docs/specs/ppc-spapr-numa.rst > @@ -198,7 +198,7 @@ This is how it is being done: > * user distance 121 and beyond will be interpreted as 160 > * user distance 10 stays 10 > > -The reasoning behind this aproximation is to avoid any round up to the local > +The reasoning behind this approximation is to avoid any round up to the local > distance (10), keeping it exclusive to the 4th NUMA level (which is still > exclusive to the node_id). All other ranges were chosen under the developer > discretion of what would be (somewhat) sensible considering the user input. > diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst > index 32a0e620db..63e9db1463 100644 > --- a/docs/system/deprecated.rst > +++ b/docs/system/deprecated.rst > @@ -465,7 +465,7 @@ default configuration. > > The CPU model runnability guarantee won't apply anymore to > existing CPU models. Management software that needs runnability > -guarantees must resolve the CPU model aliases using te > +guarantees must resolve the CPU model aliases using the > ``alias-of`` field returned by the ``query-cpu-definitions`` QMP > command. > > @@ -637,7 +637,7 @@ Splitting RAM by default between NUMA nodes had the same issues as ``mem`` > parameter with the difference that the role of the user plays QEMU using > implicit generic or board specific splitting rule. > Use ``memdev`` with *memory-backend-ram* backend or ``mem`` (if > -it's supported by used machine type) to define mapping explictly instead. > +it's supported by used machine type) to define mapping explicitly instead. > Users of existing VMs, wishing to preserve the same RAM distribution, should > configure it explicitly using ``-numa node,memdev`` options. Current RAM > distribution can be retrieved using HMP command ``info numa`` and if separate > diff --git a/docs/tools/virtiofsd.rst b/docs/tools/virtiofsd.rst > index 34a9e40146..866b7db3ee 100644 > --- a/docs/tools/virtiofsd.rst > +++ b/docs/tools/virtiofsd.rst > @@ -174,7 +174,7 @@ Using ':' as the separator a rule is of the form: > - 'bad' - If a client tries to use a name matching 'key' it's > denied using EPERM; when the server passes an attribute > name matching 'prepend' it's hidden. In many ways it's use is very like > - 'ok' as either an explict terminator or for special handling of certain > + 'ok' as either an explicit terminator or for special handling of certain > patterns. > > **key** is a string tested as a prefix on an attribute name originating > diff --git a/hw/vfio/igd.c b/hw/vfio/igd.c > index 64e332746b..470205f487 100644 > --- a/hw/vfio/igd.c > +++ b/hw/vfio/igd.c > @@ -535,7 +535,7 @@ void vfio_probe_igd_bar4_quirk(VFIOPCIDevice *vdev, int nr) > } > > /* > - * Assume we have no GMS memory, but allow it to be overrided by device > + * Assume we have no GMS memory, but allow it to be overridden by device > * option (experimental). The spec doesn't actually allow zero GMS when > * when IVD (IGD VGA Disable) is clear, but the claim is that it's unused, > * so let's not waste VM memory for it. > -- > 2.29.2
