Branch: refs/heads/staging-9.2
Home: https://github.com/qemu/qemu
Commit: ea3b821595fa474366743a293c19fa20ceb8506f
https://github.com/qemu/qemu/commit/ea3b821595fa474366743a293c19fa20ceb8506f
Author: Fabiano Rosas <[email protected]>
Date: 2025-01-13 (Mon, 13 Jan 2025)
Changed paths:
M scripts/analyze-migration.py
Log Message:
-----------
migration: Add more error handling to analyze-migration.py
The analyze-migration script was seen failing in s390x in misterious
ways. It seems we're reaching the VMSDFieldStruct constructor without
any fields, which would indicate an empty .subsection entry, a
VMSTATE_STRUCT with no fields or a vmsd with no fields. We don't have
any of those, at least not without the unmigratable flag set, so this
should never happen.
Add some debug statements so that we can see what's going on the next
time the issue happens.
Reviewed-by: Peter Xu <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit 86bee9e0c761a3d0e67c43b44001fd752f894cb0)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: abb738ad333a8f5efe2cb7a76166a4375a782253
https://github.com/qemu/qemu/commit/abb738ad333a8f5efe2cb7a76166a4375a782253
Author: Fabiano Rosas <[email protected]>
Date: 2025-01-13 (Mon, 13 Jan 2025)
Changed paths:
M migration/vmstate.c
Log Message:
-----------
migration: Remove unused argument in vmsd_desc_field_end
Reviewed-by: Peter Xu <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit 2aead53d39b828f8d9d0769ffa3579dadd64d846)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: e3839b0c19280be945a2af42b66483c09732bc5f
https://github.com/qemu/qemu/commit/e3839b0c19280be945a2af42b66483c09732bc5f
Author: Fabiano Rosas <[email protected]>
Date: 2025-01-13 (Mon, 13 Jan 2025)
Changed paths:
M scripts/analyze-migration.py
Log Message:
-----------
migration: Fix parsing of s390 stream
The parsing for the S390StorageAttributes section is currently leaving
an unconsumed token that is later interpreted by the generic code as
QEMU_VM_EOF, cutting the parsing short.
The migration will issue a STATTR_FLAG_DONE between iterations, which
the script consumes correctly, but there's a final STATTR_FLAG_EOS at
.save_complete that the script is ignoring. Since the EOS flag is a
u64 0x1ULL and the stream is big endian, on little endian hosts a byte
read from it will be 0x0, the same as QEMU_VM_EOF.
Fixes: 81c2c9dd5d ("tests/qtest/migration-test: Fix analyze-migration.py for
s390x")
Reviewed-by: Peter Xu <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit 69d1f784569fdb950f2923c3b6d00d7c1b71acc1)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: e7a9d9342865e5f7dcd836afa77990e1980b1986
https://github.com/qemu/qemu/commit/e7a9d9342865e5f7dcd836afa77990e1980b1986
Author: Fabiano Rosas <[email protected]>
Date: 2025-01-13 (Mon, 13 Jan 2025)
Changed paths:
M hw/s390x/s390-virtio-ccw.c
Log Message:
-----------
s390x: Fix CSS migration
Commit a55ae46683 ("s390: move css_migration_enabled from machine to
css.c") disabled CSS migration globally instead of doing it
per-instance.
CC: Paolo Bonzini <[email protected]>
CC: [email protected] #9.1
Fixes: a55ae46683 ("s390: move css_migration_enabled from machine to css.c")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2704
Reviewed-by: Thomas Huth <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit c76ee1f6255c3988a9447d363bb17072f1ec84e1)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 3ba6e1164a45f3345816921fec76d7bd12ed215a
https://github.com/qemu/qemu/commit/3ba6e1164a45f3345816921fec76d7bd12ed215a
Author: Fabiano Rosas <[email protected]>
Date: 2025-01-13 (Mon, 13 Jan 2025)
Changed paths:
M migration/vmstate-types.c
M scripts/analyze-migration.py
Log Message:
-----------
migration: Rename vmstate_info_nullptr
Rename vmstate_info_nullptr from "uint64_t" to "nullptr". This vmstate
actually reads and writes just a byte, so the proper name would be
uint8. However, since this is a marker for a NULL pointer, it's
convenient to have a more explicit name that can be identified by the
consumers of the JSON part of the stream.
Change the name to "nullptr" and add support for it in the
analyze-migration.py script. Arbitrarily use the name of the type as
the value of the field to avoid the script showing 0x30 or '0', which
could be confusing for readers.
Reviewed-by: Peter Xu <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit f52965bf0eeee28e89933264f1a9dbdcdaa76a7e)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 46f2af3e3917b3aa8b65fdabcff79c2ce52b9e7f
https://github.com/qemu/qemu/commit/46f2af3e3917b3aa8b65fdabcff79c2ce52b9e7f
Author: Peter Xu <[email protected]>
Date: 2025-01-13 (Mon, 13 Jan 2025)
Changed paths:
M migration/vmstate.c
Log Message:
-----------
migration: Dump correct JSON format for nullptr replacement
QEMU plays a trick with null pointers inside an array of pointers in a VMSD
field. See 07d4e69147 ("migration/vmstate: fix array of ptr with
nullptrs") for more details on why. The idea makes sense in general, but
it may overlooked the JSON writer where it could write nothing in a
"struct" in the JSON hints section.
We hit some analyze-migration.py issues on s390 recently, showing that some
of the struct field contains nothing, like:
{"name": "css", "array_len": 256, "type": "struct", "struct": {}, "size": 1}
As described in details by Fabiano:
https://lore.kernel.org/r/[email protected]
It could be that we hit some null pointers there, and JSON was gone when
they're null pointers.
To fix it, instead of hacking around only at VMStateInfo level, do that
from VMStateField level, so that JSON writer can also be involved. In this
case, JSON writer will replace the pointer array (which used to be a
"struct") to be the real representation of the nullptr field.
Signed-off-by: Peter Xu <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit 9867c3a7ced12dd7519155c047eb2c0098a11c5f)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 82565fb6b36cd37a37ff0b3380cbd58f76449957
https://github.com/qemu/qemu/commit/82565fb6b36cd37a37ff0b3380cbd58f76449957
Author: Fabiano Rosas <[email protected]>
Date: 2025-01-13 (Mon, 13 Jan 2025)
Changed paths:
M migration/vmstate.c
M scripts/analyze-migration.py
Log Message:
-----------
migration: Fix arrays of pointers in JSON writer
Currently, if an array of pointers contains a NULL pointer, that
pointer will be encoded as '0' in the stream. Since the JSON writer
doesn't define a "pointer" type, that '0' will now be an uint8, which
is different from the original type being pointed to, e.g. struct.
(we're further calling uint8 "nullptr", but that's irrelevant to the
issue)
That mixed-type array shouldn't be compressed, otherwise data is lost
as the code currently makes the whole array have the type of the first
element:
css = {NULL, NULL, ..., 0x5555568a7940, NULL};
{"name": "s390_css", "instance_id": 0, "vmsd_name": "s390_css",
"version": 1, "fields": [
...,
{"name": "css", "array_len": 256, "type": "nullptr", "size": 1},
...,
]}
In the above, the valid pointer at position 254 got lost among the
compressed array of nullptr.
While we could disable the array compression when a NULL pointer is
found, the JSON part of the stream still makes part of downtime, so we
should avoid writing unecessary bytes to it.
Keep the array compression in place, but if NULL and non-NULL pointers
are mixed break the array into several type-contiguous pieces :
css = {NULL, NULL, ..., 0x5555568a7940, NULL};
{"name": "s390_css", "instance_id": 0, "vmsd_name": "s390_css",
"version": 1, "fields": [
...,
{"name": "css", "array_len": 254, "type": "nullptr", "size": 1},
{"name": "css", "type": "struct", "struct": {"vmsd_name": "s390_css_img",
... }, "size": 768},
{"name": "css", "type": "nullptr", "size": 1},
...,
]}
Now each type-discontiguous region will become a new JSON entry. The
reader should interpret this as a concatenation of values, all part of
the same field.
Parsing the JSON with analyze-script.py now shows the proper data
being pointed to at the places where the pointer is valid and
"nullptr" where there's NULL:
"s390_css (14)": {
...
"css": [
"nullptr",
"nullptr",
...
"nullptr",
{
"chpids": [
{
"in_use": "0x00",
"type": "0x00",
"is_virtual": "0x00"
},
...
]
},
"nullptr",
}
Reviewed-by: Peter Xu <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit 35049eb0d2fc72bb8c563196ec75b4d6c13fce02)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 7fb9ce40e75e06fe6d25c835830832e7c3940d03
https://github.com/qemu/qemu/commit/7fb9ce40e75e06fe6d25c835830832e7c3940d03
Author: Yuan Liu <[email protected]>
Date: 2025-01-13 (Mon, 13 Jan 2025)
Changed paths:
M migration/multifd-nocomp.c
Log Message:
-----------
multifd: bugfix for migration using compression methods
When compression is enabled on the migration channel and
the pages processed are all zero pages, these pages will
not be sent and updated on the target side, resulting in
incorrect memory data on the source and target sides.
The root cause is that all compression methods call
multifd_send_prepare_common to determine whether to compress
dirty pages, but multifd_send_prepare_common does not update
the IOV of MultiFDPacket_t when all dirty pages are zero pages.
The solution is to always update the IOV of MultiFDPacket_t
regardless of whether the dirty pages are all zero pages.
Fixes: 303e6f54f9 ("migration/multifd: Implement zero page transmission on the
multifd thread.")
Cc: [email protected] #9.0+
Signed-off-by: Yuan Liu <[email protected]>
Reviewed-by: Jason Zeng <[email protected]>
Reviewed-by: Peter Xu <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit cdc3970f8597ebdc1a4c2090cfb4d11e297329ed)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: fcd5a157e6b21412bafb146027eb74057e053271
https://github.com/qemu/qemu/commit/fcd5a157e6b21412bafb146027eb74057e053271
Author: Yuan Liu <[email protected]>
Date: 2025-01-13 (Mon, 13 Jan 2025)
Changed paths:
M migration/multifd-qpl.c
Log Message:
-----------
multifd: bugfix for incorrect migration data with QPL compression
When QPL compression is enabled on the migration channel and the same
dirty page changes from a normal page to a zero page in the iterative
memory copy, the dirty page will not be updated to a zero page again
on the target side, resulting in incorrect memory data on the source
and target sides.
The root cause is that the target side does not record the normal pages
to the receivedmap.
The solution is to add ramblock_recv_bitmap_set_offset in target side
to record the normal pages.
Signed-off-by: Yuan Liu <[email protected]>
Reviewed-by: Jason Zeng <[email protected]>
Reviewed-by: Peter Xu <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit 2588a5f99b0c3493b4690e3ff01ed36f80e830cc)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 9a17a650667bee2249310744b4508e9647b9a5bf
https://github.com/qemu/qemu/commit/9a17a650667bee2249310744b4508e9647b9a5bf
Author: Yuan Liu <[email protected]>
Date: 2025-01-13 (Mon, 13 Jan 2025)
Changed paths:
M migration/multifd-qatzip.c
Log Message:
-----------
multifd: bugfix for incorrect migration data with qatzip compression
When QPL compression is enabled on the migration channel and the same
dirty page changes from a normal page to a zero page in the iterative
memory copy, the dirty page will not be updated to a zero page again
on the target side, resulting in incorrect memory data on the source
and target sides.
The root cause is that the target side does not record the normal pages
to the receivedmap.
The solution is to add ramblock_recv_bitmap_set_offset in target side
to record the normal pages.
Signed-off-by: Yuan Liu <[email protected]>
Reviewed-by: Jason Zeng <[email protected]>
Reviewed-by: Peter Xu <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit a523bc52166c80d8a04d46584f9f3868bd53ef69)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: bb6940dbad20a90515fd53f901b370251e7a25df
https://github.com/qemu/qemu/commit/bb6940dbad20a90515fd53f901b370251e7a25df
Author: Philippe Mathieu-Daudé <[email protected]>
Date: 2025-01-13 (Mon, 13 Jan 2025)
Changed paths:
M tests/functional/test_rx_gdbsim.py
Log Message:
-----------
tests/functional/test_rx_gdbsim: Use stable URL for test_linux_sash
Yoshinori said [*] URL references on OSDN were stable, but they
appear not to be. Mirror the artifacts on GitHub to avoid failures
while testing on CI.
[*] https://www.mail-archive.com/[email protected]/msg686487.html
Cc: Yoshinori Sato <[email protected]>
Reported-by: Alex Bennée <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
[huth: Adapt the patch to the new version in the functional framework]
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit ec2dfb7c389b94d71ee825caa20b709d5df6c166)
Signed-off-by: Michael Tokarev <[email protected]>
(Mjt: fixup for missing v9.2.0-421-g65d35a4e27a8 "tests/functional: convert
tests to new uncompress helper")
Commit: 48876bfc471ec02e5edcc935ba93e14426d891ab
https://github.com/qemu/qemu/commit/48876bfc471ec02e5edcc935ba93e14426d891ab
Author: Keoseong Park <[email protected]>
Date: 2025-01-15 (Wed, 15 Jan 2025)
Changed paths:
M hw/ufs/ufs.c
M tests/qtest/ufs-test.c
Log Message:
-----------
hw/ufs: Adjust value to match CPU's endian format
In ufs_write_attr_value(), the value parameter is handled in the CPU's
endian format but provided in big-endian format by the caller. Thus, it
is converted to the CPU's endian format. The related test code is also
fixed to reflect this change.
Fixes: 7c85332a2b3e ("hw/ufs: minor bug fixes related to ufs-test")
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Signed-off-by: Keoseong Park <[email protected]>
Reviewed-by: Jeuk Kim <[email protected]>
Message-ID: <20250107084356epcms2p2af4d86432174d76ea57336933e46b4c3@epcms2p2>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit 4572dacc33e232a7c951ba7ba7a20887fad29e71)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 3b9b5cbe0ae0aa0e2fb166611d0d407df4a307e7
https://github.com/qemu/qemu/commit/3b9b5cbe0ae0aa0e2fb166611d0d407df4a307e7
Author: Philippe Mathieu-Daudé <[email protected]>
Date: 2025-01-17 (Fri, 17 Jan 2025)
Changed paths:
M tests/qtest/boot-serial-test.c
Log Message:
-----------
tests/qtest/boot-serial-test: Correct HPPA machine name
Commit 7df6f751176 ("hw/hppa: Split out machine creation")
renamed the 'hppa' machine as 'B160L', but forgot to update
the boot serial test, which ended being skipped.
Cc: [email protected]
Fixes: 7df6f751176 ("hw/hppa: Split out machine creation")
Reported-by: Thomas Huth <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit a87077316ed2f1c1c8ba8faf05feed9dbf0f2fee)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 69e29c484f68e0c754a5da6772ebd769de1c7fbf
https://github.com/qemu/qemu/commit/69e29c484f68e0c754a5da6772ebd769de1c7fbf
Author: Gabriel Barrantes <[email protected]>
Date: 2025-01-17 (Fri, 17 Jan 2025)
Changed paths:
M backends/cryptodev-vhost-user.c
Log Message:
-----------
backends/cryptodev-vhost-user: Fix local_error leaks
Do not propagate error to the upper, directly output the error
to avoid leaks.
Fixes: 2fda101de07 ("virtio-crypto: Support asynchronous mode")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2714
Signed-off-by: Gabriel Barrantes <[email protected]>
Reviewed-by: zhenwei pi <[email protected]>
Message-Id:
<dm8pr13mb50781054a4fdace6f4fb6469b3...@dm8pr13mb5078.namprd13.prod.outlook.com>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit 78b0c15a563ac4be5afb0375602ca0a3adc6c442)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 4a3538e6f287b383daa82410769cec1b79e6df02
https://github.com/qemu/qemu/commit/4a3538e6f287b383daa82410769cec1b79e6df02
Author: Phil Dennis-Jordan <[email protected]>
Date: 2025-01-17 (Fri, 17 Jan 2025)
Changed paths:
M hw/usb/hcd-xhci-pci.c
Log Message:
-----------
hw/usb/hcd-xhci-pci: Use modulo to select MSI vector as per spec
QEMU would crash with a failed assertion if the XHCI controller
attempted to raise the interrupt on an interrupter corresponding
to a MSI vector with a higher index than the highest configured
for the device by the guest driver.
This behaviour is correct on the MSI/PCI side: per PCI 3.0 spec,
devices must ensure they do not send MSI notifications for
vectors beyond the range of those allocated by the system/driver
software. Unlike MSI-X, there is no generic way for handling
aliasing in the case of fewer allocated vectors than requested,
so the specifics are up to device implementors. (Section
6.8.3.4. "Sending Messages")
It turns out the XHCI spec (Implementation Note in section 4.17,
"Interrupters") requires that the host controller signal the MSI
vector with the number computed by taking the interrupter number
modulo the number of enabled MSI vectors.
This change introduces that modulo calculation, fixing the
failed assertion. This makes the device work correctly in MSI mode
with macOS's XHCI driver, which only allocates a single vector.
Signed-off-by: Phil Dennis-Jordan <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit bb5b7fced6b5d3334ab20702fc846e47bb1fb731)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 91b2cb9a78ae3b0487497e004c660016bc7b7b44
https://github.com/qemu/qemu/commit/91b2cb9a78ae3b0487497e004c660016bc7b7b44
Author: Sebastian Ott <[email protected]>
Date: 2025-01-17 (Fri, 17 Jan 2025)
Changed paths:
M hw/pci/pcie.c
Log Message:
-----------
pci: ensure valid link status bits for downstream ports
PCI hotplug for downstream endpoints on arm fails because Linux'
PCIe hotplug driver doesn't like the QEMU provided LNKSTA:
pcieport 0000:08:01.0: pciehp: Slot(2): Card present
pcieport 0000:08:01.0: pciehp: Slot(2): Link Up
pcieport 0000:08:01.0: pciehp: Slot(2): Cannot train link: status 0x2000
There's 2 cases where LNKSTA isn't setup properly:
* the downstream device has no express capability
* max link width of the bridge is 0
Move the sanity checks added via 88c869198aa63
("pci: Sanity test minimum downstream LNKSTA") outside of the
branch to make sure downstream ports always have a valid LNKSTA.
Signed-off-by: Sebastian Ott <[email protected]>
Tested-by: Zhenyu Zhang <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Alex Williamson <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit 694632fd44987cc4618612a38ad151047524a590)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: c8fb662a5817ee3267430ffdc711c6ec7a4cb11e
https://github.com/qemu/qemu/commit/c8fb662a5817ee3267430ffdc711c6ec7a4cb11e
Author: Nicholas Piggin <[email protected]>
Date: 2025-01-17 (Fri, 17 Jan 2025)
Changed paths:
M hw/pci/msix.c
Log Message:
-----------
pci/msix: Fix msix pba read vector poll end calculation
The end vector calculation has a bug that results in polling fewer
than required vectors when reading at a non-zero offset in PBA memory.
Fixes: bbef882cc193 ("msi: add API to get notified about pending bit poll")
Signed-off-by: Nicholas Piggin <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit 42e2a7a0ab23784e44fcb18369e06067abc89305)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: b107128ea6b3755e7ab5f9392ddffe8910caa9d0
https://github.com/qemu/qemu/commit/b107128ea6b3755e7ab5f9392ddffe8910caa9d0
Author: Igor Mammedov <[email protected]>
Date: 2025-01-17 (Fri, 17 Jan 2025)
Changed paths:
M tests/qtest/bios-tables-test-allowed-diff.h
Log Message:
-----------
tests: acpi: whitelist expected blobs
Signed-off-by: Igor Mammedov <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit 1ad32644fe4c9fb25086be15a66dde1d55d3410f)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 7170aa66aaf794c972c31d126235716b28f00cdd
https://github.com/qemu/qemu/commit/7170aa66aaf794c972c31d126235716b28f00cdd
Author: Igor Mammedov <[email protected]>
Date: 2025-01-17 (Fri, 17 Jan 2025)
Changed paths:
M hw/i386/acpi-build.c
Log Message:
-----------
pci: acpi: Windows 'PCI Label Id' bug workaround
Current versions of Windows call _DSM(func=7) regardless
of whether it is supported or not. It leads to NICs having bogus
'PCI Label Id = 0', where none should be set at all.
Also presence of 'PCI Label Id' triggers another Windows bug
on localized versions that leads to hangs. The later bug is fixed
in latest updates for 'Windows Server' but not in consumer
versions of Windows (and there is no plans to fix it
as far as I'm aware).
Given it's easy, implement Microsoft suggested workaround
(return invalid Package) so that affected Windows versions
could boot on QEMU.
This would effectvely remove bogus 'PCI Label Id's on NICs,
but MS teem confirmed that flipping 'PCI Label Id' should not
change 'Network Connection' ennumeration, so it should be safe
for QEMU to change _DSM without any compat code.
Smoke tested with WinXP and WS2022
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/774
Signed-off-by: Igor Mammedov <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit 0b053391985abcc40b16ac8fc4a7f6588d1d95c1)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 73ca3ba37d6c20174bc649663c8fc359e6fecda9
https://github.com/qemu/qemu/commit/73ca3ba37d6c20174bc649663c8fc359e6fecda9
Author: Igor Mammedov <[email protected]>
Date: 2025-01-17 (Fri, 17 Jan 2025)
Changed paths:
M tests/data/acpi/x86/pc/DSDT
M tests/data/acpi/x86/pc/DSDT.acpierst
M tests/data/acpi/x86/pc/DSDT.acpihmat
M tests/data/acpi/x86/pc/DSDT.bridge
M tests/data/acpi/x86/pc/DSDT.cphp
M tests/data/acpi/x86/pc/DSDT.dimmpxm
M tests/data/acpi/x86/pc/DSDT.hpbridge
M tests/data/acpi/x86/pc/DSDT.ipmikcs
M tests/data/acpi/x86/pc/DSDT.memhp
M tests/data/acpi/x86/pc/DSDT.nohpet
M tests/data/acpi/x86/pc/DSDT.numamem
M tests/data/acpi/x86/pc/DSDT.roothp
M tests/data/acpi/x86/q35/DSDT
M tests/data/acpi/x86/q35/DSDT.acpierst
M tests/data/acpi/x86/q35/DSDT.acpihmat
M tests/data/acpi/x86/q35/DSDT.acpihmat-generic-x
M tests/data/acpi/x86/q35/DSDT.acpihmat-noinitiator
M tests/data/acpi/x86/q35/DSDT.applesmc
M tests/data/acpi/x86/q35/DSDT.bridge
M tests/data/acpi/x86/q35/DSDT.core-count
M tests/data/acpi/x86/q35/DSDT.core-count2
M tests/data/acpi/x86/q35/DSDT.cphp
M tests/data/acpi/x86/q35/DSDT.cxl
M tests/data/acpi/x86/q35/DSDT.dimmpxm
M tests/data/acpi/x86/q35/DSDT.ipmibt
M tests/data/acpi/x86/q35/DSDT.ipmismbus
M tests/data/acpi/x86/q35/DSDT.ivrs
M tests/data/acpi/x86/q35/DSDT.memhp
M tests/data/acpi/x86/q35/DSDT.mmio64
M tests/data/acpi/x86/q35/DSDT.multi-bridge
M tests/data/acpi/x86/q35/DSDT.nohpet
M tests/data/acpi/x86/q35/DSDT.numamem
M tests/data/acpi/x86/q35/DSDT.pvpanic-isa
M tests/data/acpi/x86/q35/DSDT.thread-count
M tests/data/acpi/x86/q35/DSDT.thread-count2
M tests/data/acpi/x86/q35/DSDT.tis.tpm12
M tests/data/acpi/x86/q35/DSDT.tis.tpm2
M tests/data/acpi/x86/q35/DSDT.type4-count
M tests/data/acpi/x86/q35/DSDT.viot
M tests/data/acpi/x86/q35/DSDT.xapic
M tests/qtest/bios-tables-test-allowed-diff.h
Log Message:
-----------
tests: acpi: update expected blobs
_DSM function 7 AML should have followig change:
If ((Arg2 == 0x07))
{
- Local0 = Package (0x02)
- {
- Zero,
- ""
- }
Local2 = AIDX (DerefOf (Arg4 [Zero]), DerefOf (Arg4 [One]
))
- Local0 [Zero] = Local2
+ Local0 = Package (0x02) {}
+ If (!((Local2 == Zero) || (Local2 == 0xFFFFFFFF)))
+ {
+ Local0 [Zero] = Local2
+ Local0 [One] = ""
+ }
+
Return (Local0)
}
}
Signed-off-by: Igor Mammedov <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit 9fb1c9a1bb26e111ee5fa5538070cd684de14c08)
Signed-off-by: Michael Tokarev <[email protected]>
(Mjt: regenerate acpi tables for 9.2)
Commit: acc4e8b69b9d7a6fc30f0be63ce0bf4dffd5d560
https://github.com/qemu/qemu/commit/acc4e8b69b9d7a6fc30f0be63ce0bf4dffd5d560
Author: Li Zhijian <[email protected]>
Date: 2025-01-17 (Fri, 17 Jan 2025)
Changed paths:
M hw/mem/cxl_type3.c
Log Message:
-----------
hw/cxl: Fix msix_notify: Assertion `vector < dev->msix_entries_nr`
This assertion always happens when we sanitize the CXL memory device.
$ echo 1 > /sys/bus/cxl/devices/mem0/security/sanitize
It is incorrect to register an MSIX number beyond the device's capability.
Increase the device's MSIX number to cover the mailbox msix number(9).
Fixes: 43efb0bfad2b ("hw/cxl/mbox: Wire up interrupts for background
completion")
Signed-off-by: Li Zhijian <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit 1ce979e7269a34d19ea1a65808df014d8b2acbf6)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 1032dccadb647cf517c9ee57ffd7acca2f88df5d
https://github.com/qemu/qemu/commit/1032dccadb647cf517c9ee57ffd7acca2f88df5d
Author: Paolo Bonzini <[email protected]>
Date: 2025-01-17 (Fri, 17 Jan 2025)
Changed paths:
M scripts/make-release
Log Message:
-----------
make-release: only leave tarball of wrap-file subprojects
The QEMU source archive is including the sources downloaded from crates.io
in both tarball form (in subprojects/packagecache) and expanded/patched
form (in the subprojects directory). The former is the more authoritative
form, as it has a hash that can be verified in the wrap file and checked
against the download URL, so keep that one only. This works also with
--disable-download; when building QEMU for the first time from the
tarball, Meson will print something like
Using proc-macro2-1-rs source from cache.
for each subproject, and then go on to extract the tarball and apply the
overlay or the patches in subprojects/packagefiles.
Reported-by: Michael Tokarev <[email protected]>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2719
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit be27b5149c86f81531f8fc609baf3480fc4d9ca0)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 2f5f6cb90ab3b854044db773e418ef9867d9c9ff
https://github.com/qemu/qemu/commit/2f5f6cb90ab3b854044db773e418ef9867d9c9ff
Author: Zhao Liu <[email protected]>
Date: 2025-01-17 (Fri, 17 Jan 2025)
Changed paths:
M target/i386/cpu.c
Log Message:
-----------
i386/cpu: Mark avx10_version filtered when prefix is NULL
In x86_cpu_filter_features(), if host doesn't support AVX10, the
configured avx10_version should be marked as filtered regardless of
whether prefix is NULL or not.
Check prefix before warn_report() instead of checking for
have_filtered_features.
Cc: [email protected]
Fixes: commit bccfb846fd52 ("target/i386: add AVX10 feature and AVX10 version
property")
Signed-off-by: Zhao Liu <[email protected]>
Reviewed-by: Tao Su <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit cf4c263551886964c5d58bd7b675b13fd497b402)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: dcb80cd90832b11133f3c73706c63698f3b6e714
https://github.com/qemu/qemu/commit/dcb80cd90832b11133f3c73706c63698f3b6e714
Author: Daniel P. Berrangé <[email protected]>
Date: 2025-01-22 (Wed, 22 Jan 2025)
Changed paths:
M crypto/pbkdf.c
Log Message:
-----------
crypto: fix bogus error benchmarking pbkdf on fast machines
We're seeing periodic reports of errors like:
$ qemu-img create -f luks --object secret,data=123456,id=sec0 \
-o key-secret=sec0 luks-info.img 1M
Formatting 'luks-info.img', fmt=luks size=1048576 key-secret=sec0
qemu-img: luks-info.img: Unable to get accurate CPU usage
This error message comes from a recent attempt to workaround a
kernel bug with measuring rusage in long running processes:
commit c72cab5ad9f849bbcfcf4be7952b8b8946cc626e
Author: Tiago Pasqualini <[email protected]>
Date: Wed Sep 4 20:52:30 2024 -0300
crypto: run qcrypto_pbkdf2_count_iters in a new thread
Unfortunately this has a subtle bug on machines which are very fast.
On the first time around the loop, the 'iterations' value is quite
small (1 << 15), and so will run quite fast. Testing has shown that
some machines can complete this benchmarking task in as little as
7 milliseconds.
Unfortunately the 'getrusage' data is not updated at the time of
the 'getrusage' call, it is done asynchronously by the scheduler.
The 7 millisecond completion time for the benchmark is short
enough that 'getrusage' sometimes reports 0 accumulated execution
time.
As a result the 'delay_ms == 0' sanity check in the above commit
is triggering non-deterministically on such machines.
The benchmarking loop intended to run multiple times, increasing
the 'iterations' value until the benchmark ran for > 500 ms, but
the sanity check doesn't allow this to happen.
To fix it, we keep a loop counter and only run the sanity check
after we've been around the loop more than 5 times. At that point
the 'iterations' value is high enough that even with infrequent
updates of 'getrusage' accounting data on fast machines, we should
see a non-zero value.
Fixes:
https://lore.kernel.org/qemu-devel/[email protected]/
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2336437
Reported-by: Thomas Huth <[email protected]>
Reported-by: Richard W.M. Jones <[email protected]>
Tested-by: Thomas Huth <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit 145f12ea885c8fcfbe2d0ac5230630f071b5a9fb)
Signed-off-by: Michael Tokarev <[email protected]>
Compare: https://github.com/qemu/qemu/compare/bbc711db5b06...dcb80cd90832
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
