| 067af4f7 | 19-Aug-2025 |
Peter Maydell <peter.maydell@linaro.org> |
scripts/kernel-doc: Avoid new Perl precedence warning
Newer versions of Perl (5.41.x and up) emit a warning for code in kernel-doc: Possible precedence problem between ! and pattern match (m//) at
scripts/kernel-doc: Avoid new Perl precedence warning
Newer versions of Perl (5.41.x and up) emit a warning for code in kernel-doc: Possible precedence problem between ! and pattern match (m//) at /scripts/kernel-doc line 1597.
This is because the code does: if (!$param =~ /\w\.\.\.$/) {
In Perl, the ! operator has higher precedence than the =~ pattern-match binding, so the effect of this condition is to first logically-negate the string $param into a true-or-false value and then try to pattern match it against the regex, which in this case will always fail. This is almost certainly not what the author intended.
In the new Python version of kernel-doc in the Linux kernel, the equivalent code is written:
if KernRe(r'\w\.\.\.$').search(param): # For named variable parameters of the form `x...`, # remove the dots param = param[:-3] else: # Handles unnamed variable parameters param = "..."
which is a more sensible way of writing the behaviour you would get if you put in brackets to make the regex match first and then negate the result.
Take this as the intended behaviour, and update the Perl to match.
For QEMU, this produces no change in output, presumably because we never used the "unnamed variable parameters" syntax.
Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Message-id: 20250819115648.2125709-1-peter.maydell@linaro.org (cherry picked from commit 5ffd387e9e0f787744fadaad35e1bf92224b0642) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
show more ...
|
| fbc8fb36 | 22-Jul-2025 |
Paolo Bonzini <pbonzini@redhat.com> |
scripts: add script to help distros use global Rust packages
Some distros prefer to avoid vendored crate sources, and instead use local sources from e.g. ``/usr/share/cargo/registry``. Add a script
scripts: add script to help distros use global Rust packages
Some distros prefer to avoid vendored crate sources, and instead use local sources from e.g. ``/usr/share/cargo/registry``. Add a script, inspired by the Mesa spec file(*), that automatically performs this task. The script is meant to be invoked after unpacking the QEMU tarball.
(*) This is the hack that Mesa uses:
export MESON_PACKAGE_CACHE_DIR="%{cargo_registry}/" %define inst_crate_nameversion() %(basename %{cargo_registry}/%{1}-*) %define rewrite_wrap_file() sed -e "/source.*/d" -e "s/%{1}-.*/%{inst_crate_nameversion %{1}}/" -i subprojects/%{1}.wrap %rewrite_wrap_file proc-macro2 ... more %rewrite_wrap_file invocations follow ...
Reviewed-by: Neal Gompa <ngompa@fedoraproject.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
| c017386f | 25-Jul-2025 |
Stefan Hajnoczi <stefanha@redhat.com> |
Merge tag 'pull-target-arm-20250725' of https://gitlab.com/pm215/qemu into staging
target-arm queue: * Fix various bugs in SMEp/SVE2p1 load/store handling * hw/arm/smmu-common: Avoid using inlined
Merge tag 'pull-target-arm-20250725' of https://gitlab.com/pm215/qemu into staging
target-arm queue: * Fix various bugs in SMEp/SVE2p1 load/store handling * hw/arm/smmu-common: Avoid using inlined functions with external linkage * target/arm: hvf: stubbing reads to LORC_EL1
# -----BEGIN PGP SIGNATURE----- # # iQJNBAABCAA3FiEE4aXFk81BneKOgxXPPCUl7RQ2DN4FAmiDbRIZHHBldGVyLm1h # eWRlbGxAbGluYXJvLm9yZwAKCRA8JSXtFDYM3sifD/9uJRrZ0o/PQfRVIYl7vIFE # MjUl6sncznX1zk/B7xNuiJ5KDoziQm/L3KPcb0JPoqhO3nLeqvLIvfmB6W85cV/w # OD0PFnL1inuxWf1rKdeheGtyZ0R9Ep3BFzB6NJMDxVJC9aP0eqfGxVo2BCdydv/9 # m3v7gCkp/lj5LcpJ+8w0bEzuqT3xzcbibFdFi4eKBiG5P3OvwGv3Kt+FhOISXcBe # cU+RpXEkd0MBusOWq1OXLgWS+IPx/e67l1ehxAfVztxFUI3gwej7JgLCnIIoxRsw # EWGQYhSSg6QE8h2TknxDKj9jmMcqnjluRjaefPQS8BxbYc6s6dsSBCxbeZJ/zNyJ # gD/ymK/nayTBfoP+S7eWGDaldNv/AnKSWa28GEpi3dmDDfKlwRB77arGU2zXirjo # dG/0tcg+G7mmkSH5BbPJfFJgjUqEu+D2wq1wm53SSb/AqK8BL4ODF3LE6r6+65ft # fg5nalDbn2uTa90M7BHfaGEJj0hdP8xM9wmRHCoJ1LEDieSsjInZWwIbSwQBL6Rc # Rr2PmnTWdMKuyr9WgOBzFfCAzmFDwJmqlIqRIRHPKo21xAiGYh8oTp31MhgZWdaj # yK+V9t5Mznp1PVfL5xYwe/xG1CmKE6FKOwuvF3RkTF5lBU88x9fIcPOjaWZymW4n # iqkUZmp+nS9K3V4WWjGxnQ== # =quq9 # -----END PGP SIGNATURE----- # gpg: Signature made Fri 25 Jul 2025 07:40:02 EDT # gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE # gpg: issuer "peter.maydell@linaro.org" # gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [full] # gpg: aka "Peter Maydell <pmaydell@gmail.com>" [full] # gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [full] # gpg: aka "Peter Maydell <peter@archaic.org.uk>" [unknown] # Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE
* tag 'pull-target-arm-20250725' of https://gitlab.com/pm215/qemu: target/arm: hvf: stubbing reads to LORC_EL1 hw/arm/smmu-common: Avoid using inlined functions with external linkage target/arm: Fix LD1W, LD1D to 128-bit elements target/arm: Pass correct esize to sve_st1_z() for LD1Q, ST1Q target/arm: LD1Q, ST1Q are vector + scalar, not scalar + vector decodetree: Infer argument set before inferring format target/arm: Pack mtedesc into upper 32 bits of descriptor target/arm: Expand the descriptor for SME/SVE memory ops to i64
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
show more ...
|
| d3c9de45 | 25-Jul-2025 |
Stefan Hajnoczi <stefanha@redhat.com> |
Merge tag 'tracing-pull-request' of https://gitlab.com/stefanha/qemu into staging
Pull request
This commit is still worth having in QEMU 10.1 for the all-round improvements made (consistent timesta
Merge tag 'tracing-pull-request' of https://gitlab.com/stefanha/qemu into staging
Pull request
This commit is still worth having in QEMU 10.1 for the all-round improvements made (consistent timestamping, binary size reduction, header pollution cleanup) even if it's debatable whether this is a bug fix.
# -----BEGIN PGP SIGNATURE----- # # iQEzBAABCgAdFiEEhpWov9P5fNqsNXdanKSrs4Grc8gFAmiCR0UACgkQnKSrs4Gr # c8g4AggAyBo1oNAVSMQIC6JRRcLrVBCWGPWVyU1/3AaayKLy8egs1pImmT09DcdQ # D2CHCjEp0xbTzFlN3YiBymAOeq/a73G7NPzWdCi/PY1qBmB4td8Eli/tBoQUYvmE # k0a0r6DrOo6vGddCqv6fAKnvamcs/IB2ogzpqLVLCC4oAP6TVG0LeHsaqTAtO8bv # yZb+1YQxFZtum2yp9I4+mk8c1R04cCdDL17TRCrv4hTkpGRYfaDs8LRy5yJ4Nw6V # AID3fkLTaxOcQpb2EItfcoGalF/JcCdZoOlJ/91clJ1MWFAnV9Y9gBZtlSF4dx+k # c2rTlcBw9j402imuotLOP7Cl8mLNeg== # =lXaI # -----END PGP SIGNATURE----- # gpg: Signature made Thu 24 Jul 2025 10:46:29 EDT # gpg: using RSA key 8695A8BFD3F97CDAAC35775A9CA4ABB381AB73C8 # gpg: Good signature from "Stefan Hajnoczi <stefanha@redhat.com>" [ultimate] # gpg: aka "Stefan Hajnoczi <stefanha@gmail.com>" [ultimate] # Primary key fingerprint: 8695 A8BF D3F9 7CDA AC35 775A 9CA4 ABB3 81AB 73C8
* tag 'tracing-pull-request' of https://gitlab.com/stefanha/qemu: log: make '-msg timestamp=on' apply to all qemu_log usage
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
show more ...
|
| 012842c0 | 21-Jul-2025 |
Daniel P. Berrangé <berrange@redhat.com> |
log: make '-msg timestamp=on' apply to all qemu_log usage
Currently the tracing 'log' back emits special code to add timestamps to trace points sent via qemu_log(). This current impl is a bad design
log: make '-msg timestamp=on' apply to all qemu_log usage
Currently the tracing 'log' back emits special code to add timestamps to trace points sent via qemu_log(). This current impl is a bad design for a number of reasons.
* It changes the QEMU headers, such that 'error-report.h' content is visible to all files using tracing, but only when the 'log' backend is enabled. This has led to build failure bugs as devs rarely test without the (default) 'log' backend enabled, and CI can't cover every scenario for every trace backend.
* It bloats the trace points definitions which are inlined into every probe location due to repeated inlining of timestamp formatting code, adding MBs of overhead to QEMU.
* The tracing subsystem should not be treated any differently from other users of qemu_log. They all would benefit from having timestamps present.
* The timestamp emitted with the tracepoints is in a needlessly different format to that used by error_report() in response to '-msg timestamp=on'.
This fixes all these issues simply by moving timestamp formatting into qemu_log, using the same approach as for error_report.
The code before:
static inline void _nocheck__trace_qcrypto_tls_creds_get_path(void * creds, const char * filename, const char * path) { if (trace_event_get_state(TRACE_QCRYPTO_TLS_CREDS_GET_PATH) && qemu_loglevel_mask(LOG_TRACE)) { if (message_with_timestamp) { struct timeval _now; gettimeofday(&_now, NULL); qemu_log("%d@%zu.%06zu:qcrypto_tls_creds_get_path " "TLS creds path creds=%p filename=%s path=%s" "\n", qemu_get_thread_id(), (size_t)_now.tv_sec, (size_t)_now.tv_usec , creds, filename, path); } else { qemu_log("qcrypto_tls_creds_get_path " "TLS creds path creds=%p filename=%s path=%s" "\n", creds, filename, path); } } }
and after:
static inline void _nocheck__trace_qcrypto_tls_creds_get_path(void * creds, const char * filename, const char * path) { if (trace_event_get_state(TRACE_QCRYPTO_TLS_CREDS_GET_PATH) && qemu_loglevel_mask(LOG_TRACE)) { qemu_log("qcrypto_tls_creds_get_path " "TLS creds path creds=%p filename=%s path=%s" "\n", creds, filename, path); } }
The log and error messages before:
$ qemu-system-x86_64 -trace qcrypto* -object tls-creds-x509,id=tls0,dir=$HOME/tls -msg timestamp=on 2986097@1753122905.917608:qcrypto_tls_creds_x509_load TLS creds x509 load creds=0x55d925bd9490 dir=/var/home/berrange/tls 2986097@1753122905.917621:qcrypto_tls_creds_get_path TLS creds path creds=0x55d925bd9490 filename=ca-cert.pem path=<none> 2025-07-21T18:35:05.917626Z qemu-system-x86_64: Unable to access credentials /var/home/berrange/tls/ca-cert.pem: No such file or directory
and after:
$ qemu-system-x86_64 -trace qcrypto* -object tls-creds-x509,id=tls0,dir=$HOME/tls -msg timestamp=on 2025-07-21T18:43:28.089797Z qcrypto_tls_creds_x509_load TLS creds x509 load creds=0x55bf5bf12380 dir=/var/home/berrange/tls 2025-07-21T18:43:28.089815Z qcrypto_tls_creds_get_path TLS creds path creds=0x55bf5bf12380 filename=ca-cert.pem path=<none> 2025-07-21T18:43:28.089819Z qemu-system-x86_64: Unable to access credentials /var/home/berrange/tls/ca-cert.pem: No such file or directory
The binary size before:
$ ls -alh qemu-system-x86_64 -rwxr-xr-x. 1 berrange berrange 87M Jul 21 19:39 qemu-system-x86_64 $ strip qemu-system-x86_64 $ ls -alh qemu-system-x86_64 -rwxr-xr-x. 1 berrange berrange 30M Jul 21 19:39 qemu-system-x86_64
and after:
$ ls -alh qemu-system-x86_64 -rwxr-xr-x. 1 berrange berrange 85M Jul 21 19:41 qemu-system-x86_64 $ strip qemu-system-x86_64 $ ls -alh qemu-system-x86_64 -rwxr-xr-x. 1 berrange berrange 29M Jul 21 19:41 qemu-system-x86_64
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Message-id: 20250721185452.3016488-1-berrange@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
show more ...
|
| 24ad5e19 | 18-Jul-2025 |
Daniel P. Berrangé <berrange@redhat.com> |
crypto: implement workaround for GNUTLS thread safety problems
When TLS 1.3 is negotiated on a TLS session, GNUTLS will perform automatic rekeying of the session after 16 million records. This is do
crypto: implement workaround for GNUTLS thread safety problems
When TLS 1.3 is negotiated on a TLS session, GNUTLS will perform automatic rekeying of the session after 16 million records. This is done for all algorithms except CHACHA20_POLY1305 which does not require rekeying.
Unfortunately the rekeying breaks GNUTLS' promise that it is safe to use a gnutls_session_t object concurrently from multiple threads if they are exclusively calling gnutls_record_send/recv.
This patch implements a workaround for QEMU that adds a mutex lock around any gnutls_record_send/recv call to serialize execution within GNUTLS code. When GNUTLS calls into the push/pull functions we can release the lock so the OS level I/O calls can at least have some parallelism.
The big downside of this is that the actual encryption/decryption code is fully serialized, which will halve performance of that cipher operations if two threads are contending.
The workaround is not enabled by default, since most use of GNUTLS in QEMU does not tickle the problem, only non-multifd migration with a return path open is affected. Fortunately the migration code also won't trigger the halving of performance, since only the outbound channel diretion needs to sustain high data rates, the inbound direction is low volume.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/qemu-devel/20250718150514.2635338-2-berrange@redhat.com [add stub for qcrypto_tls_session_require_thread_safety; fix unused var] Signed-off-by: Fabiano Rosas <farosas@suse.de>
show more ...
|
| 636c96cd | 11-Jul-2025 |
John Snow <jsnow@redhat.com> |
qapi: Fix undocumented return values by generating something
Generated command documentation lacks information on return value in several cases, e.g. query-tpm.
The obvious fix would be to require
qapi: Fix undocumented return values by generating something
Generated command documentation lacks information on return value in several cases, e.g. query-tpm.
The obvious fix would be to require a Returns: section when a command returns something.
However, note that many existing Returns: sections are pretty useless: the description is basically the return type, which then gets rendered like "Return: <Type> – <basically the return type>". This suggests that a description is often not really necessary, and requiring one isn't useful.
Instead, generate the obvious minimal thing when Returns: is absent: "Return: <Type>".
This auto-generated Return documentation is placed is as follows:
1. If we have arguments, return goes right after them. 2. Else if we have errors, return goes right before them. 3. Else if we have features, return goes right before them. 4. Else return goes right after the intro
To facilitate this algorithm, a "TODO:" hack line is used to separate the intro from the remainder of the documentation block in cases where there are no other sections to separate the intro from e.g. examples and additional detail meant to appear below the key sections of interest.
Signed-off-by: John Snow <jsnow@redhat.com> Message-ID: <20250711051045.51110-3-jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [_insert_near_kind() code replaced by something simpler, commit message amended to explain why we're doing this] Signed-off-by: Markus Armbruster <armbru@redhat.com>
show more ...
|
| 62c4dc4b | 18-Jun-2025 |
John Snow <jsnow@redhat.com> |
qapi: lift restriction on using '=' in doc blocks
We reject lines starting with '=' in definition documentation. This made sense when such lines were headings in free-form documentation, but not in
qapi: lift restriction on using '=' in doc blocks
We reject lines starting with '=' in definition documentation. This made sense when such lines were headings in free-form documentation, but not in definition documentation.
Before the previous commit, lines starting with '=' were headings in free-form documentation, and rejected in definition documentation, where such headings could not work.
The previous commit dropped the headings feature from free-form documentation, because we can simply use plain rST headings. Rejecting them in definition documentation no longer makes sense, so drop that, too.
Signed-off-by: John Snow <jsnow@redhat.com> Message-ID: <20250618165353.1980365-6-jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [Amend commit message to explain why] Signed-off-by: Markus Armbruster <armbru@redhat.com>
show more ...
|