aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-01-29Update version for 8.2.1 releasev8.2.1Michael Tokarev
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-27target/arm: Fix incorrect aa64_tidcp1 feature checkPeter Maydell
A typo in the implementation of isar_feature_aa64_tidcp1() means we were checking the field in the wrong ID register, so we might have provided the feature on CPUs that don't have it and not provided it on CPUs that should have it. Correct this bug. Cc: qemu-stable@nongnu.org Fixes: 9cd0c0dec97be9 "target/arm: Implement FEAT_TIDCP1" Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2120 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20240123160333.958841-1-peter.maydell@linaro.org (cherry picked from commit ee0a2e3c9d2991a11c13ffadb15e4d0add43c257) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-27target/arm: Fix A64 scalar SQSHRN and SQRSHRNPeter Maydell
In commit 1b7bc9b5c8bf374dd we changed handle_vec_simd_sqshrn() so that instead of starting with a 0 value and depositing in each new element from the narrowing operation, it instead started with the raw result of the narrowing operation of the first element. This is fine in the vector case, because the deposit operations for the second and subsequent elements will always overwrite any higher bits that might have been in the first element's result value in tcg_rd. However in the scalar case we only go through this loop once. The effect is that for a signed narrowing operation, if the result is negative then we will now return a value where the bits above the first element are incorrectly 1 (because the narrowfn returns a sign-extended result, not one that is truncated to the element size). Fix this by using an extract operation to get exactly the correct bits of the output of the narrowfn for element 1, instead of a plain move. Cc: qemu-stable@nongnu.org Fixes: 1b7bc9b5c8bf374dd3 ("target/arm: Avoid tcg_const_ptr in handle_vec_simd_sqshrn") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2089 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20240123153416.877308-1-peter.maydell@linaro.org (cherry picked from commit 6fffc8378562c7fea6290c430b4f653f830a4c1a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-27target/xtensa: fix OOB TLB entry accessMax Filippov
r[id]tlb[01], [iw][id]tlb opcodes use TLB way index passed in a register by the guest. The host uses 3 bits of the index for ITLB indexing and 4 bits for DTLB, but there's only 7 entries in the ITLB array and 10 in the DTLB array, so a malicious guest may trigger out-of-bound access to these arrays. Change split_tlb_entry_spec return type to bool to indicate whether TLB way passed to it is valid. Change get_tlb_entry to return NULL in case invalid TLB way is requested. Add assertion to xtensa_tlb_get_entry that requested TLB way and entry indices are valid. Add checks to the [rwi]tlb helpers that requested TLB way is valid and return 0 or do nothing when it's not. Cc: qemu-stable@nongnu.org Fixes: b67ea0cd7441 ("target-xtensa: implement memory protection options") Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20231215120307.545381-1-jcmvbkbc@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 604927e357c2b292c70826e4ce42574ad126ef32) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-26qtest: bump aspeed_smc-test timeout to 6 minutesDaniel P. Berrangé
On a loaded system with --enable-debug, this test can take longer than 5 minutes. Raising the timeout to 6 minutes gives greater headroom for such situations. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> [thuth: Increase the timeout to 6 minutes for very loaded systems] Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20231215070357.10888-11-thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> (cherry picked from commit e8a12fe31f776c60fec993513cd1b1e66c2b8e29) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: context fixup in tests/qtest/meson.build)
2024-01-26monitor: only run coroutine commands in qemu_aio_contextStefan Hajnoczi
monitor_qmp_dispatcher_co() runs in the iohandler AioContext that is not polled during nested event loops. The coroutine currently reschedules itself in the main loop's qemu_aio_context AioContext, which is polled during nested event loops. One known problem is that QMP device-add calls drain_call_rcu(), which temporarily drops the BQL, leading to all sorts of havoc like other vCPU threads re-entering device emulation code while another vCPU thread is waiting in device emulation code with aio_poll(). Paolo Bonzini suggested running non-coroutine QMP handlers in the iohandler AioContext. This avoids trouble with nested event loops. His original idea was to move coroutine rescheduling to monitor_qmp_dispatch(), but I resorted to moving it to qmp_dispatch() because we don't know if the QMP handler needs to run in coroutine context in monitor_qmp_dispatch(). monitor_qmp_dispatch() would have been nicer since it's associated with the monitor implementation and not as general as qmp_dispatch(), which is also used by qemu-ga. A number of qemu-iotests need updated .out files because the order of QMP events vs QMP responses has changed. Solves Issue #1933. Cc: qemu-stable@nongnu.org Fixes: 7bed89958bfbf40df9ca681cefbdca63abdde39d ("device_core: use drain_call_rcu in in qmp_device_add") Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2215192 Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2214985 Buglink: https://issues.redhat.com/browse/RHEL-17369 Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20240118144823.1497953-4-stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Tested-by: Fiona Ebner <f.ebner@proxmox.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit effd60c878176bcaf97fa7ce2b12d04bb8ead6f7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-26iotests: port 141 to Python for reliable QMP testingStefan Hajnoczi
The common.qemu bash functions allow tests to interact with the QMP monitor of a QEMU process. I spent two days trying to update 141 when the order of the test output changed, but found it would still fail occassionally because printf() and QMP events race with synchronous QMP communication. I gave up and ported 141 to the existing Python API for QMP tests. The Python API is less affected by the order in which QEMU prints output because it does not print all QMP traffic by default. The next commit changes the order in which QMP messages are received. Make 141 reliable first. Cc: Hanna Czenczek <hreitz@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20240118144823.1497953-3-stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 9ee2dd4c22a3639c5462b3fc20df60c005c3de64) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-26iotests: add filter_qmp_generated_node_ids()Stefan Hajnoczi
Add a filter function for QMP responses that contain QEMU's automatically generated node ids. The ids change between runs and must be masked in the reference output. The next commit will use this new function. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20240118144823.1497953-2-stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit da62b507a20510d819bcfbe8f5e573409b954006) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-26block/blklogwrites: Fix a bug when logging "write zeroes" operations.Ari Sundholm
There is a bug in the blklogwrites driver pertaining to logging "write zeroes" operations, causing log corruption. This can be easily observed by setting detect-zeroes to something other than "off" for the driver. The issue is caused by a concurrency bug pertaining to the fact that "write zeroes" operations have to be logged in two parts: first the log entry metadata, then the zeroed-out region. While the log entry metadata is being written by bdrv_co_pwritev(), another operation may begin in the meanwhile and modify the state of the blklogwrites driver. This is as intended by the coroutine-driven I/O model in QEMU, of course. Unfortunately, this specific scenario is mishandled. A short example: 1. Initially, in the current operation (#1), the current log sector number in the driver state is only incremented by the number of sectors taken by the log entry metadata, after which the log entry metadata is written. The current operation yields. 2. Another operation (#2) may start while the log entry metadata is being written. It uses the current log position as the start offset for its log entry. This is in the sector right after the operation #1 log entry metadata, which is bad! 3. After bdrv_co_pwritev() returns (#1), the current log sector number is reread from the driver state in order to find out the start offset for bdrv_co_pwrite_zeroes(). This is an obvious blunder, as the offset will be the sector right after the (misplaced) operation #2 log entry, which means that the zeroed-out region begins at the wrong offset. 4. As a result of the above, the log is corrupt. Fix this by only reading the driver metadata once, computing the offsets and sizes in one go (including the optional zeroed-out region) and setting the log sector number to the appropriate value for the next operation in line. Signed-off-by: Ari Sundholm <ari@tuxera.com> Cc: qemu-stable@nongnu.org Message-ID: <20240109184646.1128475-1-megari@gmx.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit a9c8ea95470c27a8a02062b67f9fa6940e828ab6) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-26virtio-net: correctly copy vnet header when flushing TXJason Wang
When HASH_REPORT is negotiated, the guest_hdr_len might be larger than the size of the mergeable rx buffer header. Using virtio_net_hdr_mrg_rxbuf during the header swap might lead a stack overflow in this case. Fixing this by using virtio_net_hdr_v1_hash instead. Reported-by: Xiao Lei <leixiao.nop@zju.edu.cn> Cc: Yuri Benditovich <yuri.benditovich@daynix.com> Cc: qemu-stable@nongnu.org Cc: Mauro Matteo Cascella <mcascell@redhat.com> Fixes: CVE-2023-6693 Fixes: e22f0603fb2f ("virtio-net: reference implementation of hash report") Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit 2220e8189fb94068dbad333228659fbac819abb0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-25tcg/arm: Fix SIGILL in tcg_out_qemu_st_directJoseph Burt
When tcg_out_qemu_st_{index,direct} were merged, the direct case for MO_64 was omitted, causing qemu_st_i64 to be encoded as 0xffffffff due to underflow when adding h.base and h.index. Fixes: 1df6d611bdc2 ("tcg/arm: Introduce HostAddress") Signed-off-by: Joseph Burt <caseorum@gmail.com> Message-Id: <20240121211439.100829-1-caseorum@gmail.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 9f6523e8e4689cafdbed7c10b7cf7c775b5a607b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-25linux-user/riscv: Adjust vdso signal frame cfa offsetsRichard Henderson
A typo in sizeof_reg put the registers at the wrong offset. Simplify the expressions to use positive addresses from the start of uc_mcontext instead of negative addresses from the end of uc_mcontext. Reported-by: Vineet Gupta <vineetg@rivosinc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 1b21fe27e75a59bfe2513f5abcc6a18cfc35cfc8) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-25linux-user: Fixed cpu restore with pc 0 on SIGBUSRobbin Ehn
Commit f4e1168198 (linux-user: Split out host_sig{segv,bus}_handler) introduced a bug, when returning from host_sigbus_handler the PC is never set. Thus cpu_loop_exit_restore is called with a zero PC and we immediate get a SIGSEGV. Signed-off-by: Robbin Ehn <rehn@rivosinc.com> Fixes: f4e1168198 ("linux-user: Split out host_sig{segv,bus}_handler") Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com> Message-Id: <33f27425878fb529b9e39ef22c303f6e0d90525f.camel@rivosinc.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 6d913158b5023ac948b8fd649d77fc86e28072f6) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-25block/io: clear BDRV_BLOCK_RECURSE flag after recursing in bdrv_co_block_statusFiona Ebner
Using fleecing backup like in [0] on a qcow2 image (with metadata preallocation) can lead to the following assertion failure: > bdrv_co_do_block_status: Assertion `!(ret & BDRV_BLOCK_ZERO)' failed. In the reproducer [0], it happens because the BDRV_BLOCK_RECURSE flag will be set by the qcow2 driver, so the caller will recursively check the file child. Then the BDRV_BLOCK_ZERO set too. Later up the call chain, in bdrv_co_do_block_status() for the snapshot-access driver, the assertion failure will happen, because both flags are set. To fix it, clear the recurse flag after the recursive check was done. In detail: > #0 qcow2_co_block_status Returns 0x45 = BDRV_BLOCK_RECURSE | BDRV_BLOCK_DATA | BDRV_BLOCK_OFFSET_VALID. > #1 bdrv_co_do_block_status Because of the data flag, bdrv_co_do_block_status() will now also set BDRV_BLOCK_ALLOCATED. Because of the recurse flag, bdrv_co_do_block_status() for the bdrv_file child will be called, which returns 0x16 = BDRV_BLOCK_ALLOCATED | BDRV_BLOCK_OFFSET_VALID | BDRV_BLOCK_ZERO. Now the return value inherits the zero flag. Returns 0x57 = BDRV_BLOCK_RECURSE | BDRV_BLOCK_DATA | BDRV_BLOCK_OFFSET_VALID | BDRV_BLOCK_ALLOCATED | BDRV_BLOCK_ZERO. > #2 bdrv_co_common_block_status_above > #3 bdrv_co_block_status_above > #4 bdrv_co_block_status > #5 cbw_co_snapshot_block_status > #6 bdrv_co_snapshot_block_status > #7 snapshot_access_co_block_status > #8 bdrv_co_do_block_status Return value is propagated all the way up to here, where the assertion failure happens, because BDRV_BLOCK_RECURSE and BDRV_BLOCK_ZERO are both set. > #9 bdrv_co_common_block_status_above > #10 bdrv_co_block_status_above > #11 block_copy_block_status > #12 block_copy_dirty_clusters > #13 block_copy_common > #14 block_copy_async_co_entry > #15 coroutine_trampoline [0]: > #!/bin/bash > rm /tmp/disk.qcow2 > ./qemu-img create /tmp/disk.qcow2 -o preallocation=metadata -f qcow2 1G > ./qemu-img create /tmp/fleecing.qcow2 -f qcow2 1G > ./qemu-img create /tmp/backup.qcow2 -f qcow2 1G > ./qemu-system-x86_64 --qmp stdio \ > --blockdev qcow2,node-name=node0,file.driver=file,file.filename=/tmp/disk.qcow2 \ > --blockdev qcow2,node-name=node1,file.driver=file,file.filename=/tmp/fleecing.qcow2 \ > --blockdev qcow2,node-name=node2,file.driver=file,file.filename=/tmp/backup.qcow2 \ > <<EOF > {"execute": "qmp_capabilities"} > {"execute": "blockdev-add", "arguments": { "driver": "copy-before-write", "file": "node0", "target": "node1", "node-name": "node3" } } > {"execute": "blockdev-add", "arguments": { "driver": "snapshot-access", "file": "node3", "node-name": "snap0" } } > {"execute": "blockdev-backup", "arguments": { "device": "snap0", "target": "node1", "sync": "full", "job-id": "backup0" } } > EOF Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Message-id: 20240116154839.401030-1-f.ebner@proxmox.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> (cherry picked from commit 8a9be7992426c8920d4178e7dca59306a18c7a3a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-25coroutine-ucontext: Save fake stack for pooled coroutineAkihiko Odaki
Coroutine may be pooled even after COROUTINE_TERMINATE if CONFIG_COROUTINE_POOL is enabled and fake stack should be saved in such a case to keep AddressSanitizerUseAfterReturn working. Even worse, I'm seeing stack corruption without fake stack being saved. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20240117-asan-v2-1-26f9e1ea6e72@daynix.com> (cherry picked from commit d9945ccda08ef83b09ac7725b6ee2d1959f2c0c0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-25tcg/s390x: Fix encoding of VRIc, VRSa, VRSc insnsRichard Henderson
While the format names the second vector register 'v3', it is still in the second position (bits 12-15) and the argument to RXB must match. Example error: - e7 00 00 10 2a 33 verllf %v16,%v0,16 + e7 00 00 10 2c 33 verllf %v16,%v16,16 Cc: qemu-stable@nongnu.org Reported-by: Michael Tokarev <mjt@tls.msk.ru> Fixes: 22cb37b4172 ("tcg/s390x: Implement vector shift operations") Fixes: 79cada8693d ("tcg/s390x: Implement tcg_out_dup*_vec") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2054 Reviewed-by: Thomas Huth <thuth@redhat.com> Tested-by: Michael Tokarev <mjt@tls.msk.ru> Message-Id: <20240117213646.159697-2-richard.henderson@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit c1ddc18f37108498f45d57afd6bf33a23b703648) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-25accel/tcg: Revert mapping of PCREL translation block to multiple virtual ↵Paolo Bonzini
addresses This is causing regressions that have not been analyzed yet. Revert the change on stable branches. Cc: qemu-stable@nongnu.org Cc: Michael Tokarev <mjt@tls.msk.ru> Related: https://gitlab.com/qemu-project/qemu/-/issues/2092 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-24acpi/tests/avocado/bits: wait for 200 seconds for SHUTDOWN event from bits VMAni Sinha
By default, the timeout to receive any specified event from the QEMU VM is 60 seconds set by the python avocado test framework. Please see event_wait() and events_wait() in python/qemu/machine/machine.py. If the matching event is not triggered within that interval, an asyncio.TimeoutError is generated. Since the timeout for the bits avocado test is 200 secs, we need to make event_wait() timeout of the same value as well so that an early timeout is not triggered by the avocado framework. CC: peter.maydell@linaro.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2077 Signed-off-by: Ani Sinha <anisinha@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-id: 20240117042556.3360190-1-anisinha@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 7ef4c41e91d59d72a3b8bc022a6cb3e81787a50a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-22s390x/pci: drive ISM reset from subsystem resetMatthew Rosato
ISM devices are sensitive to manipulation of the IOMMU, so the ISM device needs to be reset before the vfio-pci device is reset (triggering a full UNMAP). In order to ensure this occurs, trigger ISM device resets from subsystem_reset before triggering the PCI bus reset (which will also trigger vfio-pci reset). This only needs to be done for ISM devices which were enabled for use by the guest. Further, ensure that AIF is disabled as part of the reset event. Fixes: ef1535901a ("s390x: do a subsystem reset before the unprotect on reboot") Fixes: 03451953c7 ("s390x/pci: reset ISM passthrough devices on shutdown and system reset") Reported-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Message-ID: <20240118185151.265329-4-mjrosato@linux.ibm.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 68c691ca99a2538d6a53a70ce8a9ce06ee307ff1) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-22s390x/pci: refresh fh before disabling aifMatthew Rosato
Typically we refresh the host fh during CLP enable, however it's possible that the device goes through multiple reset events before the guest performs another CLP enable. Let's handle this for now by refreshing the host handle from vfio before disabling aif. Fixes: 03451953c7 ("s390x/pci: reset ISM passthrough devices on shutdown and system reset") Reported-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Message-ID: <20240118185151.265329-3-mjrosato@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 30e35258e25c75c9d799c34fd89afcafffb37084) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-22s390x/pci: avoid double enable/disable of aifMatthew Rosato
Use a flag to keep track of whether AIF is currently enabled. This can be used to avoid enabling/disabling AIF multiple times as well as to determine whether or not it should be disabled during reset processing. Fixes: d0bc7091c2 ("s390x/pci: enable adapter event notification for interpreted devices") Reported-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Message-ID: <20240118185151.265329-2-mjrosato@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 07b2c8e034d80ff92e202405c494d2ff80fcf848) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-20hw/scsi/esp-pci: set DMA_STAT_BCMBLT when BLAST command issuedMark Cave-Ayland
Even though the BLAST command isn't fully implemented in QEMU, the DMA_STAT_BCMBLT bit should be set after the command has been issued to indicate that the command has completed. This fixes an issue with the DC390 DOS driver which issues the BLAST command as part of its normal error recovery routine at startup, and otherwise sits in a tight loop waiting for DMA_STAT_BCMBLT to be set before continuing. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Guenter Roeck <linux@roeck-us.net> Message-ID: <20240112131529.515642-5-mark.cave-ayland@ilande.co.uk> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit c2d7de557d19ec76eb83b87b6bf77c8114e2f183) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-20hw/scsi/esp-pci: synchronise setting of DMA_STAT_DONE with ESP completion ↵Mark Cave-Ayland
interrupt The setting of DMA_STAT_DONE at the end of a DMA transfer can be configured to generate an interrupt, however the Linux driver manually checks for DMA_STAT_DONE being set and if it is, considers that a DMA transfer has completed. If DMA_STAT_DONE is set but the ESP device isn't indicating an interrupt then the Linux driver considers this to be a spurious interrupt. However this can occur in QEMU as there is a delay between the end of DMA transfer where DMA_STAT_DONE is set, and the ESP device raising its completion interrupt. This appears to be an incorrect assumption in the Linux driver as the ESP and PCI DMA interrupt sources are separate (and may not be raised exactly together), however we can work around this by synchronising the setting of DMA_STAT_DONE at the end of a DMA transfer with the ESP completion interrupt. In conjunction with the previous commit Linux is now able to correctly boot from an am53c974 PCI SCSI device on the hppa C3700 machine without emitting "iget: checksum invalid" and "Spurious irq, sreg=10" errors. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Guenter Roeck <linux@roeck-us.net> Message-ID: <20240112131529.515642-4-mark.cave-ayland@ilande.co.uk> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 1e8e6644e063b20ad391140fae13d00ad7750b33) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-20hw/scsi/esp-pci: generate PCI interrupt from separate ESP and PCI sourcesMark Cave-Ayland
The am53c974/dc390 PCI interrupt has two separate sources: the first is from the internal ESP device, and the second is from the PCI DMA transfer logic. Update the ESP interrupt handler so that it sets DMA_STAT_SCSIINT rather than driving the PCI IRQ directly, and introduce a new esp_pci_update_irq() function to generate the correct PCI IRQ level. In particular this fixes spurious interrupts being generated by setting DMA_STAT_DONE at the end of a transfer if DMA_CMD_INTE_D isn't set in the DMA_CMD register. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Guenter Roeck <linux@roeck-us.net> Message-ID: <20240112131529.515642-3-mark.cave-ayland@ilande.co.uk> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 6b41417d934b2640b7ccf893544d656eea92a2e7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-20hw/scsi/esp-pci: use correct address register for PCI DMA transfersMark Cave-Ayland
The current code in esp_pci_dma_memory_rw() sets the DMA address to the value of the DMA_SPA (Starting Physical Address) register which is incorrect: this means that for each callback from the SCSI layer the DMA address is set back to the starting address. In the case where only a single SCSI callback occurs (currently for transfer lengths < 128kB) this works fine, however for larger transfers the DMA address wraps back to the initial starting address, corrupting the buffer holding the data transferred to the guest. Fix esp_pci_dma_memory_rw() to use the DMA_WAC (Working Address Counter) for the DMA address which is correctly incremented across multiple SCSI layer transfers. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Guenter Roeck <linux@roeck-us.net> Message-ID: <20240112131529.515642-2-mark.cave-ayland@ilande.co.uk> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 84a6835e004c257037492167d4f266dbb54dc33e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-20migration/rdma: define htonll/ntohll only if not predefinedNick Briggs
Solaris has #defines for htonll and ntohll which cause syntax errors when compiling code that attempts to (re)define these functions.. Signed-off-by: Nick Briggs <nicholas.h.briggs@gmail.com> Link: https://lore.kernel.org/r/65a04a7d.497ab3.3e7bef1f@gateway.sonic.net Signed-off-by: Peter Xu <peterx@redhat.com> (cherry picked from commit 44ce1b5d2fc77343f6a318cb3de613336a240048) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-20hw/pflash: implement update buffer for block writesGerd Hoffmann
Add an update buffer where all block updates are staged. Flush or discard updates properly, so we should never see half-completed block writes in pflash storage. Drop a bunch of FIXME comments ;) Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240108160900.104835-4-kraxel@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 284a7ee2e290e0c9b8cd3ea6164d92386933054f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: drop const in hw/block/pflash_cfi01.c for before v8.2.0-220-g7d5dc0a367 "hw/block: Constify VMState")
2024-01-20hw/pflash: use ldn_{be,le}_p and stn_{be,le}_pGerd Hoffmann
Use the helper functions we have to read/write multi-byte values in correct byte order. Suggested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240108160900.104835-3-kraxel@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 5dd58358a57048e5ceabf5c91c0544f4f56afdcd) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-20hw/pflash: refactor pflash_data_write()Gerd Hoffmann
Move the offset calculation, do it once at the start of the function and let the 'p' variable point directly to the memory location which should be updated. This makes it simpler to update other buffers than pfl->storage in an upcoming patch. No functional change. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240108160900.104835-2-kraxel@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 3b14a555fdb627ac091559ef5931c887d06590d8) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-20backends/cryptodev: Do not ignore throttle/backends ErrorsPhilippe Mathieu-Daudé
Both cryptodev_backend_set_throttle() and CryptoDevBackendClass::init() can set their Error** argument. Do not ignore them, return early on failure. Without that, running into another failure trips error_setv()'s assertion. Use the ERRP_GUARD() macro as suggested in commit ae7c80a7bd ("error: New macro ERRP_GUARD()"). Cc: qemu-stable@nongnu.org Fixes: e7a775fd9f ("cryptodev: Account statistics") Fixes: 2580b452ff ("cryptodev: support QoS") Reviewed-by: zhenwei pi <pizhenwei@bytedance.com> Reviewed-by: Gonglei <arei.gonglei@huawei.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20231120150418.93443-1-philmd@linaro.org> (cherry picked from commit 484aecf2d3a75251b63481be2a0c3aef635002af) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-20target/i386: pcrel: store low bits of physical address in data[0]Paolo Bonzini
For PC-relative translation blocks, env->eip changes during the execution of a translation block, Therefore, QEMU must be able to recover an instruction's PC just from the TranslationBlock struct and the instruction data with. Because a TB will not span two pages, QEMU stores all the low bits of EIP in the instruction data and replaces them in x86_restore_state_to_opc. Bits 12 and higher (which may vary between executions of a PCREL TB, since these only use the physical address in the hash key) are kept unmodified from env->eip. The assumption is that these bits of EIP, unlike bits 0-11, will not change as the translation block executes. Unfortunately, this is incorrect when the CS base is not aligned to a page. Then the linear address of the instructions (i.e. the one with the CS base addred) indeed will never span two pages, but bits 12+ of EIP can actually change. For example, if CS base is 0x80262200 and EIP = 0x6FF4, the first instruction in the translation block will be at linear address 0x802691F4. Even a very small TB will cross to EIP = 0x7xxx, while the linear addresses will remain comfortably within a single page. The fix is simply to use the low bits of the linear address for data[0], since those don't change. Then x86_restore_state_to_opc uses tb->cs_base to compute a temporary linear address (referring to some unknown instruction in the TB, but with the correct values of bits 12 and higher); the low bits are replaced with data[0], and EIP is obtained by subtracting again the CS base. Huge thanks to Mark Cave-Ayland for the image and initial debugging, and to Gitlab user @kjliew for help with bisecting another occurrence of (hopefully!) the same bug. It should be relatively easy to write a testcase that performs MMIO on an EIP with different bits 12+ than the first instruction of the translation block; any help is welcome. Fixes: e3a79e0e878 ("target/i386: Enable TARGET_TB_PCREL", 2022-10-11) Cc: qemu-stable@nongnu.org Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Cc: Richard Henderson <richard.henderson@linaro.org> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1759 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1964 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2012 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 729ba8e933f8af5800c3a92b37e630e9bdaa9f1e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-20target/i386: fix incorrect EIP in PC-relative translation blocksguoguangyao
The PCREL patches introduced a bug when updating EIP in the !CF_PCREL case. Using s->pc in func gen_update_eip_next() solves the problem. Cc: qemu-stable@nongnu.org Fixes: b5e0d5d22fbf ("target/i386: Fix 32-bit wrapping of pc/eip computation") Signed-off-by: guoguangyao <guoguangyao18@mails.ucas.ac.cn> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20240115020804.30272-1-guoguangyao18@mails.ucas.ac.cn> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 2926eab8969908bc068629e973062a0fb6ff3759) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-20target/i386: Do not re-compute new pc with CF_PCRELRichard Henderson
With PCREL, we have a page-relative view of EIP, and an approximation of PC = EIP+CSBASE that is good enough to detect page crossings. If we try to recompute PC after masking EIP, we will mess up that approximation and write a corrupt value to EIP. We already handled masking properly for PCREL, so the fix in b5e0d5d2 was only needed for the !PCREL path. Cc: qemu-stable@nongnu.org Fixes: b5e0d5d22fbf ("target/i386: Fix 32-bit wrapping of pc/eip computation") Reported-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20240101230617.129349-1-richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit a58506b748b8988a95f4fa1a2420ac5c17038b30) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-19load_elf: fix iterator's type for elf file processingAnastasia Belova
j is used while loading an ELF file to byteswap segments' data. If data is larger than 2GB an overflow may happen. So j should be elf_word. This commit fixes a minor bug: it's unlikely anybody is trying to load ELF files with 2GB+ segments for wrong-endianness targets, but if they did, it wouldn't work correctly. Found by Linux Verification Center (linuxtesting.org) with SVACE. Cc: qemu-stable@nongnu.org Fixes: 7ef295ea5b ("loader: Add data swap option to load-elf") Signed-off-by: Anastasia Belova <abelova@astralinux.ru> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 410c2a4d75f52f6a2fe978eda5a9b6f854afe5ea) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-17target/hppa: Update SeaBIOS-hppa to version 15Helge Deller
SeaBIOS-hppa version 15: - Fix OpenBSD 7.4 boot (PDC_MEM_MAP call returned wrong values) SeaBIOS-hppa version 14 comes with those fixes: - Fix 32-bit HP-UX crash (fix in PDC_FIND_MODULE call) - Fix NetBSD boot (power button fix and add option to disable it) - Fix FPU detection on NetBSD - Add MEMORY_HPA module on B160L - Fix detection of mptsas and esp scsi controllers - Fix terminate DMA transfer in esp driver (Mark Cave-Ayland) - Allow booting from esp controller Signed-off-by: Helge Deller <deller@gmx.de> (cherry picked from commit 4bda8224fa89ab28958644c5f1a4117886fe8418) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-17target/hppa: Fix IOR and ISR on error in probeHelge Deller
Put correct values (depending on CPU arch) into IOR and ISR on fault. Signed-off-by: Helge Deller <deller@gmx.de> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 31efbe72c6cc54b9cbc2505d78870a8a87a8d392) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-17target/hppa: Fix IOR and ISR on unaligned access trapHelge Deller
Put correct values (depending on CPU arch) into IOR and ISR on fault. Signed-off-by: Helge Deller <deller@gmx.de> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 910ada0225d17530188aa45afcb9412c17267f46) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-17target/hppa: Export function hppa_set_ior_and_isr()Helge Deller
Move functionality to set IOR and ISR on fault into own function. This will be used by follow-up patches. Signed-off-by: Helge Deller <deller@gmx.de> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 3824e0d643f34ee09e0cc75190c0c4b60928b78c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-17target/hppa: Avoid accessing %gr0 when raising exceptionHelge Deller
The value of unwind_breg may reference register %r0, but we need to avoid accessing gr0 directly and use the value 0 instead. At runtime I've seen unwind_breg being zero with the Linux kernel when rfi is used to jump to smp_callin(). Signed-off-by: Helge Deller <deller@gmx.de> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Bruno Haible <bruno@clisp.org> (cherry picked from commit 5915b67013eb8c3a84e3ef05e6ba4eae55ccd173) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-17hw/hppa: Move software power button address back into PDCHelge Deller
The various operating systems (e.g. Linux, NetBSD) have issues mapping the power button when it's stored in page zero. NetBSD even crashes, because it fails to map that page and then accesses unmapped memory. Since we now have a consistent memory mapping of PDC in 32-bit and 64-bit address space (the lower 32-bits of the address are in sync) the power button can be moved back to PDC space. This patch fixes the power button on Linux, NetBSD and HP-UX. Signed-off-by: Helge Deller <deller@gmx.de> Tested-by: Bruno Haible <bruno@clisp.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit ed35afcb331a972210816435d6b1b5de17fc7d4f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-17target/hppa: Fix PDC address translation on PA2.0 with PSW.W=0Helge Deller
Fix the address translation for PDC space on PA2.0 if PSW.W=0. Basically, for any address in the 32-bit PDC range from 0xf0000000 to 0xf1000000 keep the lower 32-bits and just set the upper 32-bits to 0xfffffff0. This mapping fixes the emulated power button in PDC space for 32- and 64-bit machines and is how the physical C3700 machine seems to map PDC. Figures H-10 and H-11 in the parisc2.0 spec [1] show that the 32-bit region will be mapped somewhere into a higher and bigger 64-bit PDC space. The start and end of this 64-bit space is defined by the physical address bits. But the figures don't specifiy where exactly the mapping will start inside that region. Tests on a real HP C3700 regarding the address of the power button indicate, that the lower 32-bits will stay the same though. [1] https://parisc.wiki.kernel.org/images-parisc/7/73/Parisc2.0.pdf Signed-off-by: Helge Deller <deller@gmx.de> Tested-by: Bruno Haible <bruno@clisp.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 6ce18d530638f6e4eb87ef8737c634e34362ad2b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-17hw/pci-host/astro: Add missing astro & elroy registers for NetBSDHelge Deller
NetBSD accesses some astro and elroy registers which aren't accessed by Linux yet. Add emulation for those registers to allow NetBSD to boot further. Please note that this patch is not sufficient to completely boot up NetBSD on the 64-bit C3700 machine yet. Signed-off-by: Helge Deller <deller@gmx.de> Tested-by: Bruno Haible <bruno@clisp.org> (cherry picked from commit 3b57c15f02050227c5c73ca97fa0dfc02f154fe9) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-17hw/hppa/machine: Disable default devices with --nodefaults optionHelge Deller
Recognize the qemu --nodefaults option, which will disable the following default devices on hppa: - lsi53c895a SCSI controller, - artist graphics card, - LASI 82596 NIC, - tulip PCI NIC, - second serial PCI card, - USB OHCI controller. Adding this option is very useful to allow manual testing and debugging of the other possible devices on the command line. Signed-off-by: Helge Deller <deller@gmx.de> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit d8a3220005d74512677b181e3a32cd94b13ddf49) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-17hw/hppa/machine: Allow up to 3840 MB total memoryHelge Deller
The physical hardware allows DIMMs of 4 MB size and above, allowing up to 3840 MB of memory, but is restricted by setup code to 3 GB. Increase the limit to allow up to the maximum amount of memory. Btw. the memory area from 0xf000.0000 to 0xffff.ffff is reserved by the architecture for firmware and I/O memory and can not be used for standard memory. An upcoming 64-bit SeaBIOS-hppa firmware will allow more than 3.75GB on 64-bit HPPA64. In this case the ram_max for the pa20 case will change. Signed-off-by: Helge Deller <deller@gmx.de> Noticed-by: Nelson H. F. Beebe <beebe@math.utah.edu> Fixes: b7746b1194c8 ("hw/hppa/machine: Restrict the total memory size to 3GB") Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Bruno Haible <bruno@clisp.org> (cherry picked from commit 92039f61af89629f268e04255946c2a3fa0c453f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-13readthodocs: fully specify a build environmentAlex Bennée
This is now expected by rtd so I've expanded using their example as 22.04 is one of our supported platforms. I tried to work out if there was an easy way to re-generate a requirements.txt from our pythondeps.toml but in the end went for the easier solution. Cc: <qemu-stable@nongnu.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231221174200.2693694-1-alex.bennee@linaro.org> (cherry picked from commit b16a45bc5e0e329a16af8a2e020a6e7044f9afa2) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-13.gitlab-ci.d/buildtest.yml: Work around htags bug when environment is largePeter Maydell
Sometimes the CI "pages" job fails with a message like this from htags: $ htags -anT --tree-view=filetree -m qemu_init -t "Welcome to the QEMU sourcecode" htags: Negative exec line limit = -371 This is due to a bug in hflags where if the environment is too large it falls over: https://lists.gnu.org/archive/html/bug-global/2024-01/msg00000.html This happens to us because GitLab CI puts the commit message of the commit under test into the CI_COMMIT_MESSAGE and/or CI_COMMIT_TAG_MESSAGE environment variables, so the job will fail if the commit happens to have a verbose commit message. Work around the htags bug by unsetting these variables while running htags. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2080 Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240111125543.1573473-1-peter.maydell@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 52a21689cd829c1cc931b59b5ee5bdb10dd578c1) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-13target/s390x: Fix LAE setting a wrong access registerIlya Leoshkevich
LAE should set the access register corresponding to the first operand, instead, it always modifies access register 1. Co-developed-by: Ido Plat <Ido.Plat@ibm.com> Cc: qemu-stable@nongnu.org Fixes: a1c7610a6879 ("target-s390x: implement LAY and LAEY instructions") Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Message-ID: <20240111092328.929421-2-iii@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit e358a25a97c71c39e3513d9b869cdb82052e50b8) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-13tests/qtest/virtio-ccw: Fix device presence checkingSamuel Tardieu
An apparent copy-paste error tests for the presence of the virtio-rng-ccw device in order to perform tests on the virtio-scsi-ccw device. Signed-off-by: Samuel Tardieu <sam@rfc1149.net> Message-ID: <20240106130121.1244993-1-sam@rfc1149.net> Fixes: 65331bf5d1 ("tests/qtest: Check for virtio-ccw devices before using them") Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit c98873ee4a0c2694aac976ab9affcf55da8b7e61) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-12tests/acpi: disallow tests/data/acpi/virt/SSDT.memhp changesGerd Hoffmann
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 704f7cad5105246822686f65765ab92045f71a3b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-12tests/acpi: update expected data filesGerd Hoffmann
edk2 firmware update caused a address layout change. DefinitionBlock ("", "SSDT", 1, "BOCHS ", "NVDIMM", 0x00000001) { [ ... ] - Name (MEMA, 0x43C90000) + Name (MEMA, 0x43C80000) } Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 55abfc1ffbe54c00529668903fd99b4bb57a6338) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
generated by cgit v1.2.3 (git 2.26.2) at 2025-02-16 18:12:09 +0000