Windows Server 2022 and later support
WHvCapabilityCodeProcessorPerfmonFeatures and
WHvPartitionPropertyCodeSyntheticProcessorFeaturesBanks.
Windows 10 supports neither of those.
As the QEMU executable doesn't have a manifest, OS version
queries do not return the actual Windows version but 6.2.9200
which corresponds to Windows 8. Windows Server 2022 and Windows
11 still use the 10.0 number, with distinction being the build
number.
As such, use the absence of perf monitoring feature query as
a cutoff to detect if a legacy OS is present.
Signed-off-by: Mohamed Mediouni <mohamed@unpredictable.fr>
Link: https://lore.kernel.org/r/20260324151323.74473-2-mohamed@unpredictable.fr
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The version is never set on 2.5+ machine types, so qemu_hw_version() and
qemu_set_hw_version() are not needed anymore.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This is mostly harmless right now because the "if" is never
hit, but the code as written makes no sense.
Reported-by: Stefan Weil <sw@weilnetz.de>
Cc: qemu-stable@nongnu.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Short writes can happen, too, not just short reads. The difference to
aio=native is that the kernel will actually retry the tail of short
requests internally already -- so it is harder to reproduce. But if the
tail of a short request returns an error to the kernel, we will see it
in userspace still. To reproduce this, apply the following patch on top
of the one shown in HEAD^ (again %s/escaped // to apply):
escaped diff --git a/block/export/fuse.c b/block/export/fuse.c
escaped index 67dc50a412..2b98489a32 100644
escaped --- a/block/export/fuse.c
escaped +++ b/block/export/fuse.c
@@ -1059,8 +1059,15 @@ fuse_co_read(FuseExport *exp, void **bufptr, uint64_t offset, uint32_t size)
int64_t blk_len;
void *buf;
int ret;
+ static uint32_t error_size;
- size = MIN(size, 4096);
+ if (error_size == size) {
+ error_size = 0;
+ return -EIO;
+ } else if (size > 4096) {
+ error_size = size - 4096;
+ size = 4096;
+ }
/* Limited by max_read, should not happen */
if (size > FUSE_MAX_READ_BYTES) {
@@ -1111,8 +1118,15 @@ fuse_co_write(FuseExport *exp, struct fuse_write_out *out,
{
int64_t blk_len;
int ret;
+ static uint32_t error_size;
- size = MIN(size, 4096);
+ if (error_size == size) {
+ error_size = 0;
+ return -EIO;
+ } else if (size > 4096) {
+ error_size = size - 4096;
+ size = 4096;
+ }
QEMU_BUILD_BUG_ON(FUSE_MAX_WRITE_BYTES > BDRV_REQUEST_MAX_BYTES);
/* Limited by max_write, should not happen */
I know this is a bit artificial because to produce this, there must be
an I/O error somewhere anyway, but if it does happen, qemu will
understand it to mean ENOSPC for short writes, which is incorrect. So I
believe we need to resubmit the tail to maybe have it succeed now, or at
least get the correct error code.
Reproducer as before:
$ ./qemu-img create -f raw test.raw 8k
Formatting 'test.raw', fmt=raw size=8192
$ ./qemu-io -f raw -c 'write -P 42 0 8k' test.raw
wrote 8192/8192 bytes at offset 0
8 KiB, 1 ops; 00.00 sec (64.804 MiB/sec and 8294.9003 ops/sec)
$ hexdump -C test.raw
00000000 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a |****************|
*
00002000
$ storage-daemon/qemu-storage-daemon \
--blockdev file,node-name=test,filename=test.raw \
--export fuse,id=exp,node-name=test,mountpoint=test.raw,writable=true
$ ./qemu-io --image-opts -c 'read -P 23 0 8k' \
driver=file,filename=test.raw,cache.direct=on,aio=io_uring
read 8192/8192 bytes at offset 0
8 KiB, 1 ops; 00.00 sec (58.481 MiB/sec and 7485.5342 ops/sec)
$ ./qemu-io --image-opts -c 'write -P 23 0 8k' \
driver=file,filename=test.raw,cache.direct=on,aio=io_uring
write failed: No space left on device
$ hexdump -C test.raw
00000000 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 |................|
*
00001000 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a |****************|
*
00002000
So short reads already work (because there is code for that), but short
writes incorrectly produce ENOSPC. This patch fixes that by
resubmitting not only the tail of short reads but short writes also.
(And this patch uses the opportunity to make it so qemu_iovec_destroy()
is called only if req->resubmit_qiov.iov is non-NULL. Functionally a
non-op, but this is how the code generally checks whether the
resubmit_qiov has been set up or not.)
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-ID: <20260324084338.37453-4-hreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
When password-secret is used, curl_open() resolves it with
qcrypto_secret_lookup_as_utf8() and stores the returned buffer in
s->password.
Unlike s->proxypassword, s->password is not freed either in the open
failure path or in curl_close(), so the resolved secret leaks once it
has been allocated.
Free s->password in both cleanup paths.
Fixes: 1bff960642 ('curl: add support for HTTP authentication parameters')
Signed-off-by: GuoHan Zhao <zhaoguohan@kylinos.cn>
Message-ID: <20260320063016.262954-1-zhaoguohan_salmon@163.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Change accel SMMUv3 OAS property from uint8_t to OasMode. The
'auto' value is not implemented, as this commit is meant to
set the property to the correct type and avoid breaking JSON/QMP
when the auto mode is introduced. A future patch will implement
resolution of 'auto' value to match the host SMMUv3 OAS value.
The conversion of the "oas" property type to OnOffAuto is an
incompatible change for JSON/QMP when a uint8_t value is expected for
"oas", but this property is new in 11.0 and this patch is
submitted as a fix to the property type.
Fixes: a015ac990f ("hw/arm/smmuv3-accel: Add property to specify OAS bits")
Tested-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Shameer Kolothum <skolothumtho@nvidia.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Shameer Kolothum <skolothumtho@nvidia.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Nathan Chen <nathanc@nvidia.com>
Message-id: 20260323182454.1416110-8-nathanc@nvidia.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Change accel SMMUv3 SSIDSIZE property from uint8_t to SsidSizeMode.
The 'auto' value is not implemented, as this commit is meant to set the
property to the correct type and avoid breaking JSON/QMP when the auto
mode is introduced. A future patch will implement resolution of 'auto'
value to match the host SMMUv3 SSIDSIZE value.
The conversion of the "ssidsize" property type to OnOffAuto is an
incompatible change for JSON/QMP when a uint8_t value is expected for
"ssidsize", but this property is new in 11.0 and this patch is
submitted as a fix to the property type.
Fixes: b8c6f8a69d ("hw/arm/smmuv3-accel: Make SubstreamID support configurable")
Tested-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Shameer Kolothum <skolothumtho@nvidia.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Shameer Kolothum <skolothumtho@nvidia.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Nathan Chen <nathanc@nvidia.com>
Message-id: 20260323182454.1416110-6-nathanc@nvidia.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Change accel SMMUv3 RIL property from bool to OnOffAuto. The 'auto'
value is not implemented, as this commit is meant to set the property
to the correct type and avoid breaking JSON/QMP when the auto mode is
introduced. A future patch will implement resolution of the 'auto'
value to match the host SMMUv3 RIL support.
The conversion of the RIL property type to OnOffAuto is an
incompatible change for JSON/QMP when a bool value is expected for
"ril", but the "ril" property is new in 11.0 and this patch is
submitted as a fix to the property type.
Fixes: bd715ff5bd ("hw/arm/smmuv3-accel: Add a property to specify RIL support")
Tested-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Shameer Kolothum <skolothumtho@nvidia.com>
Tested-by: Shameer Kolothum <skolothumtho@nvidia.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Nathan Chen <nathanc@nvidia.com>
Message-id: 20260323182454.1416110-4-nathanc@nvidia.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Change accel SMMUv3 ATS property from bool to OnOffAuto. The 'auto'
value is not implemented, as this commit is meant to set the property
to the correct type and avoid breaking JSON/QMP when the auto mode is
introduced. A future patch will implement resolution of the 'auto'
value to match the host SMMUv3 ATS support.
The conversion of the ATS property type to OnOffAuto is an
incompatible change for JSON/QMP when a bool value is expected for
"ats", but the "ats" property is new in 11.0 and this patch is
submitted as a fix to the property type.
Fixes: f7f5013a55 ("hw/arm/smmuv3-accel: Add support for ATS")
Tested-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Shameer Kolothum <skolothumtho@nvidia.com>
Tested-by: Shameer Kolothum <skolothumtho@nvidia.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Nathan Chen <nathanc@nvidia.com>
Message-id: 20260323182454.1416110-3-nathanc@nvidia.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The logic in the PL080 for transferring data has multiple bugs:
* The TransferSize field in the channel control register counts
in units of the source width; because our loop may do multiple
source loads if the destination width is greater than the
source width, we need to decrement it by (xsize / swidth),
not by 1, each loop
* It is documented in the TRM that it is a software error to program
the source and destination width such that SWidth < DWidth and
TransferSize * SWidth is not a multiple of DWidth. (This would
mean that there isn't enough data to do a full final destination
write.) We weren't doing anything sensible with this case.
The TRM doesn't document what the hardware actually does (though
it drops some hints that suggest that it probably over-reads
from the source).
* In the loop to write to the destination, each loop adds swidth
to ch->dest for each loop and also uses (ch->dest + n) as the
destination address. This moves the destination address on
further than we should each time round the loop, and also
is incrementing ch->dest by swidth when it should be dwidth.
This patch fixes these problems:
* decrement TransferSize by the correct amount
* log and ignore the transfer size mismatch case
* correct the loop logic for the destination writes
A repro case which exercises some of this is as follows. It
configures swidth to 1 byte, dwidth to 4 bytes, and transfer size 4,
for a transfer from 0x00000000 to 0x000010000. Examining the
destination memory in the QEMU monitor should show that the
source data 0x44332211 has all been copied, but before this
fix it is not:
./qemu-system-arm -M versatilepb -m 128M -nographic -S \
-device loader,addr=0x00000000,data=0x44332211,data-len=4 \
-device loader,addr=0x00001000,data=0x00000000,data-len=4 \
-device loader,addr=0x10130030,data=0x00000001,data-len=4 \
-device loader,addr=0x10130100,data=0x00000000,data-len=4 \
-device loader,addr=0x10130104,data=0x00001000,data-len=4 \
-device loader,addr=0x10130108,data=0x00000000,data-len=4 \
-device loader,addr=0x1013010C,data=0x9e47f004,data-len=4 \
-device loader,addr=0x10130110,data=0x0000c001,data-len=4
Without this patch the QEMU monitor shows:
(qemu) xp /1wx 0x00001000
00001000: 0x00002211
Correct result:
(qemu) xp /1wx 0x00001000
00001000: 0x44332211
Cc: qemu-stable@nongnu.org
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Tao Ding <dingtao0430@163.com>
[PMM: Wrote up what we are fixing in the commit message]
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Our definition of the target_fpstate_32 struct doesn't match the
kernel's version. We only use this struct definition in the
definition of 'struct sigframe', where it is used in a field that is
present only for legacy reasons to retain the offset of the following
'extramask' field. So really all that matters is its length, and we
do get that right; but our previous definition using
X86LegacySaveArea implicitly added an extra alignment constraint
(because X86LegacySaveArea is tagged as 16-aligned) which the real
target_fpstate_32 does not have. Because we allocate and use a
'struct sigframe' on the guest's stack with the guest's alignment
requirements, this resulted in the undefined-behaviour sanitizer
complaining during 'make check-tcg' for i386-linux-user:
../../linux-user/i386/signal.c:471:35: runtime error: member access within misaligned address 0x1000c07f75ec for type 'struct sigframe', which requires 16 byte alignment
0x1000c07f75ec: note: pointer points here
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
^
../../linux-user/i386/signal.c:808:5: runtime error: member access within misaligned address 0x1000c07f75f4 for type 'struct target_sigcontext_32', which requires 8 byte alignment
0x1000c07f75f4: note: pointer points here
0a 00 00 00 33 00 00 00 00 00 00 00 2b 00 00 00 2b 00 00 00 40 05 80 40 f4 7f 10 08 58 05 80 40
^
and various similar errors.
Replace the use of X86LegacyXSaveArea with a set of fields that match
the kernel _fpstate_32 struct, and assert that the length is correct.
We could equally have used
uint8_t legacy_area[512];
but following the kernel is probably less confusing overall.
Since in target/i386/cpu.h we assert that X86LegacySaveArea is 512
bytes, and in linux-user/i386/signal.c we assert that
target_fregs_state is (32 + 80) bytes, the new assertion confirms
that we didn't change the size of target_fpstate_32 here, only its
alignment requirements.
Cc: qemu-stable@nongnu.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260305161739.1775232-1-peter.maydell@linaro.org
Commit a811c5dafb ("target/arm: Implement get_S2prot_indirect")
changed get_phys_addr_twostage() to combine stage 1 and stage 2
permissions using the new s2prot field:
result->f.prot = s1_prot & result->s2prot;
The LPAE stage 2 path sets result->s2prot explicitly, but the PMSA
stage 2 path (get_phys_addr_pmsav8) only sets result->f.prot, leaving
s2prot at zero. This causes the combined permission to be zero,
resulting in addr_read being set to -1 in the TLB entry and triggering
an assertion in atomic_mmu_lookup() when the guest executes an atomic
instruction on a two-stage PMSA platform (e.g. Cortex-R52 with EL2).
Set s2prot from f.prot after the PMSA stage 2 lookup, consistent with
what the LPAE path does.
Cc: qemu-stable@nongnu.org
Fixes: a811c5dafb ("target/arm: Implement get_S2prot_indirect")
Signed-off-by: Jose Martins <josemartins90@gmail.com>
[PMM: refer to the right commit in the commit message]
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260321231916.2852653-1-josemartins90@gmail.com
Reviewed-by: Gustavo Romero <gustavo.romero@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
According to the Aspeed datasheet, the RX_BUF_LEN_W1T and
TX_BUF_LEN_W1T bits of the A_I2CS_DMA_LEN (0x2c) register allow
firmware to program the TX and RX DMA length (TX_BUF_LEN and
RX_BUF_LEN fields of the same register) separately without the need to
read/modify/write the value. If RX_BUF_LEN_W1T and TX_BUF_LEN_W1T
bits are 0, then both TX and RX DMA length will be written.
When setting the RX_BUF_LEN field, the TX_BUF_LEN field being set is
not an invalid condition. Remove the assert.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3315
Reviewed-by: Jamin Lin <jamin_lin@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20260323125545.577653-4-clg@redhat.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Disable the kernel crypto self-tests in the AST2700 functional tests by
appending "cryptomgr.notests=1" to the U-Boot bootargs before booting
the kernel.
The ASPEED SDK enables crypto self-tests during kernel startup to
validate the hardware crypto engine. However, the current QEMU
implementation of the AST2700 HACE/crypto engine is still incomplete.
As a result, the kernel crypto self-tests trigger multiple warnings
during boot when running under QEMU.
Typical examples observed in the kernel log include failures for
several cipher modes such as DES/TDES/AES in ECB/CBC/CTR modes:
alg: self-tests for ctr(des) using aspeed-ctr-des failed (rc=-22)
alg: self-tests for ecb(des3_ede) using aspeed-ecb-tdes failed (rc=-22)
alg: self-tests for cbc(aes) using aspeed-cbc-aes failed (rc=-22)
...
To reduce noise in the functional test logs, the tests now append
the following parameter to the kernel bootargs:
cryptomgr.notests=1
This disables the kernel crypto self-tests when running the functional
tests under QEMU.
For validating the HACE implementation, we should instead rely on the
dedicated QEMU unit tests located in:
tests/qtest/ast2700-hace-test.c
Once the QEMU implementation of the ASPEED HACE/crypto model has
progressed further and supports the missing crypto modes, we can
reassess whether enabling the kernel crypto self-tests again in the
functional tests is appropriate.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260316081549.1279841-1-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
QEMU executes I2C commands synchronously inside the CMD register write
handler. On real hardware each command takes time on the bus, so the
ISR can clear the previous interrupt status before the next completion
arrives. In QEMU, when the guest ISR handles a TX_ACK and immediately
issues the next command by writing to CMD, that command completes
instantly — before the ISR returns to W1C-clear the first TX_ACK.
Since the bit is already set, setting it again is a no-op. The ISR
then clears it, wiping both completions at once. No interrupt fires
for the second command and the driver stalls.
This affects any multi-step I2C transaction: register reads, SMBus
word reads, and PMBus device probes all fail ("Error: Read failed"
from i2cget, -ETIMEDOUT from kernel drivers).
The issue is exposed when the guest kernel includes commit "i2c:
aspeed: Acknowledge Tx done with and without ACK irq late" [1] which
defers W1C acknowledgment of TX_ACK until after the ISR has issued
the next command. This means the old TX_ACK is still set when the
next command completes synchronously, and the subsequent W1C wipes
both completions at once.
The trace below shows `i2cget -y 15 0x50 0x00` (read EEPROM register
0x00) failing without the fix. The first START+TX sets TX_ACK. The
ISR handles it and issues a second TX to send the register address.
That TX completes synchronously while TX_ACK is still set:
aspeed_i2c_bus_cmd cmd=0x3 start|tx| intr=0x0 # START+TX, clean
aspeed_i2c_bus_raise_interrupt intr=0x1 ack| # TX_ACK set
aspeed_i2c_bus_read 0x10: 0x1 # ISR reads TX_ACK
aspeed_i2c_bus_write 0x14: 0x2 # ISR issues TX cmd
aspeed_i2c_bus_cmd cmd=0x400002 tx| intr=0x1 # TX runs, TX_ACK already set!
aspeed_i2c_bus_raise_interrupt intr=0x1 ack| # re-set is no-op
aspeed_i2c_bus_write 0x10: 0x1 # ISR W1C clears TX_ACK
aspeed_i2c_bus_read 0x10: 0x0 # LOST — both ACKs wiped
The driver sees INTR_STS=0 and never proceeds to the read phase.
Fix this by tracking interrupt bits that collide with already-pending
bits. Before calling aspeed_i2c_bus_handle_cmd(), save and clear
INTR_STS so that only freshly set bits are visible after the call.
Any overlap between the old and new bits is saved in pending_intr_sts.
When the ISR later W1C-clears the old bits, re-apply the saved
pending bits so the ISR sees them on its next loop iteration.
With the fix, the same operation completes successfully:
aspeed_i2c_bus_cmd cmd=0x3 start|tx| intr=0x0 # START+TX, clean
aspeed_i2c_bus_raise_interrupt intr=0x1 ack| # TX_ACK set
aspeed_i2c_bus_read 0x10: 0x1 # ISR reads TX_ACK
aspeed_i2c_bus_write 0x14: 0x2 # ISR issues TX cmd
aspeed_i2c_bus_cmd cmd=0x400002 tx| intr=0x0 # INTR_STS cleared first
aspeed_i2c_bus_raise_interrupt intr=0x1 ack| # TX_ACK freshly set
aspeed_i2c_bus_write 0x10: 0x1 # ISR W1C clears TX_ACK
aspeed_i2c_bus_read 0x10: 0x1 # RE-DELIVERED from pending
aspeed_i2c_bus_write 0x14: 0x1b # ISR proceeds: START+RX
aspeed_i2c_bus_cmd cmd=0x40001b start|tx|rx|last| # read phase completes
i2c_recv recv(addr:0x50) data:0x00 # data received
[1] https://lore.kernel.org/all/20231211102217.2436294-3-quan@os.amperecomputing.com/
Signed-off-by: Jithu Joseph <jithu.joseph@oss.qualcomm.com>
Fixes: 1602001195 ("i2c: add aspeed i2c controller")
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260311023712.2730185-1-jithu.joseph@oss.qualcomm.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Misc HW patches
- Fix guest-triggerable abort in FTGMAC100 Gigabit Ethernet
- Fix uninitialized value in DesignWare I3C controller
- Clear dangling GLib event source tag in virtio-console
- Mark RISC-V specific peripherals as little-endian
- Correct virtual address formatting in monitor
- Improve error handling path in core loader
- Improve error hints in IOMMU FD
- Prevent hang in USB OHCI
- ATI VGA, HyperV & CXL fixes
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEE+qvnXhKRciHc/Wuy4+MsLN6twN4FAmnBb5cACgkQ4+MsLN6t
# wN408A/8DQPa8l7uB/hJ397oWjPeRTvC18V5g7xa9DkC5m82GqqbNYj5RDCajD9T
# /o/SQUdOhxXfl6wkCirpZj9qsVdhPuXh4G+CziIju6XJIJFGYf8zxvz1Z3kNn3sU
# fsFuE+P6zQXUUNspowNOnQWa/eHbCqsTa+uhVvFccVcOYOeU0ptLjm6P1CptTyrS
# 7en27DO2/RqejvcI7fPThZCdplC0HPdy7UGM4AnvKOXUGNz4aNurMJrWw92ZHxLu
# EQ8cB3o4CUoFJbJGokhP/Xcc+YHXlzJKPw9SlSXGMCdp1e1s/Z1YaWM+6BnmcqDZ
# M+8/RZ57owr5yF77KpYpuN+weWwMBlvISXr0MNa14HHJi3sEoOPxPZ/8X5vhcPUi
# sXrwrLrDtIEPeloCKDbbafdLwrFI7nqvQyldbnVdnqncrX1v8WOFPQO4m2WuD5TL
# pY0zzfSqlCyUj0sycn19yVyTH0rjybmrhsJpjDut4Qvoy2Ng1geBsSq+WVIamDnN
# e2iLVMspgQX8Klr+fcae0INRHKXdpIEt0ITroxwx0rq88ITQQbijGXgn0N0T5rWF
# f1RDg6toyz5s6//dgjK8j/vCEhQ4YRxfNreqo8gH6V/8II9jzkGyfj2g/PaWKlDr
# CZXmHtSWG+adRQLdb0/xJjG3eej3qmivMP7+0v+utNcb2DoEUZw=
# =+5Iw
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon Mar 23 16:51:35 2026 GMT
# gpg: using RSA key FAABE75E12917221DCFD6BB2E3E32C2CDEADC0DE
# gpg: Good signature from "Philippe Mathieu-Daudé (F4BUG) <f4bug@amsat.org>" [full]
# Primary key fingerprint: FAAB E75E 1291 7221 DCFD 6BB2 E3E3 2C2C DEAD C0DE
* tag 'hw-misc-20260323' of https://github.com/philmd/qemu: (27 commits)
hw/hyperv: add QEMU_PACKED to uapi structs
monitor: Correctly display virtual addresses while dumping memory
hw/net/ftgmac100: Improve DMA error handling
ati-vga: Make sure hardware cursor data is within vram
ati-vga: Simplify pointer image handling
ati-vga: Add work around for fuloong2e
ati-vga: Fix display updates in non-32 bit modes
ati-vga: Avoid warnings about sign extension
ati-vga: Do not add crtc offset to src and dst data address
ati-vga: Also switch mode on HW cursor enable bit change
ati-vga: Fix colors when frame buffer endianness does not match host
hw/usb/hcd-ohci: check for MPS=0 to avoid infinite loop
hw/hyperv: Fix SynIC not initialized except on first vCPU
hw/vfio/iommufd: report hint to user when vfio-dev/vfio*/dev is missing
backends/iommufd: report error when /dev/iommu is not available
hw/cxl: Exclude Discovery from Media Operation Discovery output
hw/cxl: Respect Media Operation max ops discovery semantics
hw/i386/hyperv: add stubs for synic enablement
hw/i386/pc_sysfw: stub out x86_firmware_configure
hw/pci/msix: fix error handling for msix_init callers
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
testing updates: tcg, functional, lcitool
- add TCG_TEST_FILTER to filter check-tcg runs
- use portable version of dirent64 in linux-test
- add VBSA linux tests
- drop python3-sqlite from deps
- update openSUSE to version 16
- replace ncat with socat for migration tests
# -----BEGIN PGP SIGNATURE-----
#
# iQEzBAABCgAdFiEEZoWumedRZ7yvyN81+9DbCVqeKkQFAmnBPPwACgkQ+9DbCVqe
# KkRwEQf+MGnOOKRVoRU4eRjp/OqcYEBzR5L3SU/lLVZ261tqGpes2ZlMdsam1cBS
# yk/Cv+M9vHPpD0qKo1opo6CB8pBn6cjcPHE09bUxvgcylok9ZfPTMp/z9RLllW0l
# 8WhVkQ+dzWJj4tWoAcOjWgadgGhf4sp6whUX/TC3wSSpGFRR/2MERlCQab9743dR
# dSh3+NUp43h9wgb2AixKwrefos8Wv3NH5/p6BZ3IHEvD7Apwuo4RkTEebloCfJFk
# 67GbxslbOYBYNTjkVRR0o3CATDXOmI7804T1TPKI/nc/KSumY0BcR2omDqc8JVqt
# 7OmlRxpWRJ1DN7omlaHVPbGJRcww1A==
# =1leB
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon Mar 23 13:15:40 2026 GMT
# gpg: using RSA key 6685AE99E75167BCAFC8DF35FBD0DB095A9E2A44
# gpg: Good signature from "Alex Bennée (Master Work Key) <alex.bennee@linaro.org>" [full]
# Primary key fingerprint: 6685 AE99 E751 67BC AFC8 DF35 FBD0 DB09 5A9E 2A44
* tag 'pull-11.0-testing-updates-230326-1' of https://gitlab.com/stsquad/qemu:
tests: Replace ncat with socat in migration test and drop ncat from containers
tests/docker: Update the opensuse-leap container file to version 16
tests/lcitool: Update openSUSE to version 16
tests/lcitool: Remove python3-sqlite3 from the list of needed packages
tests/functional: add VBSA linux tests
tests/functional: allow tests to define decompression target
tests/tcg/multiarch/linux-test: use portable alternative for dirent64
tests/tcg: allow filtering of TCG tests
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This avoids a redirect from the old to the new URL.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
All examples on https://github.com/Agnoctopus/libu2f-emu/ don't
simply include u2f-emu.h without any added directory.
The additional include directory does not exist when libu2f
was built with meson.
It's up to pkgconfig to make sure that u2f-emu.h is found in any case.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
The uapi definitions are marked with __packed hints in the kernel
headers, since we want to keep the contract of the Microsoft Hypervisor
ABI explicit, we should also added them in our vendored files, with a
few notable exceptions where the attribute is a noop.
Signed-off-by: Magnus Kulke <magnuskulke@linux.microsoft.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20260323120613.355019-1-magnuskulke@linux.microsoft.com>
[PMD: Do not include "qemu/compiler.h"]
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
While reworking the address format width in commit 6ad593a75a we
introduce a bug, leading to addresses being displayed with too many
zeroes:
$ qemu-system-ppc -monitor stdio -S
QEMU 10.2.90 monitor - type 'help' for more information
(qemu) x/x 0
0000000000000000000000000000000000000000000000000000000000000000: 0x00000000
(qemu) x/x 0xfff00000
00000000000000000000000000000000000000000000000000000000fff00000: 0x60000000
$ qemu-system-ppc64 -monitor stdio -S
QEMU 10.2.90 monitor - type 'help' for more information
(qemu) x/x 0
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000: 0x00000000
Correct the format width to restore the previous behavior:
$ qemu-system-ppc -monitor stdio -S
QEMU 10.2.90 monitor - type 'help' for more information
(qemu) x/x 0
00000000: 0x00000000
$ qemu-system-ppc64 -monitor stdio -S
QEMU 10.2.90 monitor - type 'help' for more information
(qemu) x/x 0
0000000000000000: 0x00000000
Fixes: 6ad593a75a ("monitor/hmp: Use plain uint64_t @addr argument in memory_dump()")
Reported-by: BALATON Zoltan <balaton@eik.bme.hu>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20260323095020.66658-1-philmd@linaro.org>
Currently, DMA memory operation errors in the ftgmac100 model are not
all tested and this can lead to a guest-triggerable denial of service
as described in https://gitlab.com/qemu-project/qemu/-/work_items/3335.
To fix this, check the return value of ftgmac100_write_bd() in the TX
path and exit the TX loop on error to prevent further processing. In
the event of a DMA error, also set FTGMAC100_INT_AHB_ERR interrupt
flag as appropriate.
The FTGMAC100_INT_AHB_ERR interrupt status bit only applies to the
AST2400 SoC; on newer Aspeed SoCs, it is a reserved bit.
Nevertheless, since it is supported by the Linux driver and it should
be safe to use in the QEMU implementation across all SoCs.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3335
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Reviewed-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20260322215732.387383-3-clg@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
