mirror of
https://github.com/Motorhead1991/qemu.git
synced 2025-08-02 23:33:54 -06:00
* first commit for Rust support
* add CI job using Fedora + Rust nightly * fix detection of ATOMIC128 on x86_64 * fix compilation with Sphinx 8.1.0 -----BEGIN PGP SIGNATURE----- iQFIBAABCAAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmcJEKUUHHBib256aW5p QHJlZGhhdC5jb20ACgkQv/vSX3jHroOSZQf+LlvZm9npHR6lZ9DEruhu/uf0c1gO 9+dBJiKQ1OWopSQOqEgOsLL0J123Ls4V8O3tzZwIDuuRofCB2+wKswad6CHoydJx 4p9rRXv6MLlnTqqGxemm/dPZqJ7+6L0poHoDKW+s7AgfVDshhj1RSbQfs8Ujh41F f1sdi3DzopVWtK4CE+8/UeLy5Cxlixke9SKhYQrFHrdsANARP81gxQjczKApMc1z v9qkrLtkM06VUyuvbPps7CHSHDpzx9mXcmkkPgLqLX9MfbCztzi44aVSaS9HYk5G y54dSKdY7VJEuGhG916G+GMDJyow4nhT9Gk6tWtk63TQN5nExVsoZMOmdw== =PFGL -----END PGP SIGNATURE----- Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into staging * first commit for Rust support * add CI job using Fedora + Rust nightly * fix detection of ATOMIC128 on x86_64 * fix compilation with Sphinx 8.1.0 # -----BEGIN PGP SIGNATURE----- # # iQFIBAABCAAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmcJEKUUHHBib256aW5p # QHJlZGhhdC5jb20ACgkQv/vSX3jHroOSZQf+LlvZm9npHR6lZ9DEruhu/uf0c1gO # 9+dBJiKQ1OWopSQOqEgOsLL0J123Ls4V8O3tzZwIDuuRofCB2+wKswad6CHoydJx # 4p9rRXv6MLlnTqqGxemm/dPZqJ7+6L0poHoDKW+s7AgfVDshhj1RSbQfs8Ujh41F # f1sdi3DzopVWtK4CE+8/UeLy5Cxlixke9SKhYQrFHrdsANARP81gxQjczKApMc1z # v9qkrLtkM06VUyuvbPps7CHSHDpzx9mXcmkkPgLqLX9MfbCztzi44aVSaS9HYk5G # y54dSKdY7VJEuGhG916G+GMDJyow4nhT9Gk6tWtk63TQN5nExVsoZMOmdw== # =PFGL # -----END PGP SIGNATURE----- # gpg: Signature made Fri 11 Oct 2024 12:48:53 BST # gpg: using RSA key F13338574B662389866C7682BFFBD25F78C7AE83 # gpg: issuer "pbonzini@redhat.com" # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full] # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" [full] # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * tag 'for-upstream' of https://gitlab.com/bonzini/qemu: docs: use consistent markup for footnotes docs: avoid footnotes consisting of just URLs docs: fix invalid footnote syntax gitlab-ci: add Rust-enabled CI job dockerfiles: add a Dockerfile using a nightly Rust toolchain meson: ensure -mcx16 is passed when detecting ATOMIC128 meson: define qemu_isa_flags meson: fix machine option for x86_version rust: add PL011 device model rust: add utility procedural macro crate scripts/archive-source: find directory name for subprojects rust: add crate to expose bindings and interfaces meson.build: add HAVE_GLIB_WITH_ALIGNED_ALLOC flag .gitattributes: add Rust diff and merge attributes rust: add bindgen step as a meson dependency configure, meson: detect Rust toolchain build-sys: Add rust feature option Require meson version 1.5.0 Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This commit is contained in:
Peter Maydell
commit
b38d263bca
88 changed files with 3474 additions and 75 deletions
|
|
@ -204,7 +204,7 @@ They come in six kinds:
|
|||
before the second with respect to the other components of the system.
|
||||
Therefore, unlike ``smp_rmb()`` or ``qatomic_load_acquire()``,
|
||||
``smp_read_barrier_depends()`` can be just a compiler barrier on
|
||||
weakly-ordered architectures such as Arm or PPC[#]_.
|
||||
weakly-ordered architectures such as Arm or PPC\ [#alpha]_.
|
||||
|
||||
Note that the first load really has to have a _data_ dependency and not
|
||||
a control dependency. If the address for the second load is dependent
|
||||
|
|
@ -212,7 +212,7 @@ They come in six kinds:
|
|||
than actually loading the address itself, then it's a _control_
|
||||
dependency and a full read barrier or better is required.
|
||||
|
||||
.. [#] The DEC Alpha is an exception, because ``smp_read_barrier_depends()``
|
||||
.. [#alpha] The DEC Alpha is an exception, because ``smp_read_barrier_depends()``
|
||||
needs a processor barrier. On strongly-ordered architectures such
|
||||
as x86 or s390, ``smp_rmb()`` and ``qatomic_load_acquire()`` can
|
||||
also be compiler barriers only.
|
||||
|
|
@ -295,7 +295,7 @@ Acquire/release pairing and the *synchronizes-with* relation
|
|||
------------------------------------------------------------
|
||||
|
||||
Atomic operations other than ``qatomic_set()`` and ``qatomic_read()`` have
|
||||
either *acquire* or *release* semantics [#rmw]_. This has two effects:
|
||||
either *acquire* or *release* semantics\ [#rmw]_. This has two effects:
|
||||
|
||||
.. [#rmw] Read-modify-write operations can have both---acquire applies to the
|
||||
read part, and release to the write.
|
||||
|
|
|
|||
|
|
@ -145,13 +145,13 @@ was installed in the ``site-packages`` directory of another interpreter,
|
|||
or with the wrong ``pip`` program.
|
||||
|
||||
If a package is available for the chosen interpreter, ``configure``
|
||||
prepares a small script that invokes it from the venv itself[#distlib]_.
|
||||
prepares a small script that invokes it from the venv itself\ [#distlib]_.
|
||||
If not, ``configure`` can also optionally install dependencies in the
|
||||
virtual environment with ``pip``, either from wheels in ``python/wheels``
|
||||
or by downloading the package with PyPI. Downloading can be disabled with
|
||||
``--disable-download``; and anyway, it only happens when a ``configure``
|
||||
option (currently, only ``--enable-docs``) is explicitly enabled but
|
||||
the dependencies are not present[#pip]_.
|
||||
the dependencies are not present\ [#pip]_.
|
||||
|
||||
.. [#distlib] The scripts are created based on the package's metadata,
|
||||
specifically the ``console_script`` entry points. This is the
|
||||
|
|
@ -333,7 +333,7 @@ into each emulator:
|
|||
|
||||
``default-configs/targets/*.mak``
|
||||
These files mostly define symbols that appear in the ``*-config-target.h``
|
||||
file for each emulator [#cfgtarget]_. However, the ``TARGET_ARCH``
|
||||
file for each emulator\ [#cfgtarget]_. However, the ``TARGET_ARCH``
|
||||
and ``TARGET_BASE_ARCH`` will also be used to select the ``hw/`` and
|
||||
``target/`` subdirectories that are compiled into each target.
|
||||
|
||||
|
|
|
|||
|
|
@ -95,7 +95,7 @@ guest CPU state in case of a guest CPU exception. This is passed
|
|||
to ``cpu_restore_state()``. Therefore the value should either be 0,
|
||||
to indicate that the guest CPU state is already synchronized, or
|
||||
the result of ``GETPC()`` from the top level ``HELPER(foo)``
|
||||
function, which is a return address into the generated code [#gpc]_.
|
||||
function, which is a return address into the generated code\ [#gpc]_.
|
||||
|
||||
.. [#gpc] Note that ``GETPC()`` should be used with great care: calling
|
||||
it in other functions that are *not* the top level
|
||||
|
|
|
|||
|
|
@ -99,9 +99,9 @@ members of the QEMU community, you should make arrangements to attend
|
|||
a `KeySigningParty <https://wiki.qemu.org/KeySigningParty>`__ (for
|
||||
example at KVM Forum) or make alternative arrangements to have your
|
||||
key signed by an attendee. Key signing requires meeting another
|
||||
community member **in person** [#]_ so please make appropriate
|
||||
community member **in person**\ [#2020]_ so please make appropriate
|
||||
arrangements.
|
||||
|
||||
.. [#] In recent pandemic times we have had to exercise some
|
||||
.. [#2020] In recent pandemic times we have had to exercise some
|
||||
flexibility here. Maintainers still need to sign their pull
|
||||
requests though.
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ Use-cases
|
|||
|
||||
The mapped-ram feature was designed for use cases where the migration
|
||||
stream will be directed to a file in the filesystem and not
|
||||
immediately restored on the destination VM [#]_. These could be
|
||||
immediately restored on the destination VM\ [#alternatives]_. These could be
|
||||
thought of as snapshots. We can further categorize them into live and
|
||||
non-live.
|
||||
|
||||
|
|
@ -70,7 +70,7 @@ mapped-ram in this scenario is portability since background-snapshot
|
|||
depends on async dirty tracking (KVM_GET_DIRTY_LOG) which is not
|
||||
supported outside of Linux.
|
||||
|
||||
.. [#] While this same effect could be obtained with the usage of
|
||||
.. [#alternatives] While this same effect could be obtained with the usage of
|
||||
snapshots or the ``file:`` migration alone, mapped-ram provides
|
||||
a performance increase for VMs with larger RAM sizes (10s to
|
||||
100s of GiBs), specially if the VM has been stopped beforehand.
|
||||
|
|
|
|||
|
|
@ -30,15 +30,20 @@ OS modules are generally written using low level languages such as C and
|
|||
low level assembly machine language. Writing test routines in a low level
|
||||
language makes things more cumbersome. These and other reasons makes using
|
||||
bios-bits very attractive for testing bioses. More details on the inspiration
|
||||
for developing biosbits and its real life uses can be found in [#a]_ and [#b]_.
|
||||
for developing biosbits and its real life uses were presented `at Plumbers
|
||||
in 2011 <Plumbers_>`__ and `at Linux.conf.au in 2012 <Linux.conf.au_>`__.
|
||||
|
||||
For QEMU, we maintain a fork of bios bits in gitlab along with all the
|
||||
dependent submodules `here <https://gitlab.com/qemu-project/biosbits-bits>`__.
|
||||
This fork contains numerous fixes, a newer acpica and changes specific to
|
||||
running these functional QEMU tests using bits. The author of this document
|
||||
is the sole maintainer of the QEMU fork of bios bits repository. For more
|
||||
information, please see author's `FOSDEM talk on this bios-bits based test
|
||||
framework <https://fosdem.org/2024/schedule/event/fosdem-2024-2262-exercising-qemu-generated-acpi-smbios-tables-using-biosbits-from-within-a-guest-vm-/>`__.
|
||||
For QEMU, we maintain a fork of bios bits in `gitlab`_, along with all
|
||||
the dependent submodules. This fork contains numerous fixes, a newer
|
||||
acpica and changes specific to running these functional QEMU tests using
|
||||
bits. The author of this document is the current maintainer of the QEMU
|
||||
fork of bios bits repository. For more information, please see `the
|
||||
author's FOSDEM presentation <FOSDEM_>`__ on this bios-bits based test framework.
|
||||
|
||||
.. _Plumbers: https://blog.linuxplumbersconf.org/2011/ocw/system/presentations/867/original/bits.pdf
|
||||
.. _Linux.conf.au: https://www.youtube.com/watch?v=36QIepyUuhg
|
||||
.. _gitlab: https://gitlab.com/qemu-project/biosbits-bits
|
||||
.. _FOSDEM: https://fosdem.org/2024/schedule/event/fosdem-2024-2262-exercising-qemu-generated-acpi-smbios-tables-using-biosbits-from-within-a-guest-vm-/
|
||||
|
||||
*********************************
|
||||
Description of the test framework
|
||||
|
|
@ -148,8 +153,3 @@ Under ``tests/functional/`` as the root we have:
|
|||
|
||||
Author: Ani Sinha <anisinha@redhat.com>
|
||||
|
||||
References:
|
||||
-----------
|
||||
.. [#a] https://blog.linuxplumbersconf.org/2011/ocw/system/presentations/867/original/bits.pdf
|
||||
.. [#b] https://www.youtube.com/watch?v=36QIepyUuhg
|
||||
.. [#c] https://fosdem.org/2024/schedule/event/fosdem-2024-2262-exercising-qemu-generated-acpi-smbios-tables-using-biosbits-from-within-a-guest-vm-/
|
||||
|
|
|
|||
|
|
@ -54,11 +54,11 @@ Data Register
|
|||
-------------
|
||||
|
||||
* Read/Write (writes ignored as of QEMU v2.4, but see the DMA interface)
|
||||
* Location: platform dependent (IOport [#]_ or MMIO)
|
||||
* Location: platform dependent (IOport\ [#placement]_ or MMIO)
|
||||
* Width: 8-bit (if IOport), 8/16/32/64-bit (if MMIO)
|
||||
* Endianness: string-preserving
|
||||
|
||||
.. [#]
|
||||
.. [#placement]
|
||||
On platforms where the data register is exposed as an IOport, its
|
||||
port number will always be one greater than the port number of the
|
||||
selector register. In other words, the two ports overlap, and can not
|
||||
|
|
|
|||
|
|
@ -9,11 +9,12 @@ The consumption is reported via MSRs (model specific registers) like
|
|||
MSR_PKG_ENERGY_STATUS for the CPU package power domain. These MSRs are 64 bits
|
||||
registers that represent the accumulated energy consumption in micro Joules.
|
||||
|
||||
Thanks to the MSR Filtering patch [#a]_ not all MSRs are handled by KVM. Some
|
||||
of them can now be handled by the userspace (QEMU). It uses a mechanism called
|
||||
"MSR filtering" where a list of MSRs is given at init time of a VM to KVM so
|
||||
that a callback is put in place. The design of this patch uses only this
|
||||
mechanism for handling the MSRs between guest/host.
|
||||
Thanks to KVM's `MSR filtering <msr-filter-patch_>`__ functionality,
|
||||
not all MSRs are handled by KVM. Some of them can now be handled by the
|
||||
userspace (QEMU); a list of MSRs is given at VM creation time to KVM, and
|
||||
a userspace exit occurs when they are accessed.
|
||||
|
||||
.. _msr-filter-patch: https://patchwork.kernel.org/project/kvm/patch/20200916202951.23760-7-graf@amazon.com/
|
||||
|
||||
At the moment the following MSRs are involved:
|
||||
|
||||
|
|
@ -92,9 +93,12 @@ found by the sysconf system call. A typical value of clock ticks per second is
|
|||
package has 4 cores, 400 ticks maximum can be scheduled on all the cores
|
||||
of the package for a period of 1 second.
|
||||
|
||||
The /proc/[pid]/stat [#b]_ is a sysfs file that can give the executed time of a
|
||||
process with the [pid] as the process ID. It gives the amount of ticks the
|
||||
process has been scheduled in userspace (utime) and kernel space (stime).
|
||||
`/proc/[pid]/stat <stat_>`__ is a procfs file that can give the executed
|
||||
time of a process with the [pid] as the process ID. It gives the amount
|
||||
of ticks the process has been scheduled in userspace (utime) and kernel
|
||||
space (stime).
|
||||
|
||||
.. _stat: https://man7.org/linux/man-pages/man5/proc.5.html
|
||||
|
||||
By reading those metrics for a thread, one can calculate the ratio of time the
|
||||
package has spent executing the thread.
|
||||
|
|
@ -148,8 +152,3 @@ Current Limitations
|
|||
- Only the Package Power-Plane (MSR_PKG_ENERGY_STATUS) is reported at the
|
||||
moment.
|
||||
|
||||
References
|
||||
----------
|
||||
|
||||
.. [#a] https://patchwork.kernel.org/project/kvm/patch/20200916202951.23760-7-graf@amazon.com/
|
||||
.. [#b] https://man7.org/linux/man-pages/man5/proc.5.html
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue