On Thu, Feb 19, 2026 at 10:29:56AM +0000, Peter Maydell wrote: > On Wed, 11 Feb 2026 at 15:29, Daniel P. Berrangé <[email protected]> wrote: > > After: > > > > # qemu-system-x86_64 -object tls-creds-x509,id=t0,dir=fish -d > > 'trace:qcrypto*' > > qemu-system-x86_64: (772366:main): qcrypto_tls_creds_x509_load TLS creds > > x509 load creds=0x560db818e080 dir=fish > > qemu-system-x86_64: (772366:main): qcrypto_tls_creds_get_path TLS creds > > path creds=0x560db818e080 filename=ca-cert.pem path=<none> > > qemu-system-x86_64: (772366:main): Unable to access credentials > > fish/ca-cert.pem: No such file or directory > > Even more output enabled by default that is pretty useless for most > uses of tracepoints and debug logging :-(
Getting the thread info in qemu log output was the original primary motivating factor in this series. This short example doesn't show it, but when debugging/tracing QEMU it is pretty important to understand which messages are coming from different threads, so we can correctly interpret the control flow. Pretty much every logging framework these days will include some thread identifier by default, and IMHO it is reasonable to do this by default in QEMU too. There was a proposal a while back on the list to add stack trace dumps to qemu_log output to allow threads to be distinguished, which obviously could never be enabled by default. The short thread ident info was something that could be unconditionally enabled so we get more useful info from users reporting bugs without having to go back and ask them to re-do the log collection with more options. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
