mirror of https://github.com/proxmox/mirror_qemu
docs: Fix some typos (found by codespell)
Fix also a similar typo in a code comment. Signed-off-by: Stefan Weil <sw@weilnetz.de> Message-Id: <20201117193448.393472-1-sw@weilnetz.de> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>master
Stefan Weil
Paolo Bonzini
parent
933c8fe781
commit
ac9574bc87
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -530,7 +530,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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -473,7 +473,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.
|
||||
|
||||
|
|
@ -660,7 +660,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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
Loading…
Reference in New Issue