Glusterfs has been marked as deprecated since QEMU v9.2, and as far
as I know, nobody spoke up 'til today that it should be kept.
The listed e-mail address integration@gluster.org in our MAINTAINERS
file seems to be bouncing nowadays, and looking at their website
https://www.gluster.org/ the most recent news are from 2020 / 2021 ...
so it seems like there is really hardly any interest in Glusterfs
anymore. Thus it's time to remove the code now from QEMU.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260511063013.39805-1-thuth@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
This enables overriding the built in default QEMU project version string
with a user specified string. The value can be at most 8 characters
in length.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
This enables overriding the built in default "QEMU NVMe Ctrl" string
with a user specified string. The value can be at most 40 characters
in length.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
The fby35 machine was deprecated in QEMU 10.2 and is now removed in
QEMU 11.1.
This multi-SoC machine was added as an example of heterogeneous
systems, but the models never evolved and no public firmware is
available to boot it. Users needing multi-SoC emulation should use the
ast2700fc machine instead, which is based on newer AST2700 SoCs with
better support.
Link: https://lore.kernel.org/qemu-devel/20260510165704.2935316-5-clg@redhat.com
Acked-by: Peter Delevoryas <peter@pjd.dev>
Signed-off-by: Cédric Le Goater <clg@redhat.com>
The fp5280g2-bmc machine was deprecated in QEMU 10.2 and is now
removed in QEMU 11.1.
This Inspur FP5280G2 BMC board does not rely on specific device models
and can be replaced by the ast2500-evb machine with appropriate
fmc-model and I2C device configuration via command line.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Link: https://lore.kernel.org/qemu-devel/20260510165704.2935316-4-clg@redhat.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
The qcom-dc-scm-v1-bmc and qcom-firework-bmc machines were deprecated
in QEMU 10.2 and are now removed in QEMU 11.1.
These Qualcomm lab servers never entered production and do not rely on
specific device models. They can be replaced by the ast2600-evb
machine with appropriate fmc-model and I2C device configuration via
command line.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Link: https://lore.kernel.org/qemu-devel/20260510165704.2935316-3-clg@redhat.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
The sonorapass-bmc machine was deprecated in QEMU 10.2 and is now
removed in QEMU 11.1.
This OCP SonoraPass BMC lab server never entered production and can be
replaced by the ast2500-evb machine with appropriate fmc-model and I2C
device configuration via command line.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Link: https://lore.kernel.org/qemu-devel/20260510165704.2935316-2-clg@redhat.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
In contrast to real eMMCs, we are not (yet) persisting the full state
of the device. This particularly includes the authentication key used
for RPMB access, complicating testing of firmware images which do not
support initial provisioning of the key.
One way to address this would be, e.g., extending the eMMC disk image
with a special sector to store further state. A simpler approach is used
here: Add another device property that allows to specify the
authentication key, bringing up the eMMC as if the key has already been
provisioned before.
This is how to tell qemu to use the OP-TEE test key:
-device emmc,[...],auth-key=D3EB3EC36E334C9F988CE2C0B85954610D2BCF8664844DF2AB56E6C61BB701E4
Or use this for machine-configured eMMCs:
-global emmc.auth-key=D3EB3EC36E334C9F988CE2C0B85954610D2BCF8664844DF2AB56E6C61BB701E4
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Jerome Forissier <jerome.forissier@arm.com>
Message-ID: <9fab19ee4c755f9cb2abf55494541fcadff46cbd.1776231967.git.jan.kiszka@siemens.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Allow the user to select a GICv5 via '-machine gic-version=x-5', and
document this. The 'x-' prefix indicates that the emulation is still
in an "experimental" state as far as QEMU is concerned; the
documentation describes what "experimental" means for the user and
what parts are not yet implemented.
We do not make 'gic-version=max' enable GICv5 here because:
* the GICv5 architectural spec is still at the EAC level and could
have minor changes between now and its final version; only users
who specifically want to start working with the GICv5 should
select it
* QEMU's implementation here is still not fully featured, and
selecting it instead of GICv3 will mean losing functionality such
as MSIs
* the GICv5 is not backwards compatible with the GICv3/GICv4 for
system software, so silently "upgrading" an existing command line
to GICv5 is just going to break existing guest kernels
The last one in particular suggests that even when the emulation
moves out of "experimental" status we will probably not want to
change "max".
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20260327111700.795099-66-peter.maydell@linaro.org
Allow the 'aarch64=off' property, which is currently KVM-only, to
be set for TCG CPUs also.
Note that we don't permit it on the qemu-aarch64 user-mode binary:
this makes no sense as that executable can only handle AArch64
syscalls (and it would also assert at startup since it doesn't
compile in the A32-specific GDB xml files like arm-neon.xml).
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Clément Chigot <chigot@adacore.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20260416165353.589569-3-peter.maydell@linaro.org
Implemented CPUs, RAM, UARTs and Interrupt Controller
Other peripherals are represented as TYPE_UNIMPLEMENTED_DEVICE
Complete memory map of the SoC is provided.
Set default RAM size to 2GB and default CPU count to 4 to match
the real i.MX8MM EVK hardware configuration.
Documentation is shared with imx8mp-evk to avoid duplication.
Signed-off-by: Gaurav Sharma <gaurav.sharma_7@nxp.com>
[PMM: fixed over-long lines in doc]
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Bernhard Beschow <shentey@gmail.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This is just a documentation tweak as we already support both.
FEAT_AA32 implies FEAT_AA32EL0. FEAT_AA64 implies FEAT_AA64EL[0123].
This is however useful if you are using emulation.rst as a source of
truth of what QEMU emulates and when cross checking with
Features.json from Arm.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260421093506.616307-1-alex.bennee@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This avoids a redirect from the old to the new URL.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
S3 presigned URLs are signed for a specific HTTP method (typically GET
for our use cases). The curl block driver currently issues a HEAD
request to discover the web server features and the file size, which
fails with 'HTTP 403' (forbidden).
Add a 'force-range' option that skips the HEAD request and instead
issues a minimal GET request (querying 1 byte from the server) to
extract the file size from the 'Content-Range' response header. To
achieve this the 'curl_header_cb' is redesigned to generically parse
HTTP headers.
$ $QEMU -drive driver=https,\
'url=https://s3.example.com/some.img?X-Amz-Security-Token=XXX',
force-range=true
Enabling the 'force-range' option without the web server specified with
@url supporting it might cause the server to respond successfully with
'HTTP 200' and attempt to send the whole file body. With the
'CURLOPT_NOBODY' option set the libcurl will skip reading after the
headers and close the connection. QEMU still gracefully detects the
missing feature. This might waste a small number of TCP packets but is
otherwise transparent to the user.
Acked-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Antoine Damhet <adamhet@scaleway.com>
Message-ID: <20260227-fix-curl-v3-v3-3-eb8a4d88feef@scaleway.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
This attempts to tidy up the VirtIO GPU documentation to make the list
of requirements clearer. There are still a lot of moving parts and the
distros have some catching up to do before this is all handled
automatically.
Cc: Sergio Lopez Pascual <slp@redhat.com>
Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Yiwei Zhang <zzyiwei@gmail.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
[dmitry.osipenko@collabora.com: Extended and corrected doc]
Message-ID: <20260303151422.977399-14-dmitry.osipenko@collabora.com>
Message-ID: <20260304165043.1437519-16-alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
This aligns the first line of the docs with the style used for previous
CPU models, and simplifies the text in the remaining docs.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Provide a kvm specific vcpu property to override the default
(as of kernel v6.13 that would be PSCI v1.3) PSCI version emulated
by kvm. Current valid values are: 0.1, 0.2, 1.0, 1.1, 1.2, and 1.3
Note: in order to support PSCI v0.1 we need to drop vcpu
initialization with KVM_CAP_ARM_PSCI_0_2 in that case.
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Sebastian Ott <sebott@redhat.com>
Message-id: 20260220115656.4831-2-sebott@redhat.com
[PMM: adjust sscanf to not permit negative numbers]
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Windows ARM64 guests detect virtio-mmio devices declared in ACPI
tables even when no backend is attached. This causes "Unknown
devices" (ACPI\LNRO0005) to appear in Device Manager.
Until Windows fixes that by supporting, add a new machine
property 'virtio-mmio-transports' to control the number of
virtio-mmio transports instantiated. The default remains
NUM_VIRTIO_TRANSPORTS (32) for backward compatibility.
Setting it to 0 allows users to disable virtio-mmio entirely.
Usage: -machine virt,virtio-mmio-transports=0
Signed-off-by: Mohammadfaiz Bawa <mbawa@redhat.com>
Message-id: 20260219173256.152743-1-mbawa@redhat.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Add basic plumbing for memory expander devices that support Back
Invalidation. This introduces a 'hdm-db=on|off' parameter and
exposes the relevant BI RT/Decoder component cachemem registers.
Some noteworthy properties:
- Devices require enabling Flit mode across the CXL topology.
- Explicit BI-ID commit is required.
- HDM decoder support both host and dev coherency models.
Tested-by: Dongjoo Seo <dongjoo.seo1@samsung.com>
Signed-off-by: Davidlohr Bueso <dave@stgolabs.net>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260204170936.43959-7-Jonathan.Cameron@huawei.com>
After the introduction of vhost-user-bridge and libvhost-user, we
formed the convention of placing vhost-user daemons in eponymous subdirs
of contrib/. Follow this convention.
Create a contrib/vhost-user-bridge/ directory and move vhost-user-bridge
into it. Extract its build target definition from tests/meson.build into
the new directory, and include its subdir in the root-level meson.build.
Add a section about it in the "vhost-user daemons in contrib" document.
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Yodel Eldar <yodel.eldar@yodel.dev>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260129133049.119829-2-yodel.eldar@yodel.dev>
In commit f7767ca301 ("target/arm: Disable SME if SVE is disabled")
we added code that forces SME to be disabled if SVE is disabled.
This was something we did in the run-up to a release to avoid an
assertion failure in smcr_write() if the user disabled SVE on the
'max' CPU without disabling SME also.
Now that we have corrected the code so that it doesn't assert
in an SME-without-SVE setup, we can let users select it.
This effectively reverts f7767ca301.
Note that this now means that command lines like "-cpu max,sve=off"
which used to turn off SME and SVE will now give you a CPU with SME
but not SVE. This is permitted by our loose "max can always give you
extra stuff" rules, but may be unexpected to users. Mention this in
the CPU property documentation.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260202133353.2231685-16-peter.maydell@linaro.org
In our handling of the boolean 'sme' CPU property, we write this 0/1
value directly to ID_AA64PFR1_EL1.SME. This worked when the only
valid values in that field were 0 (for no SME) and 1 (for SME1).
However, with the addition of SME2 the SME field can now also read 2.
This means that "-cpu max,sme=on" will result in an inconsistent set
of ID registers, where ID_AA64PFR1_EL1.SME claims SME1 but
ID_AA64SMFR0_EL1.SMEver claims SME2p1. This isn't a valid thing to
report, and confuses Linux into reporting SME2 to userspace but not
actually enabling userspace access for it.
Fix this bug by having arm_cpu_sme_finalize() fix up the
ID_AA64PFR1_EL1.SME field to match ID_AA64SMFR0.SMEver. This means
the "sme" property's semantics are "off" for "no SME" and "on" for
"enable at whatever the default SME version this CPU provides is".
Update the documentation to clarify what 'sve=on' and 'sme=on' do.
(We don't have the equivalent bug for 'sve=on' because
ID_AA64PFR0_EL1.SVE only has 0 and 1 as valid values, but the
semantics of the property are the same.)
Cc: qemu-stable@nongnu.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Message-id: 20260202133353.2231685-6-peter.maydell@linaro.org
FEAT_E2H0 is a formalisation of the existing behaviour of HCR_EL2.E2H
being programmable to switch between EL2 host mode and the
"traditional" nVHE EL2 mode. This implies at some point we might want
to model CPUs without FEAT_E2H0 which will always have EL2 host mode
enabled.
There are two values to represent no E2H0 systems of which 0b1110 will
make HCR_EL2.NV1 RES0 for FEAT_NV systems. For FEAT_NV2 the NV1 bit is
always valid.
Message-ID: <20260130181648.628364-1-alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Mohamed Mediouni <mohamed@unpredictable.fr>
Message-id: 20260205210231.888199-1-alex.bennee@linaro.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Update the documentation to match current QEMU.
Remove the mention of pre-2.7 machine models as those aren't provided
anymore.
Signed-off-by: Mohamed Mediouni <mohamed@unpredictable.fr>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
virtio,pci,pc: features, fixes
intel_iommu:
SVM support
vhost:
support for indirect descriptors in shadow virtqueue
vhost-user:
vhost-user-spi support
vhost-user-blk inflight migration support
vhost-user-blk inflight migration support
misc fixes in pci, vhost, virtio, acpi, cxl
cleanups in acpi/ghes
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
# -----BEGIN PGP SIGNATURE-----
#
# iQFDBAABCgAtFiEEXQn9CHHI+FuUyooNKB8NuNKNVGkFAmmEa9APHG1zdEByZWRo
# YXQuY29tAAoJECgfDbjSjVRpqj8H/iBqAHZSTmAdBJgoLnmgoTLB01J9aUTrQU2H
# BHKyrd+G3m54pwjgUNN5ieZARtlXscigf6fr0Gq2wrc8/kV/O5G5jViw9+1Bo8nW
# OkLDW45nDzZGhap4oUedV+PJ3fCuW2fC8Jyb1n8OGlkadbhq0NU6GtqiEx6/7QIh
# hk5WUDE/3LH4cTp8qNtr0/nYfM4FZk2sjq7aRyg4cz/uC7rIAFRq7BCZ/dfRqMh/
# T+rLnizSSAg9PFMd8slWqoxOGF9NzT9LIoDSkAlso1L9lUekUSNoUblhlWDrRlLn
# DEEqqGCVounfBzA95WrTRmvWs6JodppjjAjI0M4isrMKGXXg8dg=
# =HdgY
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu Feb 5 10:07:12 2026 GMT
# gpg: using RSA key 5D09FD0871C8F85B94CA8A0D281F0DB8D28D5469
# gpg: issuer "mst@redhat.com"
# gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [full]
# gpg: aka "Michael S. Tsirkin <mst@redhat.com>" [full]
# 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: (38 commits)
hw/cxl: Take into account how many media operations are requested for param check
hw/cxl: Check for overflow on santize media as both base and offset 64bit.
vhost-user-blk: support inter-host inflight migration
vhost: add vmstate for inflight region with inner buffer
vmstate: introduce VMSTATE_VBUFFER_UINT64
vhost-user: introduce protocol feature for skip drain on GET_VRING_BASE
vhost-user.rst: specify vhost-user back-end action on GET_VRING_BASE
virtio-gpu: use consistent error checking for virtio_gpu_create_mapping_iov
virtio-gpu: fix error handling in virgl_cmd_resource_create_blob
virtio-pmem: ignore empty queue notifications
virtio-gpu-virgl: correct parent for blob memory region
MAINTAINERS: Update VIOT maintainer
cryptodev-builtin: Limit the maximum size
hw/virtio/virtio-crypto: verify asym request size
virtio-spi: Add vhost-user-spi device support
standard-headers: Update virtio_spi.h from Linux v6.18-rc3
q35: Fix migration of SMRAM state
pcie_sriov: Fix PCI_SRIOV_* accesses in pcie_sriov_pf_exit()
virtio: Fix crash when sriov-pf is set for non-PCI-Express device
virtio-dmabuf: Ensure UUID persistence for hash table insertion
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>