github/acrn-hypervisor
1
0
Fork 0
mirror of https://github.com/projectacrn/acrn-hypervisor.git synced 2025-09-23 01:37:44 +00:00
Code Issues Projects Releases Wiki Activity

doc: update inclusive language terms in docs

Browse Source 
Replace white/black master/slave terms with alternatives.  We're not
changing "master" when used in the context of GitHub branches.  GitHub
advises they have a plan to help this transition.  In the text body we
rever to the "master" branch as the "main" branch, but leave any urls or
code-block commands still using "master".

Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
This commit is contained in:
David B. Kinder
2020-08-31 15:40:08 -07:00
committed by David Kinder
parent 6ddf793f16
commit fc1fc0eb8d
9 changed files with 35 additions and 34 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
doc/developer-guides/hld/hv-ioc-virt.rst
View File

@@ -23,7 +23,7 @@ user OS can directly reuse native CBC driver.
The IOC Mediator has several virtualization requirements, such as S3/S5
wakeup reason emulation, CBC link frame packing/unpacking, signal
whitelist, and RTC configuration.
passlist, and RTC configuration.
IOC Mediator Design
*******************
@@ -111,7 +111,7 @@ DM communicates with several native CBC char devices and a PTY device.
The native CBC char devices only include ``/dev/cbc-lifecycle``,
``/dev/cbc-signals``, and ``/dev/cbc-raw0`` - ``/dev/cbc-raw11``. Others
are not used by the IOC DM. IOC DM opens the ``/dev/ptmx`` device to
create a pair of devices (master and slave), The IOC DM uses these
create a pair of devices (primary and secondary), The IOC DM uses these
devices to communicate with UART DM since UART DM needs a TTY capable
device as its backend.
@@ -150,7 +150,7 @@ char devices and UART DM immediately.
receives service data from native CBC char devices such as
``/dev/cbc-lifecycle``. If service data is CBC wakeup reason, some wakeup
reason bits will be masked. If service data is CBC signal, the data
will be dropped and will not be defined in the whitelist. If service
will be dropped and will not be defined in the passlist. If service
data comes from a raw channel, the data will be passed forward. Before
transmitting to the virtual UART interface, all data needs to be
packed with an address header and link header.
@@ -562,22 +562,22 @@ IOC signal type definitions are as below.
- The IOC backend needs to emulate the channel open/reset/close message which
shouldn't be forward to the native cbc signal channel. The Service VM signal
related services should do a real open/reset/close signal channel.
- Every backend should maintain a whitelist for different VMs. The
whitelist can be stored in the Service VM file system (Read only) in the
- Every backend should maintain a passlist for different VMs. The
passlist can be stored in the Service VM file system (Read only) in the
future, but currently it is hard coded.
IOC mediator has two whitelist tables, one is used for rx
IOC mediator has two passlist tables, one is used for rx
signals(SOC->IOC), and the other one is used for tx signals. The IOC
mediator drops the single signals and group signals if the signals are
not defined in the whitelist. For multi signal, IOC mediator generates a
new multi signal, which contains the signals in the whitelist.
not defined in the passlist. For multi signal, IOC mediator generates a
new multi signal, which contains the signals in the passlist.
.. figure:: images/ioc-image3.png
:width: 600px
:align: center
:name: ioc-med-multi-signal
IOC Mediator - Multi-Signal whitelist
IOC Mediator - Multi-Signal passlist
Raw data
--------

6
doc/developer-guides/hld/ivshmem-hld.rst
View File

@@ -236,10 +236,10 @@ architecture and threat model for your application.
- References: `NIST Crypto Standards and Guidelines <https://csrc.nist.gov/projects/cryptographic-standards-and-guidelines>`_, `OpenSSL <https://www.openssl.org/>`_
4. **Applications Whitelisting**
4. **Applications Passlisting**
- For use cases implemented in static environments (for example, Industrial and Automotive usages), follow application whitelist techniques and disable any third-party or native app stores.
- This mechanism can be chained with the access control policies to protect access to whitelisting rules and configuration files (refer to opensource or implement your custom solution).
- For use cases implemented in static environments (for example, Industrial and Automotive usages), follow application approval techniques and disable any third-party or native app stores.
- This mechanism can be chained with the access control policies to protect access to passlisting rules and configuration files (refer to opensource or implement your custom solution).
- References: `NIST SP800-167 <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-167.pdf>`_, `fapolicyd <https://github.com/linux-application-whitelisting/fapolicyd>`_

18
doc/developer-guides/hld/virtio-i2c.rst
View File

@@ -4,10 +4,10 @@ Virtio-i2c
##########
Virtio-i2c provides a virtual I2C adapter that supports mapping multiple
slave devices under multiple native I2C adapters to one virtio I2C
adapter. The address for the slave device is not changed. Virtio-i2c
also provides an interface to add an acpi node for slave devices so that
the slave device driver in the guest OS does not need to change.
secondary devices under multiple native I2C adapters to one virtio I2C
adapter. The address for the secondary device is not changed. Virtio-i2c
also provides an interface to add an acpi node for secondary devices so that
the secondary device driver in the guest OS does not need to change.
:numref:`virtio-i2c-1` below shows the virtio-i2c architecture.
@@ -46,13 +46,13 @@ notifies the frontend. The msg process flow is shown in
Message Process Flow
**Usage:**
-s <slot>,virtio-i2c,<bus>[:<slave_addr>[@<node>]][:<slave_addr>[@<node>]][,<bus>[:<slave_addr>[@<node>]][:<slave_addr>][@<node>]]
-s <slot>,virtio-i2c,<bus>[:<secondary_addr>[@<node>]][:<secondary_addr>[@<node>]][,<bus>[:<secondary_addr>[@<node>]][:<secondary_addr>][@<node>]]
bus:
The bus number for the native I2C adapter; ``2`` means ``/dev/i2c-2``.
slave_addr:
The address for the native slave devices such as ``1C``, ``2F`` ...
secondary_addr:
The address for the native secondary devices such as ``1C``, ``2F`` ...
@:
The prefix for the acpi node.
@@ -68,7 +68,7 @@ notifies the frontend. The msg process flow is shown in
-s 19,virtio-i2c,0:70@cam1:2F,4:1C
This adds slave devices 0x70 and 0x2F under the native adapter
This adds secondary devices 0x70 and 0x2F under the native adapter
/dev/i2c-0, and 0x1C under /dev/i2c-6 to the virtio-i2c adapter. Since
0x70 includes '@cam1', acpi info is also added to it. Since 0x2F and
0x1C have '@<node>', no acpi info is added to them.
@@ -93,7 +93,7 @@ a virtual I2C adapter will appear in the guest OS:
i2c-0 i2c i915 gmbus dpb I2C adapter
i2c-5 i2c DPDDC-C I2C adapter
You can find the slave device 0x1C under the virtio I2C adapter i2c-6:
You can find the secondary device 0x1C under the virtio I2C adapter i2c-6:
.. code-block:: none