| /qemu/docs/devel/ |
| H A D | multi-process.rst | 6 This is the design document for multi-process QEMU. It does not
7 necessarily reflect the status of the current implementation, which
10 the goals and general direction of this feature.
12 Please refer to the following wiki for latest details:
15 QEMU is often used as the hypervisor for virtual machines running in the
16 Oracle cloud. Since one of the advantages of cloud computing is the
17 ability to run many VMs from different tenants in the same cloud
19 potentially use the hypervisor's access privileges to access data it is
23 monolithic program that provides many features to the VMs it services.
26 attack. Separating QEMU reduces the attack surface by aiding to
[all …]
|
| H A D | s390-dasd-ipl.rst | 7 The s390 hardware IPL process consists of the following steps.
10 This ccw, by definition, reads the IPL1 record which is located on the disk
11 at cylinder 0 track 0 record 1. Note that the chain flag is on in this ccw
15 2. Execute the Read IPL ccw at ``0x00``, thereby reading IPL1 data into ``0x00``.
16 IPL1 data is 24 bytes in length and consists of the following pieces of
17 information: ``[psw][read ccw][tic ccw]``. When the machine executes the Read
18 IPL ccw it read the 24-bytes of IPL1 to be read into memory starting at
19 location ``0x0``. Then the ccw program at ``0x08`` which consists of a read
20 ccw and a tic ccw is automatically executed because of the chain flag from
21 the original READ IPL ccw. The read ccw will read the IPL2 data into memory
[all …]
|
| H A D | tcg.rst | 8 it converts it to the host instruction set. Usually dynamic translators
16 The following sections outline some notable features and implementation
22 The target CPUs have many internal states which change the way they
23 evaluate instructions. In order to achieve a good speed, the
24 translation phase considers that some state information of the virtual
25 CPU cannot change in it. The state is recorded in the Translation
26 Block (TB). If the state changes (e.g. privilege level), a new TB will
27 be generated and the previous TB won't be used anymore until the state
28 matches the state recorded in the previous TB. The same idea can be applied
29 to other aspects of the CPU state. For example, on x86, if the SS,
[all …]
|
| H A D | build-system.rst | 2 The QEMU build system architecture
5 This document aims to help developers understand the architecture of the
6 QEMU build system. As with projects using GNU autotools, the QEMU build
7 system has two stages; first the developer runs the "configure" script
8 to determine the local build environment characteristics, then they run
9 "make" to build the project. This is about where the similarities with
12 The two general ways to perform a build are as follows:
29 Most of the actual build process uses Meson under the hood, therefore
30 build artifacts cannot be placed in the source tree itself.
36 The configure script has five tasks:
[all …]
|
| /qemu/target/hexagon/idef-parser/ |
| H A D | README.rst | 4 idef-parser is a small compiler able to translate the Hexagon ISA description
10 To better understand the scope of the idef-parser, we'll explore an applicative
11 example. Let's start by one of the simplest Hexagon instruction: the ``add``.
13 The ISA description language represents the ``add`` instruction as
22 idef-parser will compile the above code into the following code:
36 The output of the compilation process will be a function, containing the
37 tinycode generator code, implementing the correct semantics. That function will
38 not access any global variable, because all the accessed data structures will be
39 passed explicitly as function parameters. Among the passed parameters we will
40 have TCGv (tinycode variables) representing the input and output registers of
[all …]
|
| /qemu/docs/interop/ |
| H A D | vhost-user.rst | 10 Licence: This work is licensed under the terms of the GNU GPL,
11 version 2 or later. See the COPYING file in the top-level
19 This protocol is aiming to complement the ``ioctl`` interface used to
20 control the vhost implementation in the Linux kernel. It implements
21 the control plane needed to establish virtqueue sharing with a user
22 space process on the same host. It uses communication over a Unix
23 domain socket to share file descriptors in the ancillary data of the
26 The protocol defines 2 sides of the communication, *front-end* and
27 *back-end*. The *front-end* is the application that shares its virtqueues, in
28 our case QEMU. The *back-end* is the consumer of the virtqueues.
[all …]
|
| H A D | qcow2.rst | 6 (host) clusters. A cluster is the unit in which all allocations are done,
9 Likewise, the virtual disk as seen by the guest is divided into (guest)
10 clusters of the same size.
17 The first cluster of a qcow2 image contains the file header::
26 Offset into the image file at which the backing file name
27 is stored (NB: The string is not null terminated). 0 if the
34 Length of the backing file name in bytes. Must not be
35 longer than 1023 bytes. Undefined if the image doesn't have
40 within a cluster (1 << cluster_bits is the cluster size).
44 as the maximum cluster size and won't be able to open images
[all …]
|
| H A D | parallels.rst | 8 This work is licensed under the terms of the GNU GPL, version 2 or later.
9 See the COPYING file in the top-level directory.
29 A data chunk of the size specified in the image header.
30 Currently, the default size is 1MiB (2048 sectors). In previous
40 The header is placed at the start of an image and contains the following
66 Only the lowest 4 bytes are used. The highest 4 bytes must be
73 Set to 0x746F6E59 when the image is opened by software in R/W
74 mode; set to 0x312e3276 when the image is closed.
76 A zero in this field means that the image was opened by an old
77 version of the software that doesn't support Format Extension
[all …]
|
| H A D | live-block-operations.rst | 4 This work is licensed under the terms of the GNU GPL, version 2 or
5 later. See the COPYING file in the top-level directory.
20 a block device. Below is a description of the said block (QMP)
25 The file ``qapi/block-core.json`` in the QEMU source tree has the
26 canonical QEMU API (QAPI) schema documentation for the QMP
29 .. todo (kashyapc):: Remove the ".. contents::" directive when Sphinx is
49 The arrow can be read as: Image [A] is the backing file of disk image
51 is also referred to as the "active layer".
56 (1) Directional: 'base' and 'top'. Given the simple disk image chain
58 'top'. (This terminology can be seen in the QAPI schema file,
[all …]
|
| /qemu/docs/devel/migration/ |
| H A D | postcopy.rst | 9 the amount of migration traffic and time it takes, the down side is that during
10 the postcopy phase, a failure of *either* side causes the guest to be lost.
12 In postcopy the destination CPUs are started before all the memory has been
14 a fault that's translated by QEMU into a request to the source QEMU.
17 doesn't finish in a given time the switch is made to postcopy.
22 To enable postcopy, issue this command on the monitor (both source and
23 destination) prior to the start of migration:
27 The normal commands are then used to start a migration, which is still
32 will now cause the transition from precopy to postcopy.
34 time later on. Issuing it after the end of a migration is harmless.
[all …]
|
| H A D | main.rst | 7 QEMU has code to load/save the state of the guest that it is running.
8 These are two complementary operations. Saving the state just does
9 that, saves the state for each device that the guest is running.
10 Restoring a guest is just the opposite operation: we need to load the
13 For this to work, QEMU has to be launched with the same arguments the
14 two times. I.e. it can only restore the state in one guest that has
15 the same devices that the one it was saved (this last requirement can
17 to be exactly the same).
24 Next was the "live migration" functionality. This is important
27 migration allows the guest to continue running while the state is
[all …]
|
| /qemu/include/qom/ |
| H A D | object.h | 9 * This work is licensed under the terms of the GNU GPL, version 2 or later.
10 * See the COPYING file in the top-level directory.
35 * @obj: the object that owns the property
36 * @v: the visitor that contains the property data
37 * @name: the name of the property
38 * @opaque: the object property opaque
51 * @obj: the object that owns the property
52 * @opaque: the opaque registered with the property
53 * @part: the name of the property
55 * Resolves the #Object corresponding to property @part.
[all …]
|
| /qemu/docs/specs/ |
| H A D | rapl-msr.rst | 5 The RAPL interface (Running Average Power Limit) is advertising the accumulated
8 The consumption is reported via MSRs (model specific registers) like
9 MSR_PKG_ENERGY_STATUS for the CPU package power domain. These MSRs are 64 bits
10 registers that represent the accumulated energy consumption in micro Joules.
13 not all MSRs are handled by KVM. Some of them can now be handled by the
19 At the moment the following MSRs are involved:
28 The ``*_POWER_UNIT``, ``*_POWER_LIMIT``, ``*_POWER INFO`` are part of the RAPL
29 spec and specify the power limit of the package, provide range of parameter(min
30 power, max power,..) and also the information of the multiplier for the energy
31 counter to calculate the power. Those MSRs are populated once at the beginning
[all …]
|
| H A D | ivshmem-spec.rst | 5 The Inter-VM shared memory device (ivshmem) is designed to share a
7 and the host. In order for all guests to be able to pick up the
9 said memory to the guest as a PCI BAR.
11 The device can use a shared memory object on the host directly, or it
14 In the latter case, the device can additionally interrupt its peers, and
17 For information on configuring the ivshmem device on the QEMU
20 The ivshmem PCI device's guest interface
23 The device has vendor ID 1af4, device ID 1110, revision 1. Before
29 The ivshmem PCI device has two or three BARs:
33 - BAR2 maps the shared memory object
[all …]
|
| H A D | ppc-spapr-numa.rst | 5 NUMA in sPAPR works different than the System Locality Distance
6 Information Table (SLIT) in ACPI. The logic is explained in the LOPAPR
9 of the elements that impacts how QEMU views NUMA in pseries.
16 everyone else outside of the group.
18 The format of the ibm,associativity property varies with the value of
19 bit 0 of byte 5 of the ibm,architecture-vec-5 property. The format with
20 bit 0 equal to zero is deprecated. The current format, with the bit 0
21 with the value of one, makes ibm,associativity property represent the
22 physical hierarchy of the platform, as one or more lists that starts
23 with the highest level grouping up to the smallest. Considering the
[all …]
|
| /qemu/linux-headers/LICENSES/preferred/ |
| H A D | GPL-2.0 | 7 To use this license in source code, put one of the following SPDX
8 tag/value pairs into a comment according to the placement
9 guidelines in the licensing rules documentation.
30 The licenses for most software are designed to take away your
31 freedom to share and change it. By contrast, the GNU General Public
33 software--to make sure the software is free for all its users. This
34 General Public License applies to most of the Free Software
37 the GNU Library General Public License instead.) You can apply it to
42 have the freedom to distribute copies of free software (and charge for
44 if you want it, that you can change the software or use pieces of it
[all …]
|
| /qemu/docs/tools/ |
| H A D | qemu-img.rst | 17 machine or any other process; this may destroy the image. Also, be aware that
40 The following commands are supported:
48 *FMT* is the disk image format. It is guessed automatically in most
49 cases. See below for a description of the supported disk formats.
51 *SIZE* is the disk image size in bytes. Optional suffixes ``k`` or
55 *OUTPUT_FILENAME* is the destination disk image filename.
57 *OUTPUT_FMT* is the destination format.
60 name=value format. Use ``-o help`` for an overview of the options supported
61 by the used format or see the format descriptions below for details.
67 Note the use of a new 'program'; otherwise Sphinx complains about
[all …]
|
| /qemu/ |
| H A D | COPYING | 11 The licenses for most software are designed to take away your
12 freedom to share and change it. By contrast, the GNU General Public
14 software--to make sure the software is free for all its users. This
15 General Public License applies to most of the Free Software
18 the GNU Lesser General Public License instead.) You can apply it to
23 have the freedom to distribute copies of free software (and charge for
25 if you want it, that you can change the software or use pieces of it
29 anyone to deny you these rights or to ask you to surrender the rights.
31 distribute copies of the software, or if you modify it.
34 gratis or for a fee, you must give the recipients all the rights that
[all …]
|
| /qemu/docs/devel/testing/ |
| H A D | functional.rst | 6 The ``tests/functional`` directory hosts functional tests written in
10 The tests should be written in the style of the Python `unittest`_ framework,
11 using stdio for the TAP protocol. The folder ``tests/functional/qemu_test``
12 provides classes (e.g. the ``QemuBaseTest``, ``QemuUserTest`` and the
14 into the right shape, e.g. by replacing the 'stdout' python object to redirect
15 the normal output of your test to stderr instead.
17 Note that if you don't use one of the QemuBaseTest based classes for your
20 prefixing every line with a "# " to mark the output as a TAP comment, or
21 e.g. by capturing the stdout output of subprocesses (redirecting it to
26 * Customize the command line arguments given to the convenience
[all …]
|
| H A D | main.rst | 8 the way to full blown functional tests. To get an overview of the
9 tests you can run ``make check-help`` from either the source or build
13 the meson build system so can be run directly from the build tree,
18 will run just the softfloat tests.
20 An automated test is written with one of the test frameworks using its
21 generic test functions/classes. The test framework can run the tests and
26 1. The test initialization of the parameters, where the expected parameters,
28 2. The call to the code that should be tested;
29 3. An assertion, comparing the result from the previous call with the expected
30 result set during the initialization of the parameters. If the result
[all …]
|
| /qemu/docs/system/s390x/ |
| H A D | vfio-ap.rst | 9 The IBM Adjunct Processor (AP) Cryptographic Facility is comprised
14 On s390x, AP adapter cards are exposed via the AP bus. This document
15 describes how those cards may be made available to KVM guests using the
21 In order understand the terminology used in the rest of this document, let's
28 on the machine model. Adapters assigned to the LPAR in which a linux host is
29 running will be available to the linux host. Each adapter is identified by a
30 number from 0 to 255; however, the maximum adapter number allowed is
38 hold up to 256 domains; however, the maximum domain number allowed is
46 commands sent to a usage domain to control or change the domain; for
47 example, to set a secure private key for the domain.
[all …]
|
| /qemu/include/io/ |
| H A D | channel.h | 7 * modify it under the terms of the GNU Lesser General Public
8 * License as published by the Free Software Foundation; either
9 * version 2.1 of the License, or (at your option) any later version.
11 * This library is distributed in the hope that it will be useful,
12 * but WITHOUT ANY WARRANTY; without even the implied warranty of
13 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
16 * You should have received a copy of the GNU Lesser General Public
67 * The QIOChannel defines the core API for a generic I/O channel
68 * class hierarchy. It is inspired by GIOChannel, but has the
73 * - None of the character set translation, binary data exclusively
[all …]
|
| /qemu/docs/ |
| H A D | rdma.txt | 10 linked on the QEMU wiki above.
29 of the significantly lower latency and higher throughput over TCP/IP. This is
30 because the RDMA I/O architecture reduces the number of interrupts and
31 data copies by bypassing the host networking stack. In particular, a TCP-based
33 unpredictable amount of time to complete the migration if the amount of
35 with the rate of dirty memory produced by the workload.
40 the use of the OpenFabrics OFED software stack that abstracts out the
41 programming model irrespective of the underlying hardware.
44 an understanding on how to verify that you have the OFED software stack
46 against the "librdmacm" and "libibverbs" libraries and development headers
[all …]
|
| H A D | qcow2-cache.txt | 6 This work is licensed under the terms of the GNU GPL, version 2 or
7 later. See the COPYING file in the top-level directory.
11 The QEMU qcow2 driver has two caches that can improve the I/O
12 performance significantly. However, setting the right cache sizes is
15 This document attempts to give an overview of the L2 and refcount
18 Please refer to the docs/interop/qcow2.rst file for an in-depth
19 technical description of the qcow2 file format.
26 The cluster size is configurable, but it must be a power of two and
30 The 'qemu-img create' command supports specifying the size using the
36 The L2 tables
[all …]
|
| /qemu/linux-headers/linux/ |
| H A D | vfio.h | 9 * it under the terms of the GNU General Public License version 2 as
10 * published by the Free Software Foundation.
43 * The No-IOMMU IOMMU offers no translation or isolation for devices and
45 * code will taint the host kernel and should be used with extreme caution.
53 * Supports the vaddr flag for DMA map and unmap. Not supported for mediated
60 * The IOCTL interface is designed for extensibility by embedding the
62 * kernel and userspace. We therefore use the _IO() macro for these
63 * defines to avoid implicitly embedding a size into the ioctl request.
66 * It's *always* the caller's responsibility to indicate the size of
67 * the structure passed by setting argsz appropriately.
[all …]
|