From: Markus Armbruster <armbru@redhat.com>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
qemu-devel@nongnu.org, "Eduardo Habkost" <ehabkost@redhat.com>
Subject: Re: [PATCH v2 02/21] docs: collect the disparate device emulation docs into one section
Date: Thu, 15 Jul 2021 08:10:54 +0200 [thread overview]
Message-ID: <8735sgds41.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20210714182056.25888-3-alex.bennee@linaro.org> ("Alex Bennée"'s message of "Wed, 14 Jul 2021 19:20:37 +0100")
Cc: QOM maintainers for additional eyes.
Alex Bennée <alex.bennee@linaro.org> writes:
> While we are at it add a brief preamble that explains some of the
> common concepts in QEMU's device emulation which will hopefully lead
> to less confusing about our dizzying command line options.
>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> Message-Id: <20210714093638.21077-3-alex.bennee@linaro.org>
> ---
> docs/system/device-emulation.rst | 78 +++++++++++++++++++++++
> docs/system/{ => devices}/ivshmem.rst | 0
> docs/system/{ => devices}/net.rst | 0
> docs/system/{ => devices}/nvme.rst | 0
> docs/system/{ => devices}/usb.rst | 0
> docs/system/{ => devices}/virtio-pmem.rst | 0
> docs/system/index.rst | 6 +-
> 7 files changed, 79 insertions(+), 5 deletions(-)
> create mode 100644 docs/system/device-emulation.rst
> rename docs/system/{ => devices}/ivshmem.rst (100%)
> rename docs/system/{ => devices}/net.rst (100%)
> rename docs/system/{ => devices}/nvme.rst (100%)
> rename docs/system/{ => devices}/usb.rst (100%)
> rename docs/system/{ => devices}/virtio-pmem.rst (100%)
>
> diff --git a/docs/system/device-emulation.rst b/docs/system/device-emulation.rst
> new file mode 100644
> index 0000000000..3156eeac2d
> --- /dev/null
> +++ b/docs/system/device-emulation.rst
> @@ -0,0 +1,78 @@
> +.. _device-emulation:
> +
> +Device Emulation
> +----------------
> +
> +QEMU supports the emulation of a large number of devices from
> +peripherals such network cards and USB devices to integrated systems
> +on a chip (SoCs). Configuration of these is often a source of
> +confusion so it helps to have an understanding of some of the terms
> +used to describes devices within QEMU.
> +
> +Common Terms
> +~~~~~~~~~~~~
> +
> +Device Front End
> +================
> +
> +A device front end is how a device is presented to the guest. The type
> +of device presented should match the hardware that the guest operating
> +system is expecting to see. All devices can be specified with the
> +``--device`` command line option. Running QEMU with the command line
> +options ``--device help`` will list all devices it is aware of. Using
> +the command line ``--device foo,help`` will list the additional
> +configuration options available for that device.
> +
> +A front end is often paired with a back end, which describes how the
> +host's resources are used in the emulation.
> +
> +Device Buses
> +============
> +
> +All devices exist on a BUS. Depending on the machine model you choose
This isn't true anymore; there are bus-less devices. To show the
user-pluggable ones, try
$ qemu-system-FOO -device help | grep -v '", bus'
> +(``-M foo``) a number of buses will have been automatically created.
> +In most cases the BUS a device is attached to can be inferred, for
> +example PCI devices are generally automatically allocated to the next
> +free slot of the PCI bus. However in complicated configurations you
"The PCI bus" tacitly assumes there's just one.
We actually pick the first bus (in qtree pre-order) that can take
another device. Best not to rely on the search order; if you care which
bus to plug into, specify it with bus=ID.
"Next free slot" is about the device address on the bus. Should we
explain the concept "device address on a bus"?
> +can explicitly specify what bus a device is attached to and its
> +address. Some devices, for example a PCI SCSI host controller, will
> +add an additional bus to the system that other devices can be attached
A device can add more than one bus.
> +to.
> +
> +Device Back End
> +===============
> +
> +The back end describes how the data from the emulated device will be
> +processed by QEMU. The configuration of the back end is usually
> +specific to the class of device being emulated. For example serial
> +devices will be backed by a ``--chardev`` which can redirect the data
> +to a file or socket or some other system. Storage devices are handled
> +by ``--blockdev`` which will specify how blocks are handled, for
> +example being stored in a qcow2 file or accessing a raw host disk
> +partition. Back ends can sometimes be stacked to implement features
> +like snapshots.
> +
> +While the choice of back end is generally transparent to the guest
Comma, I think.
> +there are cases where features will not be reported to the guest if
> +the back end is unable to support it.
> +
> +Device Pass Through
> +===================
> +
> +Device pass through is where the device is actually given access to
> +the underlying hardware. This can be as simple as exposing a single
> +USB device on the host system to the guest or dedicating a video card
> +in a PCI slot to the exclusive use of the guest.
Thanks for writing this up!
> +
> +
> +Emulated Devices
> +~~~~~~~~~~~~~~~~
> +
> +.. toctree::
> + :maxdepth: 1
> +
> + devices/ivshmem.rst
> + devices/net.rst
> + devices/nvme.rst
> + devices/usb.rst
> + devices/virtio-pmem.rst
> diff --git a/docs/system/ivshmem.rst b/docs/system/devices/ivshmem.rst
> similarity index 100%
> rename from docs/system/ivshmem.rst
> rename to docs/system/devices/ivshmem.rst
> diff --git a/docs/system/net.rst b/docs/system/devices/net.rst
> similarity index 100%
> rename from docs/system/net.rst
> rename to docs/system/devices/net.rst
> diff --git a/docs/system/nvme.rst b/docs/system/devices/nvme.rst
> similarity index 100%
> rename from docs/system/nvme.rst
> rename to docs/system/devices/nvme.rst
> diff --git a/docs/system/usb.rst b/docs/system/devices/usb.rst
> similarity index 100%
> rename from docs/system/usb.rst
> rename to docs/system/devices/usb.rst
> diff --git a/docs/system/virtio-pmem.rst b/docs/system/devices/virtio-pmem.rst
> similarity index 100%
> rename from docs/system/virtio-pmem.rst
> rename to docs/system/devices/virtio-pmem.rst
> diff --git a/docs/system/index.rst b/docs/system/index.rst
> index 6092eb2d91..641d243ba4 100644
> --- a/docs/system/index.rst
> +++ b/docs/system/index.rst
> @@ -16,15 +16,12 @@ Contents:
>
> quickstart
> invocation
> + device-emulation
> keys
> mux-chardev
> monitor
> images
> - net
> virtio-net-failover
> - usb
> - nvme
> - ivshmem
> linuxboot
> generic-loader
> guest-loader
> @@ -35,7 +32,6 @@ Contents:
> gdb
> managed-startup
> cpu-hotplug
> - virtio-pmem
> pr-manager
> targets
> security
next prev parent reply other threads:[~2021-07-15 6:12 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-14 18:20 [PATCH v2 00/21] documentation and metadata updates Alex Bennée
2021-07-14 18:20 ` [PATCH v2 01/21] gitignore: Update with some filetypes Alex Bennée
2021-07-14 18:20 ` [PATCH v2 02/21] docs: collect the disparate device emulation docs into one section Alex Bennée
2021-07-15 6:10 ` Markus Armbruster [this message]
2021-07-19 8:34 ` Alex Bennée
2021-07-20 13:09 ` Markus Armbruster
2021-07-14 18:20 ` [PATCH v2 03/21] docs: add a section on the generalities of vhost-user Alex Bennée
2021-07-15 10:06 ` Stefan Hajnoczi
2021-07-14 18:20 ` [PATCH v2 04/21] configure: remove needless if leg Alex Bennée
2021-07-16 16:08 ` Richard Henderson
2021-07-14 18:20 ` [PATCH v2 05/21] contrib/gitdm: add some new aliases to fix up commits Alex Bennée
2021-07-16 16:09 ` Richard Henderson
2021-07-14 18:20 ` [PATCH v2 06/21] .mailmap: fix up some broken commit authors Alex Bennée
2021-07-14 18:20 ` [PATCH v2 07/21] contrib/gitdm: add domain-map for MontaVista Alex Bennée
2021-07-14 18:20 ` [PATCH v2 08/21] contrib/gitdm: add a group mapping for robot scanners Alex Bennée
2021-07-14 18:20 ` [PATCH v2 09/21] gitdm.config: sort the corporate GroupMap entries Alex Bennée
2021-07-14 18:20 ` [PATCH v2 10/21] contrib/gitdm: add domain-map/group-map mappings for Samsung Alex Bennée
2021-07-15 5:49 ` Klaus Jensen
2021-07-15 9:06 ` Alex Bennée
2021-07-14 18:20 ` [PATCH v2 11/21] contrib/gitdm: add domain-map for Eldorado Alex Bennée
2021-07-14 18:20 ` [PATCH v2 12/21] contrib/gitdm: add domain-map/group-map for Wind River Alex Bennée
2021-07-14 18:20 ` [PATCH v2 13/21] contrib/gitdm: un-ironically add a mapping for LWN Alex Bennée
2021-07-14 18:20 ` [PATCH v2 14/21] contrib/gitdm: add domain-map for Crudebyte Alex Bennée
2021-07-14 18:20 ` [PATCH v2 15/21] contrib/gitdm: add domain-map for ZTE Alex Bennée
2021-07-14 18:20 ` [PATCH v2 16/21] contrib/gitdm: add domain-map for Syrmia Alex Bennée
2021-07-14 18:20 ` [PATCH v2 17/21] contrib/gitdm: add domain-map for NVIDIA Alex Bennée
2021-07-15 15:01 ` Kirti Wankhede
2021-07-14 18:20 ` [PATCH v2 18/21] contrib/gitdm: add group-map for Netflix Alex Bennée
2021-07-14 18:20 ` [PATCH v2 19/21] contrib/gitdm: add an explicit academic entry for BU Alex Bennée
2021-07-14 18:39 ` Alexander Bulekov
2021-07-14 18:20 ` [PATCH v2 20/21] contrib/gitdm: add a new interns group-map for GSoC/Outreachy work Alex Bennée
2021-07-15 14:31 ` Mahmoud Mandour
2021-07-14 18:20 ` [PATCH v2 21/21] contrib/gitdm: add more individual contributor entries Alex Bennée
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8735sgds41.fsf@dusky.pond.sub.org \
--to=armbru@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=berrange@redhat.com \
--cc=ehabkost@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.