Nvidia stable 10.1 bugfixes #8
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Proposing myself as a reviewer for XIVE on PPC. I have been looking at XIVE in context of KVM internally at IBM for some time in addition to testing a few XIVE upstream patches; and I'll be closely looking at XIVE going forward. Signed-off-by: Gautam Menghani <gautam@linux.ibm.com> Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250724100623.3071131-6-harshpb@linux.ibm.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
Frédéric has moved to other tasks within IBM and no longer does QEMU development. Cc: Frédéric Barrat <fbarrat@linux.ibm.com> Acked-by: Frédéric Barrat <fbarrat@linux.ibm.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Link: https://lore.kernel.org/qemu-devel/20250724075916.1593420-1-clg@redhat.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
It has been awhile since I actively did anything for qemu-ppc aside from reading the qemu-ppc inbox a couple of times each month. It's not enough to justify a reviewer role, let alone being a maintainer. Given that we're doing qemu-ppc maintainership changes across the board I'll take the opportunity and remove myself from the premises too. Feel free to reach out with questions about code I did in the past, but at this moment I'm no longer able to keep up with qemu-ppc activities. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250724123416.3115941-1-danielhb413@gmail.com [ clg: Adjusted context ] Signed-off-by: Cédric Le Goater <clg@redhat.com>
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>
In case of multiple chunks, code in qxl_unpack_chunks() takes size of the wrong (next in the chain) chunk, instead of using current chunk size. This leads to wrong number of bytes being copied, and to crashes if next chunk size is larger than the current one. Based on the code by Gao Yong. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1628 Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Thomas Huth <thuth@redhat.com>
We have run out of room attempting to pack both the gvec descriptor and the mte descriptor into 32 bits. Here, change nothing except the parameter type, which affects all declarations, the function typedefs, and the type used with tcg expansion. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20250723165458.3509150-2-peter.maydell@linaro.org
Instead of trying to pack mtedesc into the upper 17 bits of a 32-bit gvec descriptor, pass the gvec descriptor in the lower 32 bits and the mte descriptor in the upper 32 bits of a 64-bit operand. This fixes two bugs: (1) in gen_sve_ldr() and gen_sve_str() call gen_mte_checkN() with a length value which is the SVE vector length and can be up to 256 bytes. We don't assert there that it fits in the descriptor, so we would just fail to do the MTE checks on the right length of memory if the VL is more than 32 bytes (2) the new-in-SVE2p1 insns LD3Q, LD4Q, ST3Q, ST4Q also involve transfers of more than 32 bytes of memory. In this case we would assert at translate time. (Note for potential backporting: this commit depends on the previous "target/arm: Expand the descriptor for SME/SVE memory ops to i64".) Fixes: 7b1613a ("target/arm: Enable FEAT_SME2p1 on -cpu max") Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20250723165458.3509150-3-peter.maydell@linaro.org [PMM: expand commit message to clarify that we are fixing bugs here] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Failure to confirm an argument set first may result in the selection of a format which leaves extra arguments to be filled in by the pattern. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Tested-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20250723165458.3509150-4-peter.maydell@linaro.org Message-id: 20250722183343.273533-1-richard.henderson@linaro.org Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Tested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Unlike the "LD1D (scalar + vector)" etc instructions, LD1Q is vector + scalar. This means that: * the vector and the scalar register are in opposite fields in the encoding * 31 in the scalar register field is XZR, not XSP The same applies for ST1Q. This means we can't reuse the trans_LD1_zprz() and trans_ST1_zprz() functions for LD1Q and ST1Q. Split them out to use their own trans functions. Note that the change made here to sve.decode requires the decodetree bugfix "decodetree: Infer argument set before inferring format" to avoid a spurious compile-time error about "dtype". Fixes: d2aa9a8 ("target/arm: Implement LD1Q, ST1Q for SVE2p1") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20250723165458.3509150-5-peter.maydell@linaro.org
Our implementation of the helper functions for the LD1Q and ST1Q insns reused the existing DO_LD1_ZPZ_D and DO_ST1_ZPZ_D macros. This passes the wrong esize (8, not 16) to sve_ldl_z(). Create new macros DO_LD1_ZPZ_Q and DO_ST1_ZPZ_Q which pass the correct esize, and use them for the LD1Q and ST1Q helpers. Fixes: d2aa9a8 ("target/arm: Implement LD1Q, ST1Q for SVE2p1") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20250723165458.3509150-6-peter.maydell@linaro.org
In our implementation of the SVE2p1 contiguous load to 128-bit element insns such as LD1D (scalar plus scalar, single register), we got the order of the arguments to the DO_LD1_2() macro wrong. Here the first argument is the element size and the second is the memory size, and the element size is always the same size or larger than the memory size. For the 128-bit versions, we want to load either 32-bit or 64-bit values from memory and extend them to the 128-bit vector element, but were trying to load 128 bit values and then stuff them into 32-bit or 64-bit vector elements. Correct the macro ordering. Fixes: fc5f060 ("target/arm: Implement {LD1, ST1}{W, D} (128-bit element) for SVE2p1") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20250723165458.3509150-7-peter.maydell@linaro.org
Similarly to commit 9de9fa5 ("hw/arm/smmu-common: Avoid using inlined functions with external linkage"): None of our code base require / use inlined functions with external linkage. Some places use internal inlining in the hot path. These two functions are certainly not in any hot path and don't justify any inlining, so these are likely oversights rather than intentional. Fixes: b8fa4c2 (hw/arm/smmu: Support nesting in the rest of commands) Signed-off-by: JianChunfu <jansef.jian@hj-micro.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Linux zeroes LORC_EL1 on boot at EL2, without further interaction with FEAT_LOR afterwards. Stub out LORC_EL1 accesses as FEAT_LOR is a mandatory extension on Armv8.1+. 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>
…osas/qemu into staging Migration pull request - Fixes to postcopy blocktime latency display code - Fix to QMP error message (not)shown when postcopy fails - Workaround to a GNUTLS bug that crashes QEMU # -----BEGIN PGP SIGNATURE----- # # iQJEBAABCAAuFiEEqhtIsKIjJqWkw2TPx5jcdBvsMZ0FAmiAG1wQHGZhcm9zYXNA # c3VzZS5kZQAKCRDHmNx0G+wxnR0xEACZMIqnVIFUu57V5gJ8v/4IJv70n6jrjtzJ # 5/TzdAAY9bKJE5y84axovZy4iHijbZnGz+kVKr5Wai9KKb41tW0liWAe5RART2TE # VuRBgxXODCmg3US6w0niy9cR3NH7WXbEQ5gyexC7D3/1R1ahpqOragZQxzvtA+3e # aKe2pqRyQODHU9D1tnKexeFNJM6dGBVd9FVsYAHDfhx0Bk1vcpVXVrAJcfaSY2Y5 # +4/g7CXOJCUFBrFbVxYFU9muU8JrMvWv8lU4nG2ztDhmSH7Uy/DVCfEUa9/jEjDa # 1BwZbOIIFMJy0P/G3toK6Z9lJEVfiUXaboNtqgSK5ZM8ZL1L1yHKQi631Qny/Wuf # pzJWR1nOSL2f/bsueWj2OmZKl3FpXcaDWisZuDeS3wXWrtPRuJEXi6f//6JcYd2i # Zm0kVRNf3CbXGnJxwDrsbh0hr5sN+bonaI+N4hHGxDCqUHhND4p0JMaPMte+PF4u # pOooaRKq2a6KRZFyDPjyBgESXfDJ0Tdw5IeOKbFPskOEIpBVxyc3mpwu8Kz45qoV # 8b2GYCKBjWLpqfTPwUcJd5MNVDO1ZUyqOPuarHNADth6pJglnWyFI/TIBoARzAKB # EzS4dQ+DKM/Jz5cM++0dMPL75/1i2q2x7BBhCBBm9yeZDqDIKeT07yl8JGL/OCq9 # 7gNGfyze5w== # =DGn2 # -----END PGP SIGNATURE----- # gpg: Signature made Tue 22 Jul 2025 19:14:36 EDT # gpg: using RSA key AA1B48B0A22326A5A4C364CFC798DC741BEC319D # gpg: issuer "farosas@suse.de" # gpg: Good signature from "Fabiano Rosas <farosas@suse.de>" [unknown] # gpg: aka "Fabiano Almeida Rosas <fabiano.rosas@suse.com>" [unknown] # 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: AA1B 48B0 A223 26A5 A4C3 64CF C798 DC74 1BEC 319D * tag 'migration-20250722-pull-request' of https://gitlab.com/farosas/qemu: crypto: add tracing & warning about GNUTLS countermeasures migration: activate TLS thread safety workaround io: add support for activating TLS thread safety workaround crypto: implement workaround for GNUTLS thread safety problems migration: show error message when postcopy fails migration: HMP: Fix postcopy latency distribution label migration: HMP: Fix possible out-of-bounds access Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
…o staging ppc queue: * Update maintainers # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEoPZlSPBIlev+awtgUaNDx8/77KEFAmiCMyUACgkQUaNDx8/7 # 7KEfqhAAvyOcR8r2bFfbLcOXWnHLgh+zjO5WlJpofMdktKK+AkzDK3oRZJHi8KtH # Xu+F68F2Qt2AFZC7K4ddI/6hT+ki78yTUCSCVr73YTa+R94iHlOIWn/8CaQJjNjU # FZPRIGQuGg5kNw0IJQj4qqo0qk77v2mkLhi0nuQ69mjuiCnydr2UWDrkaNCP9qtx # WwhcneTK5UIwelowWVBpV3E6aH8jo1psj9PyIn11nBaLmriFtcu4Uz1X3WG6ydxW # AKDDD5hBom9SwRMlKPNJjRqZ5ydDdMkgmRSrCCMWSv0m5wdvzbA3pqTPkl5Cc/o5 # IH8m/YAlF5mGAHbIBryys0OnCqMd7AiYjCdVrP14qc/Ccrar61v8rBMQo24qUDcB # NF6+4MlbgYMqns79VJftu7s/DI4p4R9cJmkInKNFGlpVIaDHYhENz3KTTszlntp2 # aV8fILK9oFpoQllgtFuSx89Ay2DG8kqU/D8OKR6haHXwdaFaKGMSyB+hoZ9+Iv3R # LNne5hGKr6p0j6k0kyIAXi11KS1i0mOg+Eha+v0fLqRqsIPt1Nt7ysRbxV+Yf6zc # zsxK4CR98FERKSlBbNtMU2sb3AJRamdX35+cGG8/lWq+RK5RbweCMBgHktLFW5/8 # BXPF2Ju0fZk5kvhxoJ0qg9SRU6t4C6kApSa/buKj22Ix/41KpWI= # =bWN6 # -----END PGP SIGNATURE----- # gpg: Signature made Thu 24 Jul 2025 09:20:37 EDT # gpg: using RSA key A0F66548F04895EBFE6B0B6051A343C7CFFBECA1 # gpg: Good signature from "Cédric Le Goater <clg@redhat.com>" [full] # gpg: aka "Cédric Le Goater <clg@kaod.org>" [full] # Primary key fingerprint: A0F6 6548 F048 95EB FE6B 0B60 51A3 43C7 CFFB ECA1 * tag 'pull-ppc-20250724' of https://github.com/legoater/qemu: MAINTAINERS: remove myself as ppc maintainer/reviewer MAINTAINERS: Remove Frédéric as reviewer MAINTAINERS: Add myself as a reviewer for XIVE MAINTAINERS: Add myself as a reviewer of PowerNV emulation MAINTAINERS: Add myself as reviewer for PowerPC TCG CPUs MAINTAINERS: Adding myself as reviewer for PPC KVM cpus. MAINTAINERS: Adding myself as a co-maintainer for ppc/spapr Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
…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>
…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>
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>
Table A-5 of the Intel manual incorrectly lists the third operand of VINSERTx128 as Wqq, but it is actually a 128-bit value. This is visible when W is a memory operand close to the end of the page. Fixes the recently-added poly1305_kunit test in linux-next. (No testcase yet, but I plan to modify test-avx2 to use memory close to the end of the page. This would work because the test vectors correctly have the memory operand as xmm2/m128). Reported-by: Eric Biggers <ebiggers@kernel.org> Tested-by: Eric Biggers <ebiggers@kernel.org> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: "Jason A. Donenfeld" <Jason@zx2c4.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: qemu-stable@nongnu.org Fixes: 7906847 ("target/i386: reimplement 0x0f 0x3a, add AVX", 2022-10-18) Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
A recent change to the kernel (Linux commit b376108e1f88 "arm64/fpsimd: signal: Clear TPIDR2 when delivering signals") updated the signal-handler entry code to always clear TPIDR2_EL0. This is necessary for the userspace ZA lazy saving scheme to work correctly when unwinding exceptions across a signal boundary. (For the essay-length description of the incorrect behaviour and why this is the correct fix, see the commit message for the kernel commit.) Make QEMU also clear TPIDR2_EL0 on signal entry, applying the equivalent bugfix to our implementation. Note that getting this unwinding to work correctly also requires changes to the userspace code, e.g. as implemented in gcc in https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b5ffc8e75a8 This change is technically an ABI change; from the kernel's point of view SME was never enabled (it was hidden behind CONFIG_BROKEN) before the change. From QEMU's point of view our SME-related signal handling was broken anyway as we weren't saving and restoring TPIDR2_EL0. Cc: qemu-stable@nongnu.org Fixes: 7801158 ("target/arm: Enable SME for user-only") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20250725175510.3864231-2-peter.maydell@linaro.org>
FEAT_SME adds the TPIDR2 userspace-accessible system register, which is used as part of the procedure calling standard's lazy saving scheme for the ZA registers: https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#66the-za-lazy-saving-scheme The Linux kernel has a signal frame record for saving and restoring this value when calling signal handlers, but we forgot to implement this. The result is that code which tries to unwind an exception out of a signal handler will not work correctly. Add support for the missing record. Cc: qemu-stable@nongnu.org Fixes: 7801158 ("target/arm: Enable SME for user-only") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20250725175510.3864231-3-peter.maydell@linaro.org>
FEAT_SME2 adds the ZT0 register, whose contents may need to be preserved and restored on signal handler entry and exit. This is done with a new ZT_MAGIC record. We forgot to implement support for this in our linux-user code before enabling the SME2p1 emulation, which meant that a signal handler using SME would corrupt the ZT0 register value, and code that attempted to unwind an exception from inside a signal handler would not work. Add the missing record handling. Fixes: 7b1613a ("target/arm: Enable FEAT_SME2p1 on -cpu max") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20250725175510.3864231-4-peter.maydell@linaro.org>
While we somewhat cover this later when we talk about supported operating systems make it clear in the front matter. Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-ID: <20250725154517.3523095-2-alex.bennee@linaro.org>
We don't ship the tarball and users should generally look to the distribution specific packaging. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/560 Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-ID: <20250725154517.3523095-3-alex.bennee@linaro.org>
This was a slightly duff format for rst, make it use proper headings. Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-ID: <20250725154517.3523095-4-alex.bennee@linaro.org>
Expand the description slightly and quote ioctl(). I did ponder mentioning something about why DRM ioctls are often missing but I see we have the I915 ones so I guess its just no one has done them. Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-ID: <20250725154517.3523095-5-alex.bennee@linaro.org>
Potentially too many weasel words when describing atomic and memory order issues. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-ID: <20250725154517.3523095-6-alex.bennee@linaro.org>
This is a simple test case that runs an image with kvmtool and kvm-unit-tests which can validate virtualisation works. This is useful for exercising TCG but can also be applied to any nested virt setup which is why it doesn't specify an accelerator. Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-ID: <20250725154517.3523095-7-alex.bennee@linaro.org>
It isn't testing anything and just expanding the runtime of testing. Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-ID: <20250725154517.3523095-8-alex.bennee@linaro.org>
We never actually used this is the end. Remove it to enable re-factoring. Fixes: 7cefff2 (tests/tcg: add mechanism to run specific tests with plugins) Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-ID: <20250725154517.3523095-9-alex.bennee@linaro.org>
Signed-off-by: Ankit Agrawal <ankita@nvidia.com> (cherry picked from commit 3f183b4 https://github.com/nvmochs/QEMU/tree/stable101_smmuv3-accel-07212025_egm) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
The Extended GPU Memory (EGM) feature [1] enables the GPU access to the local or remote system memory across sockets and nodes. In this mode, the physical memory can be allocated for GPU usage from anywhere in a multi-node system. The feature is being extended to virtualization. The EGM memory is exposed as a memory-backend-file backed by the nvgrace-egm module. The EGM node information such as the physical address, length and the proximity domain ID is populated in the ACPI DSDT entries for the GPU devices present on the same physical socket. A new qom object acpi-egm-memory is introduced to link the GPU devices to the EGM node. It is possible for the EGM memory to have memory pages with ECC errors, and such list is fetched using an ioctl provided by the nvgrace-egm module. VM DTB memory regions are built using the list by skipping such pages. The VM OS is thus prevented from using those pages. Link: https://developer.nvidia.com/blog/nvidia-grace-hopper-superchip-architecture-in-depth/#extended_gpu_memory [1] Ankit Agrawal (3): qom: New object to associate device to EGM node hw/acpi: Populate DSD tables with EGM properties hw/arm/boot: Create DTB memory regions skipping ECC error pages on EGM hw/acpi/acpi_egm_memory.c | 176 ++++++++++++++++++++++++++++++ hw/acpi/meson.build | 1 + hw/arm/boot.c | 129 ++++++++++++++++++++-- hw/pci-host/gpex-acpi.c | 5 + include/hw/acpi/acpi_egm_memory.h | 24 ++++ linux-headers/linux/egm.h | 20 ++++ qapi/qom.json | 17 +++ 7 files changed, 363 insertions(+), 9 deletions(-) create mode 100644 hw/acpi/acpi_egm_memory.c create mode 100644 include/hw/acpi/acpi_egm_memory.h create mode 100644 linux-headers/linux/egm.h -- 2.34.1 Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> (cherry picked from commit fab2732 https://github.com/nvmochs/QEMU/tree/stable101_smmuv3-accel-07212025_egm) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
The dma_map_file pathway doesn't fit into the kernel WAR that bypasses PFNMAP, resulting dma_map failures. Only the dma_map pathway could work. So retry with that upon a failure. Keep this WAR until the kernel WAR for PFNMAP is lifted. Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> (cherry picked from commit faff92d https://github.com/nvmochs/QEMU/tree/stable101_smmuv3-accel-07212025_egm) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
Add a new helper for IOMMU_VEVENTQ_ALLOC ioctl to allocate a virtual event queue (vEVENTQ) for a vIOMMU object. Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> (cherry picked from commit f5a9b37) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> [Shameer: aligned to other APIs] Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com> (cherry picked from commit 8e3b1cde5e0920c7a1798cc9149b313b6ca5c723 https://github.com/shamiali2008/qemu-master/tree/sep302025_nvidia_stable-10.1-vcmdq) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
Allocate a vIOMMU EventQ for SMMUv3 and start a thread to poll vEVENTs. Comments[Shameer]: -Need to check we need locking now across smmuv3_write_eventq() -Also check, it make sense to call smmuv3_record_event() instead. -io_uring instead of poll/read? Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> (cherry picked from commit f1e0af4) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> [Shameer: Rebased] Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com> (cherry picked from commit 801222ff069f59e8f6f727e0ceb0b89f1ce85b12 https://github.com/shamiali2008/qemu-master/tree/sep302025_nvidia_stable-10.1-vcmdq) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> (cherry picked from commit 9b15f92) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com> (cherry picked from commit c0dfa3c747e7da32a11680a2737bbba59f4e5f4a https://github.com/shamiali2008/qemu-master/tree/sep302025_nvidia_stable-10.1-vcmdq) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
This will be used by a later patch sanitizing a pyhsical address. Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> (cherry picked from commit 0fde7f8) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com> (cherry picked from commit 4d242b62aa6339e206f002ec20d059c761e8088b https://github.com/shamiali2008/qemu-master/tree/sep302025_nvidia_stable-10.1-vcmdq) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
The new uAPI supports input type to request a type-specific info v.s. the default type. Demand every caller to pass in a zero-ed type so it can set IOMMU_HW_INFO_FLAG_INPUT_TYPE upon a non-zero type. Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> (cherry picked from commit e60a652) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> [Shameer: Rebased] Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com> (cherry picked from commit 65b237d9c98663c53c175cc532cd778cb6077cbc https://github.com/shamiali2008/qemu-master/tree/sep302025_nvidia_stable-10.1-vcmdq) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
…to allow user ptr An IOMMU_VIOMMU_TYPE_TEGRA241_CMDQV iommufd vIOMMU object requires some private data given by the user space. So, the latest iommu_viommu_alloc ioctl supports a user ptr. Update the API accordingly. Also update its caller accordingly. Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> (cherry picked from commit 7c2923e) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> [Shameer: Rebased] Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com> (cherry picked from commit 1262e93c8f3125a947c8fc751c09e8fbe61d6581 https://github.com/shamiali2008/qemu-master/tree/sep302025_nvidia_stable-10.1-vcmdq) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
…ueue Allocate/free iommufd hw_queue object per viommu. Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> (cherry picked from commit 847ab0c) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> [Shameer: aligned to other APIs] Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com> (cherry picked from commit f8a13495e02f1220f5006767a312b1d223929509 https://github.com/shamiali2008/qemu-master/tree/sep302025_nvidia_stable-10.1-vcmdq) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
Allow to mmap a shared HW MMIO region via iommufd. Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> (cherry picked from commit 82fb4af) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> [Shameer: aligned to other APIs] Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com> (cherry picked from commit 48ad3efb96c519da16d15fa7e9daeac59bfe39b7 https://github.com/shamiali2008/qemu-master/tree/sep302025_nvidia_stable-10.1-vcmdq) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
Add an initial device model of NVIDIA Tegra241 CMDQV, an extension for ARM SMMUv3. It supports passthroughs of physical SMMU-CMDQ liked command queue from host space to a VM. Note[Shameer]: -tegra241_cmdqv_init() has an ordering dependency now as it maps mmio space and it should be after SMMUv3 mmio map calls. -Stub functions for !defined TEGRA241_CMDQV -Pre-bake CMDQV_NUM_CMDQ_LOG2/_NUM_SID_PER_VM_LOG2/_VERSION and validate on device plug Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> (cherry picked from commit cef37ba) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> [Shameer: Heavily rebased] Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com> (cherry picked from commit a36918bd3e35f8656126ca82efc88762219bda07 https://github.com/shamiali2008/qemu-master/tree/sep302025_nvidia_stable-10.1-vcmdq) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
…stem RAM To ensure the memory backing up the guest RAM is contiguous physically, cap the CMDQ size to the page size of the system. This can be a huge page size, so long as the VM is configured properly. Note[Shameer]: -Probably needs to do a validation of this with host CMDQ size. For now, GB and QEMU default CMDQ size is same(19). Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> (cherry picked from commit 3503108) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> [Shameer: rebased] Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com> (cherry picked from commit 562b8ed8b4bac63d63f024f0afa1ec19ebbfaf2c https://github.com/shamiali2008/qemu-master/tree/sep302025_nvidia_stable-10.1-vcmdq) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
The smmuv3_devs list, if there is an accel type of SMMUv3 device, will be used by both the IORT and DSDT. Since DSDT is the first table to build in the virt_acpi_build(). The list built for IORT cann't be used in advance. Prebuild a smmuv3_devs list and carry in the AcpiBuildTables structure. Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> (cherry picked from commit 7ae055e) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com> (cherry picked from commit c7e0143ba57724670a1c477863f30062966d8562 https://github.com/shamiali2008/qemu-master/tree/sep302025_nvidia_stable-10.1-vcmdq) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
Add CMDQV device tree nodes and Dsdt if there is a support in the VM. This will be an SMMUv3 add-on feature, so each CMDQV device will be tied to an existing SMMUv3 device (accel=on). Also add two virt_acpi_ tracers for debugging. Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> (cherry picked from commit 2b9514f) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com> (cherry picked from commit 3c672632f9d54a9fd6914f2222036693d8ed6332 https://github.com/shamiali2008/qemu-master/tree/sep302025_nvidia_stable-10.1-vcmdq) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
Testing command:
cmdqv=",cmdqv=on"
vm_image="/home/nicolinc/vm2-nic.qcow2"
qemu-system-aarch64 \
-object iommufd,id=iommufd0 \
-machine hmat=on -machine virt,accel=kvm,gic-version=3,ras=on,highmem-mmio-size=4T \
-cpu host -smp cpus=62 -m size=16G,slots=2,maxmem=256G -nographic \
-object memory-backend-file,size=8G,id=m0,mem-path=/hugepages/,prealloc=on,share=on \
-object memory-backend-file,size=8G,id=m1,mem-path=/hugepages/,prealloc=on,share=on \
-numa node,memdev=m0,cpus=0-61,nodeid=0 -numa node,memdev=m1,nodeid=1 \
-numa node,nodeid=2 -numa node,nodeid=3 -numa node,nodeid=4 -numa node,nodeid=5 \
-numa node,nodeid=6 -numa node,nodeid=7 -numa node,nodeid=8 -numa node,nodeid=9 \
-numa node,nodeid=10 -numa node,nodeid=11 -numa node,nodeid=12 -numa node,nodeid=13 \
-numa node,nodeid=14 -numa node,nodeid=15 -numa node,nodeid=16 -numa node,nodeid=17 \
-numa node,nodeid=18 -numa node,nodeid=19 -numa node,nodeid=20 -numa node,nodeid=21 \
-numa node,nodeid=22 -numa node,nodeid=23 -numa node,nodeid=24 -numa node,nodeid=25 \
-numa node,nodeid=26 -numa node,nodeid=27 -numa node,nodeid=28 -numa node,nodeid=29 \
-numa node,nodeid=30 -numa node,nodeid=31 -numa node,nodeid=32 -numa node,nodeid=33 \
-device pxb-pcie,id=pcie.1,bus_nr=1,bus=pcie.0 \
-device arm-smmuv3,primary-bus=pcie.1,id=smmuv3.1,accel=on,ats=on,ril=off,pasid=on,oas=48${cmdqv} \
-device pcie-root-port,id=pcie.port1,bus=pcie.1,chassis=1,io-reserve=0 \
-device vfio-pci-nohotplug,host=0009:01:00.0,bus=pcie.port1,rombar=0,id=dev0,iommufd=iommufd0 \
-object acpi-generic-initiator,id=gi0,pci-dev=dev0,node=2 \
-object acpi-generic-initiator,id=gi1,pci-dev=dev0,node=3 \
-object acpi-generic-initiator,id=gi2,pci-dev=dev0,node=4 \
-object acpi-generic-initiator,id=gi3,pci-dev=dev0,node=5 \
-object acpi-generic-initiator,id=gi4,pci-dev=dev0,node=6 \
-object acpi-generic-initiator,id=gi5,pci-dev=dev0,node=7 \
-object acpi-generic-initiator,id=gi6,pci-dev=dev0,node=8 \
-object acpi-generic-initiator,id=gi7,pci-dev=dev0,node=9 \
-device pxb-pcie,id=pcie.9,bus_nr=9,bus=pcie.0 \
-device arm-smmuv3,primary-bus=pcie.9,id=smmuv3.2,accel=on,ats=on,ril=off,pasid=on,oas=48${cmdqv} \
-device pcie-root-port,id=pcie.port9,bus=pcie.9,chassis=2,io-reserve=0 \
-device vfio-pci-nohotplug,host=0019:01:00.0,bus=pcie.port9,rombar=0,id=dev1,iommufd=iommufd0 \
-object acpi-generic-initiator,id=gi8,pci-dev=dev1,node=10 \
-object acpi-generic-initiator,id=gi9,pci-dev=dev1,node=11 \
-object acpi-generic-initiator,id=gi10,pci-dev=dev1,node=12 \
-object acpi-generic-initiator,id=gi11,pci-dev=dev1,node=13 \
-object acpi-generic-initiator,id=gi12,pci-dev=dev1,node=14 \
-object acpi-generic-initiator,id=gi13,pci-dev=dev1,node=15 \
-object acpi-generic-initiator,id=gi14,pci-dev=dev1,node=16 \
-object acpi-generic-initiator,id=gi15,pci-dev=dev1,node=17 \
-device pxb-pcie,id=pcie.17,bus_nr=17,bus=pcie.0 \
-device arm-smmuv3,primary-bus=pcie.17,id=smmuv3.3,accel=on,ats=on,ril=off,pasid=on,oas=48${cmdqv} \
-device pcie-root-port,id=pcie.port17,bus=pcie.17,chassis=3,io-reserve=0 \
-device vfio-pci-nohotplug,host=0029:01:00.0,bus=pcie.port17,rombar=0,id=dev2,iommufd=iommufd0 \
-object acpi-generic-initiator,id=gi16,pci-dev=dev2,node=18 \
-object acpi-generic-initiator,id=gi17,pci-dev=dev2,node=19 \
-object acpi-generic-initiator,id=gi18,pci-dev=dev2,node=20 \
-object acpi-generic-initiator,id=gi19,pci-dev=dev2,node=21 \
-object acpi-generic-initiator,id=gi20,pci-dev=dev2,node=22 \
-object acpi-generic-initiator,id=gi21,pci-dev=dev2,node=23 \
-object acpi-generic-initiator,id=gi22,pci-dev=dev2,node=24 \
-object acpi-generic-initiator,id=gi23,pci-dev=dev2,node=25 \
-device pxb-pcie,id=pcie.25,bus_nr=25,bus=pcie.0 \
-device arm-smmuv3,primary-bus=pcie.25,id=smmuv3.4,accel=on,ats=on,ril=off,pasid=on,oas=48${cmdqv} \
-device pcie-root-port,id=pcie.port25,bus=pcie.25,chassis=4,io-reserve=0 \
-device vfio-pci-nohotplug,host=0039:01:00.0,bus=pcie.port25,rombar=0,id=dev3,iommufd=iommufd0 \
-object acpi-generic-initiator,id=gi24,pci-dev=dev3,node=26 \
-object acpi-generic-initiator,id=gi25,pci-dev=dev3,node=27 \
-object acpi-generic-initiator,id=gi26,pci-dev=dev3,node=28 \
-object acpi-generic-initiator,id=gi27,pci-dev=dev3,node=29 \
-object acpi-generic-initiator,id=gi28,pci-dev=dev3,node=30 \
-object acpi-generic-initiator,id=gi29,pci-dev=dev3,node=31 \
-object acpi-generic-initiator,id=gi30,pci-dev=dev3,node=32 \
-object acpi-generic-initiator,id=gi31,pci-dev=dev3,node=33 \
-bios /usr/share/AAVMF/AAVMF_CODE.fd \
-device nvme,drive=nvme0,serial=deadbeaf1,bus=pcie.0 \
-drive file=${vm_image},index=0,media=disk,format=qcow2,if=none,id=nvme0 \
-device e1000,romfile=/home/nicolinc/efi-e1000.rom,netdev=net0,bus=pcie.0 \
-netdev user,id=net0,hostfwd=tcp::5558-:22,hostfwd=tcp::5586-:5586
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
(cherry picked from commit be26efe)
Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com>
--
2.43.0
(cherry picked from commit dbb463f189c4211c9fb02348cddaa882f10dd28b https://github.com/shamiali2008/qemu-master/tree/sep302025_nvidia_stable-10.1-vcmdq)
Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
Add debian folder from Ubuntu Noble QEMU: https://git.launchpad.net/ubuntu/+source/qemu/tree/?h=ubuntu/noble Tag: import/1%8.2.2+ds-0ubuntu1.10 HEAD commit: bc0011afab01 1:8.2.2+ds-0ubuntu1.10 (patches unapplied) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
debian/control: debian/control-in: - Added dependency support for meson-1.5 (required by v10.1) - Added NVIDIA as maintainer debian/patches/*: debian/patches/series: - Remove all Debian/Ubuntu patches debian/rules: - Removed pvrdma and cris/nios2 architectures (removed since v8.2) - Disabled firmware builds debian/qemu-system-common.install: - Remove obsolete files (removed since v8.2) - Added hw-uefi-vars.so (added since v8.2) debian/rules: - Removed pvrdma and cris/nios2 architectures (removed since v8.2) - Disabled firmware builds Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
QEMU is particularly challenging to package due to its multiple subprojects that ship binary files. To simplify and speed up maintenance, allow binaries to be included in the source package. Signed-off-by: Andrea Righi <arighi@nvidia.com> Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
This fixes a build failure in PPA environments where dh_missing reports DTB files exist in debian/tmp but are not installed to any package. QEMU 10.1's Meson build has a bug where it ignores the install_blobs=false option when dtc is not found, causing DTB files to be auto-installed to usr/share/qemu/dtb/. This creates inconsistent behavior between local builds (with dtc installed) and PPA builds (without dtc). Changes: 1. Add qemu-system-data.install with PPC DTBs (bamboo, canyonlands) 2. Add qemu-system-misc.install with MicroBlaze DTBs (petalogix-ml605, petalogix-s3adsp1800) 3. Update debian/rules install-misc paths to usr/share/qemu/dtb/ 4. Patch pc-bios/dtb/meson.build to disable dtc detection, forcing use of pre-built files 5. Update debian/rules build-misc to copy pre-built DTBs instead of compiling 6. Uncomment sysdata-components += misc to enable manual DTB installation This ensures both local (with dtc) and PPA (without dtc) builds behave identically by always using pre-built DTB files from pc-bios/dtb/. Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
Introduce debian/build-deb-from-git.sh to automate the creation of the orig tarball from the Git repository for packaging purposes. Signed-off-by: Andrea Righi <arighi@nvidia.com> Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
…ility Remove CONFIG options that are incompatible with QEMU 10.1's Kconfig: - CONFIG_Q35=y: conflicts with CONFIG_PCI_DEVICES=n - CONFIG_VIRTIO_MEM=y: requires VIRTIO_MD_SUPPORTED (not available for microvm) - CONFIG_VIRTIO_PMEM=y: requires VIRTIO_MD_SUPPORTED (not available for microvm) This brings the configuration in line with Ubuntu's QEMU 10.1 packaging and fixes the amd64 PPA build failure where minikconf.py was failing with 'contradiction between clauses' errors. Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
The --enable-avx2 option was removed in QEMU 10.1. This option no longer exists in the configure script, causing the xen build to fail with: ERROR: unknown option --enable-avx2 Ubuntu's QEMU 10.1 packaging (questing) also removed this option from the xen build configuration. This fixes the amd64 PPA build failure in the xen configuration stage. Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
The microvm build target creates the binary directly in b/microvm/qemu-system-x86_64, not in a subdirectory. The install-microvm target was looking in the wrong location: Wrong: b/microvm/x86_64-softmmu/qemu-system-x86_64 Correct: b/microvm/qemu-system-x86_64 This matches Ubuntu's QEMU 10.1 packaging and fixes the amd64 build failure: cp: cannot stat 'b/microvm/x86_64-softmmu/qemu-system-x86_64': No such file or directory Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
qemu-vmsr-helper is a VMware-specific tool new in QEMU 10.1 that provides VMware VMSR (Virtual Machine Service Registry) compatibility features. Since this is not needed for NVIDIA QEMU, we exclude it from the package by adding it to debian/not-installed. This fixes the dh_missing error: usr/bin/qemu-vmsr-helper exists in debian/tmp but is not installed to anywhere Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
Adds a GitHub Action pipeline to automatically build a source package that can be signed and uploaded to an LP builder Signed-off-by: Mitchell Augustin <mitchell.augustin@canonical.com> Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
During creation of the VM's SRAT table, the generic intiator entries are added. Currently, the code queries the object, which may not be in the sorted order. This results in the mismatch in the VMs view of the PXM and the numa node ids. As a fix, the patch builds a list of generic intiator objects, sorts them and then put it in the VM's SRAT table. Signed-off-by: Ankit Agrawal <ankita@nvidia.com>
Qemu's determination of the VMA address for a region needs an update to handle regions that may be a BAR, but with the actual size of the mapping to not be at a power-of-2 alignment. This happens for the case of Grace based systems, where the device memory is exposed as a BAR. The mapping however is only of the size of the actual physical memory, which may not be a power-of-2 aligned. This affects hugepfnmap mappings on such regions. The current algorithm determines the VMA address alignment based on the mapping alignment. This needs change so as to be based on the next power-of-2 of the mapping size. This patch updates the algorithm to achieve the alignment. Signed-off-by: Ankit Agrawal <ankita@nvidia.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Address the following bugs: