Branch: refs/heads/staging-9.1
Home: https://github.com/qemu/qemu
Commit: 6b45ab51736833f1fe586879a46819e5cfbc4ae7
https://github.com/qemu/qemu/commit/6b45ab51736833f1fe586879a46819e5cfbc4ae7
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: aacde7dfb7acf289a2a521e3754ab3d29806823f
https://github.com/qemu/qemu/commit/aacde7dfb7acf289a2a521e3754ab3d29806823f
Author: Fabiano Rosas <[email protected]>
Date: 2025-01-18 (Sat, 18 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: 1e223152b64a57863a5480d8a7c2c832146022f2
https://github.com/qemu/qemu/commit/1e223152b64a57863a5480d8a7c2c832146022f2
Author: Fabiano Rosas <[email protected]>
Date: 2025-01-18 (Sat, 18 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: 7d2122b94acfe26b05691c7d5fe2376ebf558d8d
https://github.com/qemu/qemu/commit/7d2122b94acfe26b05691c7d5fe2376ebf558d8d
Author: Fabiano Rosas <[email protected]>
Date: 2025-01-18 (Sat, 18 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: 575ed2e688dc434d13608140d80ae2b7d0da62c7
https://github.com/qemu/qemu/commit/575ed2e688dc434d13608140d80ae2b7d0da62c7
Author: Fabiano Rosas <[email protected]>
Date: 2025-01-18 (Sat, 18 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: 15efc4a0ddaea3387b45525f4dabd100d5d82e0f
https://github.com/qemu/qemu/commit/15efc4a0ddaea3387b45525f4dabd100d5d82e0f
Author: Peter Xu <[email protected]>
Date: 2025-01-18 (Sat, 18 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: 58e5249e5bc845658b070cd8c97f04a98d8bac77
https://github.com/qemu/qemu/commit/58e5249e5bc845658b070cd8c97f04a98d8bac77
Author: Fabiano Rosas <[email protected]>
Date: 2025-01-18 (Sat, 18 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: b604a42faa14c26810880af553f0d95f4abbd1b6
https://github.com/qemu/qemu/commit/b604a42faa14c26810880af553f0d95f4abbd1b6
Author: Yuan Liu <[email protected]>
Date: 2025-01-18 (Sat, 18 Jan 2025)
Changed paths:
M migration/multifd.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]>
(Mjt: in 9.1 this code is in migration/multifd.c, not in
migration/multifd-nocomp.c)
Commit: 49da21ed5a7146cc1507322f04a789bef6d4a7d6
https://github.com/qemu/qemu/commit/49da21ed5a7146cc1507322f04a789bef6d4a7d6
Author: Yuan Liu <[email protected]>
Date: 2025-01-18 (Sat, 18 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: 07893634cbb40fcd38c37f7d74c4e4cab429769c
https://github.com/qemu/qemu/commit/07893634cbb40fcd38c37f7d74c4e4cab429769c
Author: Philippe Mathieu-Daudé <[email protected]>
Date: 2025-01-18 (Sat, 18 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: 34a2b679c552d3c14573f01e6a5ef3a1d021dd22
https://github.com/qemu/qemu/commit/34a2b679c552d3c14573f01e6a5ef3a1d021dd22
Author: Gabriel Barrantes <[email protected]>
Date: 2025-01-18 (Sat, 18 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: 98f7a50d4c86e4ef197e51b20da325b141c5e769
https://github.com/qemu/qemu/commit/98f7a50d4c86e4ef197e51b20da325b141c5e769
Author: Phil Dennis-Jordan <[email protected]>
Date: 2025-01-18 (Sat, 18 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: 9e0ece41fca502bba9b0dafd8f6549c84f7faeab
https://github.com/qemu/qemu/commit/9e0ece41fca502bba9b0dafd8f6549c84f7faeab
Author: Sebastian Ott <[email protected]>
Date: 2025-01-18 (Sat, 18 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: d00c5d29edb965e678ba6cd54ffe41b3fe8422d2
https://github.com/qemu/qemu/commit/d00c5d29edb965e678ba6cd54ffe41b3fe8422d2
Author: Nicholas Piggin <[email protected]>
Date: 2025-01-18 (Sat, 18 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: a988265bb85f850aa3ebe09f94248576e4f3e380
https://github.com/qemu/qemu/commit/a988265bb85f850aa3ebe09f94248576e4f3e380
Author: Igor Mammedov <[email protected]>
Date: 2025-01-18 (Sat, 18 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]>
(Mjt: remove q35/DSDT.acpihmat-generic-x which is not present in 9.1)
Commit: a4f807dfabf5affc9b7fe820a8d04d99dfefc2d5
https://github.com/qemu/qemu/commit/a4f807dfabf5affc9b7fe820a8d04d99dfefc2d5
Author: Igor Mammedov <[email protected]>
Date: 2025-01-18 (Sat, 18 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: 30faa99558e4b12af174c5d35a96859ff1aa0232
https://github.com/qemu/qemu/commit/30faa99558e4b12af174c5d35a96859ff1aa0232
Author: Igor Mammedov <[email protected]>
Date: 2025-01-18 (Sat, 18 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-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: rebuild acpi tables for 9.1)
Commit: 7594c49b95453c085d4da3903e6ffb79bae07c50
https://github.com/qemu/qemu/commit/7594c49b95453c085d4da3903e6ffb79bae07c50
Author: Li Zhijian <[email protected]>
Date: 2025-01-18 (Sat, 18 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]>
Compare: https://github.com/qemu/qemu/compare/afc57aa33812...7594c49b9545
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
