motorhead/qemu
1
0
Fork 0
mirror of https://github.com/Motorhead1991/qemu.git synced 2025-08-02 15:23:53 -06:00
Code Issues Projects Releases Packages Wiki Activity Actions

* target/i386: new feature bits for AMD processors

Browse source 
* target/i386/tcg: improvements around flag handling
 * target/i386: add AVX10 support
 * target/i386: add GraniteRapids-v2 model
 * dockerfiles: add libcbor
 * New nitro-enclave machine type
 * qom: cleanups to object_new
 * configure: detect 64-bit MIPS for rust
 * configure: deprecate 32-bit MIPS
 -----BEGIN PGP SIGNATURE-----
 
 iQFIBAABCAAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmcjvkQUHHBib256aW5p
 QHJlZGhhdC5jb20ACgkQv/vSX3jHroPIKgf/etNpO2T+eLFtWN/Qd5eopBXqNd9k
 KmeK9EgW9lqx2IPGNen33O+uKpb/TsMmubSsSF+YxTp7pmkc8+71f3rBMaIAD02r
 /paHSMVw0+f12DAFQz1jdvGihR7Mew0wcF/UdEt737y6vEmPxLTyYG3Gfa4NSZwT
 /V5jTOIcfUN/UEjNgIp6NTuOEESKmlqt22pfMapgkwMlAJYeeJU2X9eGYE86wJbq
 ZSXNgK3jL9wGT2XKa3e+OKzHfFpSkrB0JbQbdico9pefnBokN/hTeeUJ81wBAc7u
 i00W1CEQVJ5lhBc121d4AWMp83ME6HijJUOTMmJbFIONPsITFPHK1CAkng==
 =D4nR
 -----END PGP SIGNATURE-----

Merge tag 'for-upstream-i386' of https://gitlab.com/bonzini/qemu into staging

* target/i386: new feature bits for AMD processors
* target/i386/tcg: improvements around flag handling
* target/i386: add AVX10 support
* target/i386: add GraniteRapids-v2 model
* dockerfiles: add libcbor
* New nitro-enclave machine type
* qom: cleanups to object_new
* configure: detect 64-bit MIPS for rust
* configure: deprecate 32-bit MIPS

# -----BEGIN PGP SIGNATURE-----
#
# iQFIBAABCAAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmcjvkQUHHBib256aW5p
# QHJlZGhhdC5jb20ACgkQv/vSX3jHroPIKgf/etNpO2T+eLFtWN/Qd5eopBXqNd9k
# KmeK9EgW9lqx2IPGNen33O+uKpb/TsMmubSsSF+YxTp7pmkc8+71f3rBMaIAD02r
# /paHSMVw0+f12DAFQz1jdvGihR7Mew0wcF/UdEt737y6vEmPxLTyYG3Gfa4NSZwT
# /V5jTOIcfUN/UEjNgIp6NTuOEESKmlqt22pfMapgkwMlAJYeeJU2X9eGYE86wJbq
# ZSXNgK3jL9wGT2XKa3e+OKzHfFpSkrB0JbQbdico9pefnBokN/hTeeUJ81wBAc7u
# i00W1CEQVJ5lhBc121d4AWMp83ME6HijJUOTMmJbFIONPsITFPHK1CAkng==
# =D4nR
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 31 Oct 2024 17:28:36 GMT
# 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-i386' of https://gitlab.com/bonzini/qemu: (49 commits)
  target/i386: Introduce GraniteRapids-v2 model
  target/i386: Add AVX512 state when AVX10 is supported
  target/i386: Add feature dependencies for AVX10
  target/i386: add CPUID.24 features for AVX10
  target/i386: add AVX10 feature and AVX10 version property
  target/i386: return bool from x86_cpu_filter_features
  target/i386: do not rely on ExtSaveArea for accelerator-supported XCR0 bits
  target/i386: cpu: set correct supported XCR0 features for TCG
  target/i386: use + to put flags together
  target/i386: use higher-precision arithmetic to compute CF
  target/i386: use compiler builtin to compute PF
  target/i386: make flag variables unsigned
  target/i386: add a note about gen_jcc1
  target/i386: add a few more trivial CCPrepare cases
  target/i386: optimize TEST+Jxx sequences
  target/i386: optimize computation of ZF from CC_OP_DYNAMIC
  target/i386: Wrap cc_op_live with a validity check
  target/i386: Introduce cc_op_size
  target/i386: Rearrange CCOp
  target/i386: remove CC_OP_CLR
  ...

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This commit is contained in:
Peter Maydell 2024-11-02 16:21:38 +00:00
commit c94bee4cd6
84 changed files with 4219 additions and 350 deletions
Download patch file Download diff file Expand all files Collapse all files

2
docs/about/build-platforms.rst
View file

@ -41,7 +41,7 @@ Those hosts are officially supported, with various accelerators:
- Accelerators
* - Arm
- kvm (64 bit only), tcg, xen
* - MIPS (little endian only)
* - MIPS (64 bit little endian only)
- kvm, tcg
* - PPC
- kvm, tcg

12
docs/about/deprecated.rst
View file

@ -164,15 +164,19 @@ property types.
Host Architectures
------------------
BE MIPS (since 7.2)
'''''''''''''''''''
Big endian MIPS since 7.2; 32-bit little endian MIPS since 9.2
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
As Debian 10 ("Buster") moved into LTS the big endian 32 bit version of
MIPS moved out of support making it hard to maintain our
cross-compilation CI tests of the architecture. As we no longer have
CI coverage support may bitrot away before the deprecation process
completes. The little endian variants of MIPS (both 32 and 64 bit) are
still a supported host architecture.
completes.
Likewise, the little endian variant of 32 bit MIPS is not supported by
Debian 13 ("Trixie") and newer.
64 bit little endian MIPS is still a supported host architecture.
System emulation on 32-bit x86 hosts (since 8.0)
''''''''''''''''''''''''''''''''''''''''''''''''

78
docs/system/i386/nitro-enclave.rst Normal file
View file

@ -0,0 +1,78 @@
'nitro-enclave' virtual machine (``nitro-enclave``)
===================================================
``nitro-enclave`` is a machine type which emulates an *AWS nitro enclave*
virtual machine. `AWS nitro enclaves`_ is an Amazon EC2 feature that allows
creating isolated execution environments, called enclaves, from Amazon EC2
instances which are used for processing highly sensitive data. Enclaves have
no persistent storage and no external networking. The enclave VMs are based
on Firecracker microvm with a vhost-vsock device for communication with the
parent EC2 instance that spawned it and a Nitro Secure Module (NSM) device
for cryptographic attestation. The parent instance VM always has CID 3 while
the enclave VM gets a dynamic CID. Enclaves use an EIF (`Enclave Image Format`_)
file which contains the necessary kernel, cmdline and ramdisk(s) to boot.
In QEMU, ``nitro-enclave`` is a machine type based on ``microvm`` similar to how
AWS nitro enclaves are based on `Firecracker`_ microvm. This is useful for
local testing of EIF files using QEMU instead of running real AWS Nitro Enclaves
which can be difficult for debugging due to its roots in security. The vsock
device emulation is done using vhost-user-vsock which means another process that
can do the userspace emulation, like `vhost-device-vsock`_ from rust-vmm crate,
must be run alongside nitro-enclave for the vsock communication to work.
``libcbor`` and ``gnutls`` are required dependencies for nitro-enclave machine
support to be added when building QEMU from source.
.. _AWS nitro enclaves: https://docs.aws.amazon.com/enclaves/latest/user/nitro-enclave.html
.. _Enclave Image Format: https://github.com/aws/aws-nitro-enclaves-image-format
.. _vhost-device-vsock: https://github.com/rust-vmm/vhost-device/tree/main/vhost-device-vsock
.. _Firecracker: https://firecracker-microvm.github.io
Using the nitro-enclave machine type
------------------------------------
Machine-specific options
~~~~~~~~~~~~~~~~~~~~~~~~
It supports the following machine-specific options:
- nitro-enclave.vsock=string (required) (Id of the chardev from '-chardev' option that vhost-user-vsock device will use)
- nitro-enclave.id=string (optional) (Set enclave identifier)
- nitro-enclave.parent-role=string (optional) (Set parent instance IAM role ARN)
- nitro-enclave.parent-id=string (optional) (Set parent instance identifier)
Running a nitro-enclave VM
~~~~~~~~~~~~~~~~~~~~~~~~~~
First, run `vhost-device-vsock`__ (or a similar tool that supports vhost-user-vsock).
The forward-cid option below with value 1 forwards all connections from the enclave
VM to the host machine and the forward-listen (port numbers separated by '+') is used
for forwarding connections from the host machine to the enclave VM.
__ https://github.com/rust-vmm/vhost-device/tree/main/vhost-device-vsock#using-the-vsock-backend
$ vhost-device-vsock \
--vm guest-cid=4,forward-cid=1,forward-listen=9001+9002,socket=/tmp/vhost4.socket
Now run the necessary applications on the host machine so that the nitro-enclave VM
applications' vsock communication works. For example, the nitro-enclave VM's init
process connects to CID 3 and sends a single byte hello heartbeat (0xB7) to let the
parent VM know that it booted expecting a heartbeat (0xB7) response. So you must run
a AF_VSOCK server on the host machine that listens on port 9000 and sends the heartbeat
after it receives the heartbeat for enclave VM to boot successfully. You should run all
the applications on the host machine that would typically be running in the parent EC2
VM for successful communication with the enclave VM.
Then run the nitro-enclave VM using the following command where ``hello.eif`` is
an EIF file you would use to spawn a real AWS nitro enclave virtual machine:
$ qemu-system-x86_64 -M nitro-enclave,vsock=c,id=hello-world \
-kernel hello-world.eif -nographic -m 4G --enable-kvm -cpu host \
-chardev socket,id=c,path=/tmp/vhost4.socket
In this example, the nitro-enclave VM has CID 4. If there are applications that
connect to the enclave VM, run them on the host machine after enclave VM starts.
You need to modify the applications to connect to CID 1 (instead of the enclave
VM's CID) and use the forward-listen (e.g., 9001+9002) option of vhost-device-vsock
to forward the ports they connect to.

3
docs/system/target-i386.rst
View file

@ -14,8 +14,9 @@ Board-specific documentation
.. toctree::
:maxdepth: 1
i386/microvm
i386/pc
i386/microvm
i386/nitro-enclave
Architectural features
~~~~~~~~~~~~~~~~~~~~~~