Fix inverted error check in virgl_cmd_resource_create_blob() that causes
the function to return error when virtio_gpu_create_mapping_iov() succeeds.
virtio_gpu_create_mapping_iov() returns 0 on success and negative values
on error. The check 'if (!ret)' incorrectly treats success (ret=0) as an
error condition, causing the function to fail when it should succeed.
Change the condition to 'if (ret != 0)' to properly detect errors.
Fixes: 7c092f17cc ("virtio-gpu: Handle resource blob commands")
Signed-off-by: Honglei Huang <honghuan@amd.com>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260113015203.3643608-2-honghuan@amd.com>
(cherry picked from commit 3560b51979577afc3ab937fd8b02597515bdfbae)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
virtio_pmem_flush() treats a NULL return from virtqueue_pop() as a fatal
error and calls virtio_error(), which puts the device into NEEDS_RESET.
However, virtqueue handlers can be invoked when no element is available,
so an empty queue should be handled as a benign no-op.
With a Linux guest this avoids spurious NEEDS_RESET and the resulting
-EIO propagation (e.g. EXT4 journal abort and remount-ro).
Signed-off-by: Li Chen <me@linux.beauty>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260106083859.380338-1-me@linux.beauty>
(cherry picked from commit efd581a8cd4405ca183ecd017072b0c878802d69)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
When `owner` == `mr`, `object_unparent` will crash:
object_unparent(mr) ->
object_property_del_child(mr, mr) ->
object_finalize_child_property(mr, name, mr) ->
object_unref(mr) ->
object_finalize(mr) ->
object_property_del_all(mr) ->
object_finalize_child_property(mr, name, mr) ->
object_unref(mr) ->
fail on g_assert(obj->ref > 0)
However, passing a different `owner` to `memory_region_init` does not
work. `memory_region_ref` has an optimization where it takes a ref
only on the owner. That means when flatviews are created, it does not
take a ref on the region and you can get a UAF from `flatview_destroy`
called from RCU.
The correct fix therefore is to use `NULL` as the name which will set
the `owner` but not the `parent` (which is still NULL). This allows us
to use `memory_region_ref` on itself while not having to rely on unparent
for cleanup.
Signed-off-by: Joelle van Dyne <j@getutm.app>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260103214400.71694-1-j@getutm.app>
(cherry picked from commit e27194e087aede62dbe3d2805c6f1aa30d3465df)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
This backend driver is used for demonstration purposes only, unlimited
size leads QEMU OOM.
Fixes: CVE-2025-14876
Fixes: 1653a5f3fc ("cryptodev: introduce a new cryptodev backend")
Reported-by: 이재영 <nakamurajames123@gmail.com>
Signed-off-by: zhenwei pi <zhenwei.pi@linux.dev>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20251221024321.143196-3-zhenwei.pi@linux.dev>
(cherry picked from commit 7b913094c703641a0442bb1d1165323a019c591c)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
The total lenght of request is limited by cryptodev config, verify it
to avoid unexpected request from guest.
Fixes: CVE-2025-14876
Fixes: 0e660a6f90 ("crypto: Introduce RSA algorithm")
Reported-by: 이재영 <nakamurajames123@gmail.com>
Signed-off-by: zhenwei pi <zhenwei.pi@linux.dev>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20251221024321.143196-2-zhenwei.pi@linux.dev>
(cherry picked from commit 91c6438caffc880e999a7312825479685d659b44)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
When migrating, dst QEMU by default has SMRAM unlocked,
and since wmask is not migrated, the migrated value of
MCH_HOST_BRIDGE_F_SMBASE in config space fall to prey of
mch_update_smbase_smram()
...
if (pd->wmask[MCH_HOST_BRIDGE_F_SMBASE] == 0xff) {
*reg = 0x00;
and is getting cleared and leads to unlocked smram
on dst even if on source it's been locked.
As Andrey has pointed out [1], we should derive wmask
from config and not other way around.
Drop offending chunk and resync wmask based on MCH_HOST_BRIDGE_F_SMBASE
register value. That would preserve the register during
migration and set smram regions into corresponding state.
What that changes is:
that it would let guest write junk values in register
(with no apparent effect) until it's stumbles upon
reserved 0x1 [|] 0x2 values, at which point it
would be only possible to lock register and trigger
switch to SMRAM blackhole in CPU AS.
While at it, fix up test by removing junk discard before negotiation hunk.
PS2:
Instead of adding a dedicated post_load handler for it,
reuse mch_update->mch_update_smbase_smram call chain
that is called on write/reset/post_load to be consistent
with how we handle mch registers.
PS3:
for prosterity here is erro message Andrey got due to this bug:
qemu: vfio_container_dma_map(0x..., 0x0, 0xa0000, 0x....) = -22 (Invalid argument)
qemu: hardware error: vfio: DMA mapping failed, unable to continue
1) https://patchew.org/QEMU/20251203180851.6390-1-arbn@yandex-team.com/
Fixes: f404220e27 ("q35: implement 128K SMRAM at default SMBASE address")
Reported-by: Andrey Ryabinin <arbn@yandex-team.com>
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Andrey Ryabinin <arbn@yandex-team.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20251211165454.288476-1-imammedo@redhat.com>
(cherry picked from commit 66cf169e29b06dca104c5a229fba0da4ce33599c)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
PCI_SRIOV_* are offsets into the SR-IOV capability, not into the PCI
config space. pcie_sriov_pf_exit() erroneously takes them as the latter,
which makes it read PCI_HEADER_TYPE and PCI_BIST when it tries to read
PCI_SRIOV_TOTAL_VF.
In many cases we're lucky enough that the PCI config space will be 0
there, so we just skip the whole for loop, but this isn't guaranteed.
For example, setting the multifunction bit on the PF and then doing a
'device_del' on it will get a larger number and cause a segfault.
Fix this and access the real PCI_SRIOV_* fields in the capability.
Cc: qemu-stable@nongnu.org
Fixes: 19e55471d4 ('pcie_sriov: Allow user to create SR-IOV device')
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20251205145718.55136-1-kwolf@redhat.com>
(cherry picked from commit f73e5ed9bc4cfacf041323a6b40a85e6b6459b75)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Setting the sriov-pf property on devices that aren't PCI Express causes
an assertion failure:
$ qemu-system-x86_64 \
-blockdev null-co,node-name=null \
-blockdev null-co,node-name=null2 \
-device virtio-blk,drive=null,id=pf \
-device virtio-blk,sriov-pf=pf,drive=null2
qemu-system-x86_64: ../hw/pci/pcie.c:1062: void pcie_add_capability(PCIDevice *, uint16_t, uint8_t, uint16_t, uint16_t): Assertion `offset >= PCI_CONFIG_SPACE_SIZE' failed.
This is because proxy->last_pcie_cap_offset is only initialised to a
non-zero value in virtio_pci_realize() if it's a PCI Express device, and
then virtio_pci_device_plugged() still tries to use it.
To fix this, just skip the SR-IOV code for !pci_is_express(). Then the
next thing pci_qdev_realize() does is call pcie_sriov_register_device(),
which returns the appropriate error.
Cc: qemu-stable@nongnu.org
Fixes: d0c280d3fa ('pcie_sriov: Make a PCI device with user-created VF ARI-capable')
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20251204172657.174391-1-kwolf@redhat.com>
(cherry picked from commit 623db856476806124e9ae45fbc39e75012261570)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
In `virtio_add_resource` function, the UUID used as a key for
`g_hash_table_insert` was temporary, which could lead to
invalid lookups when accessed later. This patch ensures that
the UUID remains valid by duplicating it into a newly allocated
memory space. The value is then inserted into the hash table
with this persistent UUID key to ensure that the key stored in
the hash table remains valid as long as the hash table entry
exists.
Fixes: faefdba847 ("hw/display: introduce virtio-dmabuf")
Signed-off-by: Dorinda Bassey <dbassey@redhat.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Reviewed-by: Albert Esteve <aesteve@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Jim MacArthur <jim.macarthur@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20251204162129.262745-1-dbassey@redhat.com>
(cherry picked from commit fff77cfb8413190c6362b95203ef0973c83b50d2)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
When stopping a vhost-vdpa device, only the first queue pair is marked as suspended,
while the remaining queues are not updated to the suspended state.
As a result, when stopping a multi-queue vhost-vdpa device,
the following error message will be printed.
qemu-system-x86_64:vhost VQ 2 ring restore failed: -1: Operation not permitted (1)
qemu-system-x86_64:vhost VQ 3 ring restore failed: -1: Operation not permitted (1)
So move v->suspended to v->shared, and then all the vhost_vdpa devices cannot
have different suspended states.
Fixes: 0bb302a996 ("vdpa: add vhost_vdpa_suspend")
Suggested-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Wafer Xie <wafer@jaguarmicro.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Message-Id: <20251119132452.3117-1-wafer@jaguarmicro.com>
(cherry picked from commit fd3a2c601ab4a1bdb669e4c584b364e00a978702)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
In the previous design, the I2C model updated dma_dram_offset only when
firmware programmed the RX/TX DMA buffer address registers. The firmware
used to rewrite these registers before issuing each DMA command.
The firmware driver behavior has changed to program the DMA address
registers only once during I2C initialization. As a result, the I2C model
no longer refreshes dma_dram_offset, causing DMA to move data into an
incorrect DRAM address.
Fix this by introducing helper functions to update dma_dram_offset from
the DMA address registers, and invoke them right before handling TX/RX
DMA operations. This guarantees DMA always uses the correct buffer
address even if the registers are programmed only once.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Fixes: c400c38854 ("hw/i2c/aspeed: Introduce a new dma_dram_offset attribute in AspeedI2Cbus")
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260203020855.1642884-5-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
(cherry picked from commit efea7ddb4689a1ac4bce63a9ddb32887c7f3ac50)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
In the previous design, the I2C model would update I2CC_DMA_LEN (0x54) based on
the value of I2CM_DMA_LEN (0x1C) when the firmware set either I2CM_DMA_TX_ADDR
(0x30) or I2CM_DMA_RX_ADDR (0x34). However, this only worked correctly if the
firmware set I2CM_DMA_LEN before setting I2CM_DMA_TX_ADDR or I2CM_DMA_RX_ADDR.
If the firmware instead set I2CM_DMA_TX_ADDR or I2CM_DMA_RX_ADDR before setting
I2CM_DMA_LEN, the value written to I2CC_DMA_LEN would be incorrect.
To fix this issue, the model should be updated to set I2CC_DMA_LEN when the
firmware writes to the I2CM_DMA_LEN register, rather than when it writes to the
I2CM_DMA_RX_ADDR and I2CM_DMA_TX_ADDR registers.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Fixes: ba2cccd64e ("aspeed: i2c: Add new mode support")
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260102090746.1130033-4-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
(cherry picked from commit 9cbd8ee7f67fceee51d3c993a282e5adc397b6b9)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
EHCI3 and EHCI4 were missing entries in aspeed_soc_ast2700a1_irqmap,
so their source IRQs were never routed through the INTC OR-gates.
As a result, EHCI3/4 interrupts were not propagated to the GIC,
causing incorrect interrupt behavior for these controllers.
Add EHCI3 and EHCI4 to the IRQ map and route them to the same INTC
group as other shared peripherals, ensuring their interrupts are
properly connected to the GIC.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Fixes: ba27ba302a ("hw/arm: ast27x0: Wire up EHCI controllers")
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260203020855.1642884-2-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
(cherry picked from commit 7d64f04863ed23f6a142fb8f47c5a470c0e081f9)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
If aspeed_i2c_dma_read fails in aspeed_i2c_bus_send currently, we get
stuck in an infinite retry loop. Add a check for the return value of
aspeed_i2c_dma_read that will break us out of said loop.
Signed-off-by: Nabih Estefan <nabihestefan@google.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Fixes: 545d6bef70 ("aspeed/i2c: Add support for DMA transfers")
Link: https://lore.kernel.org/qemu-devel/20260120211116.1367476-1-nabihestefan@google.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
(cherry picked from commit 0a1d4770670297a1da52118f84812e4a5ffc7722)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
The 'regs' array has ASPEED_ADC_NR_REGS (52) elements, while the
memory region covers offsets 0x00-0xFC. The aspeed_adc_engine_write()
function has an out-of-bounds write vulnerability when accessing
unimplemented registers.
Fix this by using 'return' instead of 'break' in the default case,
which prevents execution from reaching the s->regs[reg] assignment for
unimplemented registers.
Reported-by: Elhrj Saad <saadelhrj@gmail.com>
Fixes: 5857974d5d ("hw/adc: Add basic Aspeed ADC model")
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Link: https://lore.kernel.org/qemu-devel/20260126141820.719492-1-clg@redhat.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
(cherry picked from commit 4c6521296d2b6820ab1f8c59d3a80cd0c138b2d8)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Payload size is the variable request size, not the total buffer size.
Take that into account and subtract header sizes.
Fixes: db1ecfb473 ("hw/uefi: add var-service-vars.c")
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20260114104745.3465860-1-kraxel@redhat.com>
(cherry picked from commit 46dee71a945d50639586ca3365be29aa9f368bfd)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
The bootindex suffix can be used as long as the property is alive.
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20260125-nvme-v1-5-0658c31fade9@rsg.ci.i.u-tokyo.ac.jp>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit eda9baa17a2854494709a8094419ba6a6901721d)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
In python3.14, fixes were made to the file URI parsing [1] such that
file URIs that used to work but were technically out of spec are now
broken.
As a result, our msys2 GitLab CI tests began failing.
Stop using "file://" URI links in favor of simple paths (Thanks pbo) to
fix parsing errors under Python 3.14 and fix the msys2 GitLab CI tests.
[1] https://docs.python.org/3/whatsnew/3.14.html#urllib
Reported-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Suggested-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Tested-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260130050518.517688-2-jsnow@redhat.com>
(cherry picked from commit 587f4a1805c83a4e1d59dd43cb14e0a834843d1d)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Added a test that sends 32 NOP Out commands asynchronously. Since the CQ
has 31 entries by default, this tests the scenario where CQ processing
needs to wait for space to become available.
Additionally, added two minor fixes to existing tests:
* advance CQ head after reading from CQ
* initialize command descriptor slots bitmap in ufs_init()
Signed-off-by: Ilia Levi <ilia.levi@intel.com>
Acked-by: Fabiano Rosas <farosas@suse.de>
Reviewed-by: Jeuk Kim <jeuk20.kim@samsung.com>
Signed-off-by: Jeuk Kim <jeuk20.kim@samsung.com>
(cherry picked from commit 94e72135d4d657d672561b1ae02a5854421616a7)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Currently, ufs_mcq_process_cq() writes to the CQ without checking whether
there is available space. This can cause CQ entries to be discarded and
overwritten. The solution is to stop writing when CQ is full and exert
backpressure on the affected SQs. This is similar to how NVMe CQs operate.
Signed-off-by: Ilia Levi <ilia.levi@intel.com>
Reviewed-by: Jeuk Kim <jeuk20.kim@samsung.com>
Signed-off-by: Jeuk Kim <jeuk20.kim@samsung.com>
(cherry picked from commit f78762a3cc81ca9842907a5fc1b2280083ac51ba)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Round-trip UTRD fields through cpu_to_le/ le_to_cpu when building MCQ CQEs to
keep BE hosts correct. Also avoid double BE conversion of response
data_segment_length and document the LE round-trip.
Signed-off-by: Jeuk Kim <jeuk20.kim@samsung.com>
(cherry picked from commit ed621cc8e2a6dab2663ffb02e875f896f521bee2)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
The UFS spec defines the PRDT data byte count as an 18-bit field. This
commit masks the value to the lower 18 bits to prevent incorrect
transfer lengths and ensure compliance.
Signed-off-by: Jeuk Kim <jeuk20.kim@samsung.com>
(cherry picked from commit 289e6a3edf5041a9f96c3fb792845b94b5b3c666)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
As the builds in codelinaro.org are going away migrate the binaries to
share.linaro.org. As the hotlinks don't encode the filename we need to
explicitly tell uncompress how to handle the files.
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-ID: <20260128105839.3487840-3-alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
(cherry picked from commit d9ca273f8f31acb22d3f5aca5f063b94fb962e19)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Without this linker flag, the linking fails on NetBSD v10.1 with:
ld: i386 architecture of input file `multiboot.o' is incompatible with i386:x86-64 output
ld: i386 architecture of input file `multiboot_dma.o' is incompatible with i386:x86-64 output
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260121074819.29396-1-thuth@redhat.com>
(cherry picked from commit e4f1a9b1dacb4d02500629056551b1db2985429c)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
When extending the container template to allow scheduled pipelines in
upstream context, we must ensure that all the existing rules defined
by .base_job_template are preserved.
Fortunately since the new rule for scheduled pipelines can come at
the head of all other rules, not in the middle, we can just the obscure
'!reference' syntax to pull in all the pre-existing rules as a single
block.
This fixes
* stable branches using the wrong tag name in container images
* pushes to forks unconditionally running container builds
Fixes: 8bec7b9874
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Tested-by: Michael Tokarev <mjt@tls.msk.ru>
Fixes: 8bec7b9874 ("gitlab: add a weekly container building job")
Message-ID: <20260119135528.2738108-1-berrange@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 815567b4ea35176a8f92c5f25bfb335c1cac274e)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Match the contents of table 2-17 ("#UD Exception and VEX.L Field Encoding")
in the SDM, for instruction in exception class 5. They were incorrectly
accepting 256-bit versions that do not exist.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 2eb8d9734355ed86e162dce2a3f265ffee4005ed)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Add several missing baud rates and inputs baud rates in cflag_tbl.
Add these missing definitions in termbits.h:
- TARGET_BOTHER for alpha, hppa, ppc, sh4, sparc
- TARGET_IBSHIFT for hppa, mips, ppc, sh4, sparc
- Missing standard baud rates for hppa
These are required for the glibc test tst-termios-linux.
Link: https://lore.kernel.org/qemu-devel/20251203-linux-user-higher-baud-rates-v2-1-e45b35224437@iscas.ac.cn
Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>
Reviewed-by: Helge Deller <deller@gmx.de>
(cherry picked from commit 4f22fcb5c67f40a36e6654f6cfaee23f9f9e93d1)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
This allows us to keep the MSI data in plain host order all the way
from the MemoryRegionOps write method to the final KVM_SIGNAL_MSI
ioctl. This fixes a theoretical bug on big-endian hosts because we
were using different size byte swaps which would have truncated the data.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260121105932.135676-5-alex.bennee@linaro.org
Cc: qemu-stable@nongnu.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit cf10273aff8198ab1c7e2a00e7e5fe51c80b04e7)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit 369c1ba2b changed the wrong conditional "#if defined(__i386__)" to
"#if defined(TARGET_I386)".
However, TARGET_I386 is defined for target x86_64 also.
This commit fixes it by identifying correctly 32 bits target.
Found with:
$ ./build/qemu-x86_64 \
-plugin ./build/contrib/plugins/libstoptrigger,icount=1000000 \
-plugin ./build/tests/tcg/plugins/libinsn \
-d plugin \
./build/qemu-system-x86_64 --version
ld-elf.so.1: /lib/libz.so.6: invalid file format
cpu 0 insns: 59746
total insns: 59746
Fixes: 369c1ba2b ("Fix __i386__ test for TARGET_HAS_STAT_TIME_T_EXT")
Fixes: dba028d1b ("Fix __i386__ test for TARGET_HAS_STAT_TIME_T_EXT" in 10.2.x)
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Warner Losh <imp@bsdimp.com>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit f0de58ccf6566ad5cf04948788f9b0cfb8b960b4)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
The target test is TARGET_I386, not __i386__.
Cc: Kyle Evans <kevans@freebsd.org>
Reviewed-by: Warner Losh <imp@bsdimp.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit 369c1ba2b7c721341979889841772629b853092b)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Fixes TYPE_FSL_IMX6UL, TYPE_FSL_IMX7, and TYPE_FSL_IMX8MP to implement
version 3 of the SD specification.
Note that TYPE_FSL_IMX6 already had "sd-spec-version" set accordingly and
that TYPE_FSL_IMX25 correctly sets the same property to version 2 since the
real hardware is an eSDHC which is the uSDHC's predecessor.
Fixes: fd1e5c8179 ("sdhci: Add i.MX specific subtype of SDHCI")
cc: qemu-stable
Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: BALATON Zoltan <balaton@eik.bme.hu>
Message-ID: <20260112145418.220506-2-shentey@gmail.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 214f79fdfb43e92f6c06efb76c3ad8e932b035f8)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
This caused a failure with program using openat2, where O_LARGEFILE was
replaced by O_NOFOLLOW.
This issue is only visible when QEMU is compiled with musl libc, where
O_LARGEFILE is different from 0 (vs glibc).
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3262
Cc: qemu-stable@nongnu.org
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit 83017c4aaa9e3ef80161443019764196dffdb654)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Fix typo to avoid the following build failure:
target/i386/nvmm/nvmm-all.c: In function 'nvmm_init_vcpu':
target/i386/nvmm/nvmm-all.c:988:9: error: 'AccelCPUState' has no member named 'vcpu_dirty'
988 | qcpu->vcpu_dirty = true;
| ^~
Cc: qemu-stable@nongnu.org
Reported-by: Thomas Huth <thuth@redhat.com>
Fixes: 2098164a6b ("accel/nvmm: Replace @dirty field by generic CPUState::vcpu_dirty field")
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Tested-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-ID: <20260113203924.81560-1-philmd@linaro.org>
(cherry picked from commit 7be4256281f430f726366c92ffdea0b72651de8a)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
In v7A HCR.TID1 is defined to trap for TCMTR, TLBTR, REVIDR and AIDR.
We incorrectly use an accessfn for REVIDR and AIDR that only traps on
v8A cores. Fix this by collapsing access_aa64_tid1() and
access_aa32_tid1() together and never doing a check for v8 vs v7.
The accessfn is also used for SMIDR_EL1, which is fine as this
register is AArch64 only.
Cc: qemu-stable@nongnu.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20251231170858.254594-4-peter.maydell@linaro.org
(cherry picked from commit b67a35622f9a816544ec094132d8af0debfac7f2)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
The HCR.TID3 bit defines that we should trap to the hypervisor for
reads to a collection of ID registers. Different architecture versions
have defined this differently:
* v7A has a set of ID regs that definitely must trap:
- ID_PFR{0,1}, ID_DFR0, ID_AFR0, ID_MMFR{0,1,2,3},
ID_ISAR{0,1,2,3,4,5}, MVFR{0,1}
and somewhat vaguely says that "there is no requirement"
to trap for registers that are reserved in the ID reg space
(i.e. which RAZ and might be used for new ID regs in future)
* v8A adds to this list:
- ID_PFR2 and MVFR2 must trap
- ID_MMFR4, ID_MMFR5, ID_ISAR6, ID_DFR1 and reserved registers
in the ID reg space must trap if FEAT_FGT is implemented,
and it is IMPDEF if they trap if FEAT_FGT is not implemented
In QEMU we seem to have attempted to implement this distinction
(taking the "we do trap" IMPDEF choice if no FEAT_FGT), with
access_aa64_tid3() always trapping on TID3 and access_aa32_tid3()
trapping only if ARM_FEATURE_V8 is set. However, we didn't apply
these to the right set of registers: we use access_aa32_tid3() on all
the 32-bit ID registers *except* ID_PFR2, ID_DFR1, ID_MMFR5 and the
RES0 space, which means that for a v7 CPU we don't trap on a lot of
registers that we should trap on, and we do trap on various things
that the v7A Arm ARM says there is "no requirement" to trap on.
Straighten this out by naming the access functions more clearly for
their purpose, and documenting this: access_v7_tid3() is only for the
fixed set of ID registers that v7A traps on HCR.TID3, and
access_tid3() is for any others, including the reserved encoding
spaces and any new registers we add in future.
AArch32 MVFR2 access is handled differently, in check_hcr_el2_trap;
there we already do not trap on TID3 on v7A cores (where MVFR2
doesn't exist), because we in the code-generation function we UNDEF
if ARM_FEATURE_V8 is not set, without generating code to call
check_hcr_el2_trap.
This bug was causing a problem for Xen which (after a recent change
to Xen) expects to be able to trap ID_PFR0 on a Cortex-A15.
The result of these changes is that our v8A behaviour remains
the same, and on v7A we now trap the registers the Arm ARM definitely
requires us to trap, and don't trap the reserved space that "there is
no requirement" to trap.
Cc: qemu-stable@nongnu.org
Fixes: 6a4ef4e5d1 ("target/arm: Honor HCR_EL2.TID3 trapping requirements")
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20251231170858.254594-3-peter.maydell@linaro.org
(cherry picked from commit 205ca535abaceda375c54797b1129a54a5ebbe96)
(Mjt: trivial context fix around AA64MMFR4_EL1 definition)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
In the definition of ID_PFR1 we have an ifdef block; we specify the
accessfn once in the common part of the ifdef and once in the
not-user-only part, which is redundant but harmless.
The accessfn will always return success in user-only mode (because
we won't trap to EL2), so specify it only in the not-user-only
half of the ifdef, as was probably the intention.
This is only cc'd to stable to avoid a textual conflict with
the following patch, which is a bug fix.
Cc: qemu-stable@nongnu.org
Fixes: 0f150c8499 ("target/arm: Constify ID_PFR1 on user emulation")
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20251231170858.254594-2-peter.maydell@linaro.org
(cherry picked from commit 8da52b8401afa34ea8caa58e1bfb321ae142899b)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Cedric has a host for the file which allows us to keep the name.
Cc: qemu-stable@nongnu.org
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Message-id: 20260113135941.3361163-1-alex.bennee@linaro.org
Cc: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 7cf096d609e67fd06abf6a59e592cb6de427825c)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Unfortunately while rebasing the series registering the
ARM/Aarch64 machine interfaces and getting it merged as
commit 38c5ab4003 ("hw/arm: Filter machine types for
qemu-system-arm/aarch64 binaries") we missed the recent
addition of the MAX78000FTHR machine in commit 51eb283dd0.
Correct that.
The effect is that the machine was accidentally disabled.
Cc: qemu-stable@nongnu.org
Reported-by: Thomas Huth <thuth@redhat.com>
Tested-by: Thomas Huth <thuth@redhat.com>
Tested-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20251218214306.63667-1-philmd@linaro.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3248
Fixes: 38c5ab4003 ("hw/arm: Filter machine types for single binary")
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit c5712ad83fa4bf2f2a4e8fc9431ad9548bac2b06)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Since commit f2e61edb29 ("hw/loongarch/virt: Use MemTxAttrs interface
for misc ops") which adds a call to g_assert_not_reached() in the path
of handling unimplemented IOCSRs, QEMU would abort when the guest
accesses unimplemented IOCSRs.
This is too serious since there's nothing fatal happening in QEMU
itself, and the guest could probably continue running if we give zero as
result for these reads, which also matches the behavior observed on
3A5000M real machine.
Replace the assertion with qemu_log_mask(LOG_UNIMP, ...), it's still
possible to examine unimplemented IOCSR access through "-d unimp"
command line arguments.
Fixes: f2e61edb29 ("hw/loongarch/virt: Use MemTxAttrs interface for misc ops")
Signed-off-by: Yao Zi <me@ziyao.cc>
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
(cherry picked from commit 49ee001a5b8378e9a9b3db8cbf61e7eda970ecd2)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Exception ADEM/ADEF need update CSR_BADV, the value from the virtual
address.
Signed-off-by: Song Gao <gaosong@loongson.cn>
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
(cherry picked from commit a7be2e0a3f7d0f35bcc3b17e2b558084efc5d9fe)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Exception BCE need update CSR_BADV, and the value is env->pc.
Signed-off-by: Song Gao <gaosong@loongson.cn>
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
(cherry picked from commit e4f0ef58d53eb20056f9f3ca9f21dbbbf25f2530)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
According to Volume 1 Manual 7.4.8 ,exception,SYS,BRK,INE,IPE,PPD
FPE,SXD,ASXD are need't update CSR_BADV, this patch correct it.
Signed-off-by: Song Gao <gaosong@loongson.cn>
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
(cherry picked from commit 70cf9b7bf7aff47f8d85ccce35b688dd91335cf0)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
When we use the -kernel parameter to start an elf format kernel relying on
fdt, we get the following error:
pcieport 0000:00:01.0: of_irq_parse_pci: failed with rc=-22
pcieport 0000:00:01.0: enabling device (0000 -> 0003)
pcieport 0000:00:01.0: PME: Signaling with IRQ 19
pcieport 0000:00:01.0: AER: enabled with IRQ 19
pcieport 0000:00:01.1: of_irq_parse_pci: failed with rc=-22
pcieport 0000:00:01.1: enabling device (0000 -> 0003)
pcieport 0000:00:01.1: PME: Signaling with IRQ 20
pcieport 0000:00:01.1: AER: enabled with IRQ 20
pcieport 0000:00:01.2: of_irq_parse_pci: failed with rc=-22
pcieport 0000:00:01.2: enabling device (0000 -> 0003)
pcieport 0000:00:01.2: PME: Signaling with IRQ 21
pcieport 0000:00:01.2: AER: enabled with IRQ 21
pcieport 0000:00:01.3: of_irq_parse_pci: failed with rc=-22
pcieport 0000:00:01.3: enabling device (0000 -> 0003)
pcieport 0000:00:01.3: PME: Signaling with IRQ 22
pcieport 0000:00:01.3: AER: enabled with IRQ 22
pcieport 0000:00:01.4: of_irq_parse_pci: failed with rc=-22
This is because the description of interrupt-cell is missing in the pcie
irq map. And there is a lack of a description of the interrupt trigger
type. Now it is corrected and the correct interrupt-cell is added in the
pcie irq map.
Refer to the implementation in arm and add some comments.
Signed-off-by: Xianglai Li <lixianglai@loongson.cn>
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
(cherry picked from commit ff54394eed148c642f83b45753c7898acdbd5ddb)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
