mirror of
https://github.com/Motorhead1991/qemu.git
synced 2026-01-27 19:30:38 -07:00
virtio,pci,pc: features,fixes
pci: Initial support for SPDM Responders
cxl: Add support for scan media, feature commands, device patrol scrub
control, DDR5 ECS control, firmware updates
virtio: in-order support
virtio-net: support for SR-IOV emulation (note: known issues on s390,
might get reverted if not fixed)
smbios: memory device size is now configurable per Machine
cpu: architecture agnostic code to support vCPU Hotplug
Fixes, cleanups all over the place.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
-----BEGIN PGP SIGNATURE-----
iQFDBAABCAAtFiEEXQn9CHHI+FuUyooNKB8NuNKNVGkFAmae9l8PHG1zdEByZWRo
YXQuY29tAAoJECgfDbjSjVRp8fYH/impBH9nViO/WK48io4mLSkl0EUL8Y/xrMvH
zKFCKaXq8D96VTt1Z4EGKYgwG0voBKZaCEKYU/0ARGnSlSwxINQ8ROCnBWMfn2sx
yQt08EXVMznNLtXjc6U5zCoCi6SaV85GH40No3MUFXBQt29ZSlFqO/fuHGZHYBwS
wuVKvTjjNF4EsGt3rS4Qsv6BwZWMM+dE6yXpKWk68kR8IGp+6QGxkMbWt9uEX2Md
VuemKVnFYw0XGCGy5K+ZkvoA2DGpEw0QxVSOMs8CI55Oc9SkTKz5fUSzXXGo1if+
M1CTjOPJu6pMym6gy6XpFa8/QioDA/jE2vBQvfJ64TwhJDV159s=
=k8e9
-----END PGP SIGNATURE-----
Merge tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu into staging
virtio,pci,pc: features,fixes
pci: Initial support for SPDM Responders
cxl: Add support for scan media, feature commands, device patrol scrub
control, DDR5 ECS control, firmware updates
virtio: in-order support
virtio-net: support for SR-IOV emulation (note: known issues on s390,
might get reverted if not fixed)
smbios: memory device size is now configurable per Machine
cpu: architecture agnostic code to support vCPU Hotplug
Fixes, cleanups all over the place.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
# -----BEGIN PGP SIGNATURE-----
#
# iQFDBAABCAAtFiEEXQn9CHHI+FuUyooNKB8NuNKNVGkFAmae9l8PHG1zdEByZWRo
# YXQuY29tAAoJECgfDbjSjVRp8fYH/impBH9nViO/WK48io4mLSkl0EUL8Y/xrMvH
# zKFCKaXq8D96VTt1Z4EGKYgwG0voBKZaCEKYU/0ARGnSlSwxINQ8ROCnBWMfn2sx
# yQt08EXVMznNLtXjc6U5zCoCi6SaV85GH40No3MUFXBQt29ZSlFqO/fuHGZHYBwS
# wuVKvTjjNF4EsGt3rS4Qsv6BwZWMM+dE6yXpKWk68kR8IGp+6QGxkMbWt9uEX2Md
# VuemKVnFYw0XGCGy5K+ZkvoA2DGpEw0QxVSOMs8CI55Oc9SkTKz5fUSzXXGo1if+
# M1CTjOPJu6pMym6gy6XpFa8/QioDA/jE2vBQvfJ64TwhJDV159s=
# =k8e9
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 23 Jul 2024 10:16:31 AM AEST
# gpg: using RSA key 5D09FD0871C8F85B94CA8A0D281F0DB8D28D5469
# gpg: issuer "mst@redhat.com"
# gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [undefined]
# gpg: aka "Michael S. Tsirkin <mst@redhat.com>" [undefined]
# gpg: WARNING: The key's User ID is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67
# Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469
* tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu: (61 commits)
hw/nvme: Add SPDM over DOE support
backends: Initial support for SPDM socket support
hw/pci: Add all Data Object Types defined in PCIe r6.0
tests/acpi: Add expected ACPI AML files for RISC-V
tests/qtest/bios-tables-test.c: Enable basic testing for RISC-V
tests/acpi: Add empty ACPI data files for RISC-V
tests/qtest/bios-tables-test.c: Remove the fall back path
tests/acpi: update expected DSDT blob for aarch64 and microvm
acpi/gpex: Create PCI link devices outside PCI root bridge
tests/acpi: Allow DSDT acpi table changes for aarch64
hw/riscv/virt-acpi-build.c: Update the HID of RISC-V UART
hw/riscv/virt-acpi-build.c: Add namespace devices for PLIC and APLIC
virtio-iommu: Add trace point on virtio_iommu_detach_endpoint_from_domain
hw/vfio/common: Add vfio_listener_region_del_iommu trace event
virtio-iommu: Remove the end point on detach
virtio-iommu: Free [host_]resv_ranges on unset_iommu_devices
virtio-iommu: Remove probe_done
Revert "virtio-iommu: Clear IOMMUDevice when VFIO device is unplugged"
gdbstub: Add helper function to unregister GDB register space
physmem: Add helper function to destroy CPU AddressSpace
...
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
This commit is contained in:
Richard Henderson
commit
5885bcef3d
81 changed files with 2486 additions and 288 deletions
|
|
@ -64,7 +64,8 @@ GED IO interface (4 byte access)
|
|||
0: Memory hotplug event
|
||||
1: System power down event
|
||||
2: NVDIMM hotplug event
|
||||
3-31: Reserved
|
||||
3: CPU hotplug event
|
||||
4-31: Reserved
|
||||
|
||||
**write_access:**
|
||||
|
||||
|
|
|
|||
|
|
@ -29,6 +29,7 @@ guest hardware that is specific to QEMU.
|
|||
edu
|
||||
ivshmem-spec
|
||||
pvpanic
|
||||
spdm
|
||||
standard-vga
|
||||
virt-ctlr
|
||||
vmcoreinfo
|
||||
|
|
|
|||
134
docs/specs/spdm.rst
Normal file
134
docs/specs/spdm.rst
Normal file
|
|
@ -0,0 +1,134 @@
|
|||
======================================================
|
||||
QEMU Security Protocols and Data Models (SPDM) Support
|
||||
======================================================
|
||||
|
||||
SPDM enables authentication, attestation and key exchange to assist in
|
||||
providing infrastructure security enablement. It's a standard published
|
||||
by the `DMTF`_.
|
||||
|
||||
QEMU supports connecting to a SPDM responder implementation. This allows an
|
||||
external application to emulate the SPDM responder logic for an SPDM device.
|
||||
|
||||
Setting up a SPDM server
|
||||
========================
|
||||
|
||||
When using QEMU with SPDM devices QEMU will connect to a server which
|
||||
implements the SPDM functionality.
|
||||
|
||||
SPDM-Utils
|
||||
----------
|
||||
|
||||
You can use `SPDM Utils`_ to emulate a responder. This is the simplest method.
|
||||
|
||||
SPDM-Utils is a Linux applications to manage, test and develop devices
|
||||
supporting DMTF Security Protocol and Data Model (SPDM). It is written in Rust
|
||||
and utilises libspdm.
|
||||
|
||||
To use SPDM-Utils you will need to do the following steps. Details are included
|
||||
in the SPDM-Utils README.
|
||||
|
||||
1. `Build libspdm`_
|
||||
2. `Build SPDM Utils`_
|
||||
3. `Run it as a server`_
|
||||
|
||||
spdm-emu
|
||||
--------
|
||||
|
||||
You can use `spdm emu`_ to model the
|
||||
SPDM responder.
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
$ cd spdm-emu
|
||||
$ git submodule init; git submodule update --recursive
|
||||
$ mkdir build; cd build
|
||||
$ cmake -DARCH=x64 -DTOOLCHAIN=GCC -DTARGET=Debug -DCRYPTO=openssl ..
|
||||
$ make -j32
|
||||
$ make copy_sample_key # Build certificates, required for SPDM authentication.
|
||||
|
||||
It is worth noting that the certificates should be in compliance with
|
||||
PCIe r6.1 sec 6.31.3. This means you will need to add the following to
|
||||
openssl.cnf
|
||||
|
||||
.. code-block::
|
||||
|
||||
subjectAltName = otherName:2.23.147;UTF8:Vendor=1b36:Device=0010:CC=010802:REV=02:SSVID=1af4:SSID=1100
|
||||
2.23.147 = ASN1:OID:2.23.147
|
||||
|
||||
and then manually regenerate some certificates with:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
$ openssl req -nodes -newkey ec:param.pem -keyout end_responder.key \
|
||||
-out end_responder.req -sha384 -batch \
|
||||
-subj "/CN=DMTF libspdm ECP384 responder cert"
|
||||
|
||||
$ openssl x509 -req -in end_responder.req -out end_responder.cert \
|
||||
-CA inter.cert -CAkey inter.key -sha384 -days 3650 -set_serial 3 \
|
||||
-extensions v3_end -extfile ../openssl.cnf
|
||||
|
||||
$ openssl asn1parse -in end_responder.cert -out end_responder.cert.der
|
||||
|
||||
$ cat ca.cert.der inter.cert.der end_responder.cert.der > bundle_responder.certchain.der
|
||||
|
||||
You can use SPDM-Utils instead as it will generate the correct certificates
|
||||
automatically.
|
||||
|
||||
The responder can then be launched with
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
$ cd bin
|
||||
$ ./spdm_responder_emu --trans PCI_DOE
|
||||
|
||||
Connecting an SPDM NVMe device
|
||||
==============================
|
||||
|
||||
Once a SPDM server is running we can start QEMU and connect to the server.
|
||||
|
||||
For an NVMe device first let's setup a block we can use
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
$ cd qemu-spdm/linux/image
|
||||
$ dd if=/dev/zero of=blknvme bs=1M count=2096 # 2GB NNMe Drive
|
||||
|
||||
Then you can add this to your QEMU command line:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
-drive file=blknvme,if=none,id=mynvme,format=raw \
|
||||
-device nvme,drive=mynvme,serial=deadbeef,spdm_port=2323
|
||||
|
||||
At which point QEMU will try to connect to the SPDM server.
|
||||
|
||||
Note that if using x64-64 you will want to use the q35 machine instead
|
||||
of the default. So the entire QEMU command might look like this
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
qemu-system-x86_64 -M q35 \
|
||||
--kernel bzImage \
|
||||
-drive file=rootfs.ext2,if=virtio,format=raw \
|
||||
-append "root=/dev/vda console=ttyS0" \
|
||||
-net none -nographic \
|
||||
-drive file=blknvme,if=none,id=mynvme,format=raw \
|
||||
-device nvme,drive=mynvme,serial=deadbeef,spdm_port=2323
|
||||
|
||||
.. _DMTF:
|
||||
https://www.dmtf.org/standards/SPDM
|
||||
|
||||
.. _SPDM Utils:
|
||||
https://github.com/westerndigitalcorporation/spdm-utils
|
||||
|
||||
.. _spdm emu:
|
||||
https://github.com/dmtf/spdm-emu
|
||||
|
||||
.. _Build libspdm:
|
||||
https://github.com/westerndigitalcorporation/spdm-utils?tab=readme-ov-file#build-libspdm
|
||||
|
||||
.. _Build SPDM Utils:
|
||||
https://github.com/westerndigitalcorporation/spdm-utils?tab=readme-ov-file#build-the-binary
|
||||
|
||||
.. _Run it as a server:
|
||||
https://github.com/westerndigitalcorporation/spdm-utils#qemu-spdm-device-emulation
|
||||
|
|
@ -39,3 +39,4 @@ or Hypervisor.Framework.
|
|||
multi-process
|
||||
confidential-guest-support
|
||||
vm-templating
|
||||
sriov
|
||||
|
|
|
|||
36
docs/system/sriov.rst
Normal file
36
docs/system/sriov.rst
Normal file
|
|
@ -0,0 +1,36 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0-or-later
|
||||
|
||||
Compsable SR-IOV device
|
||||
=======================
|
||||
|
||||
SR-IOV (Single Root I/O Virtualization) is an optional extended capability of a
|
||||
PCI Express device. It allows a single physical function (PF) to appear as
|
||||
multiple virtual functions (VFs) for the main purpose of eliminating software
|
||||
overhead in I/O from virtual machines.
|
||||
|
||||
There are devices with predefined SR-IOV configurations, but it is also possible
|
||||
to compose an SR-IOV device yourself. Composing an SR-IOV device is currently
|
||||
only supported by virtio-net-pci.
|
||||
|
||||
Users can configure an SR-IOV-capable virtio-net device by adding
|
||||
virtio-net-pci functions to a bus. Below is a command line example:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
-netdev user,id=n -netdev user,id=o
|
||||
-netdev user,id=p -netdev user,id=q
|
||||
-device pcie-root-port,id=b
|
||||
-device virtio-net-pci,bus=b,addr=0x0.0x3,netdev=q,sriov-pf=f
|
||||
-device virtio-net-pci,bus=b,addr=0x0.0x2,netdev=p,sriov-pf=f
|
||||
-device virtio-net-pci,bus=b,addr=0x0.0x1,netdev=o,sriov-pf=f
|
||||
-device virtio-net-pci,bus=b,addr=0x0.0x0,netdev=n,id=f
|
||||
|
||||
The VFs specify the paired PF with ``sriov-pf`` property. The PF must be
|
||||
added after all VFs. It is the user's responsibility to ensure that VFs have
|
||||
function numbers larger than one of the PF, and that the function numbers
|
||||
have a consistent stride.
|
||||
|
||||
You may also need to perform additional steps to activate the SR-IOV feature on
|
||||
your guest. For Linux, refer to [1]_.
|
||||
|
||||
.. [1] https://docs.kernel.org/PCI/pci-iov-howto.html
|
||||
Loading…
Add table
Add a link
Reference in a new issue