On 2026/06/23 5:23, Peter Xu wrote:
On Thu, Jun 11, 2026 at 03:35:47PM +0900, Akihiko Odaki wrote:
Supersedes: <[email protected]>
("[PATCH] system/physmem: Assert migration invariants")
ram_mig_ram_block_resized() already aborts migration when migratable RAM
is resized. Extend the same handling to other unsupported changes to the
migratable RAMBlock set, such as removing a migratable RAMBlock or
changing a RAMBlock's migratable state.
Signed-off-by: Akihiko Odaki <[email protected]>
---
Akihiko Odaki (3):
system/physmem: Pass RAMBlock to RAMBlockNotifier callbacks
system/physmem: Notify RAMBlock migratable and idstr changes
migration/ram: Abort on unsupported migratable RAM changes
Thanks for looking at this, Akihiko.
I understand this is a protection to the system to trap error use cases.
The question I have is do we have any possible way to trigger these.
I worry we add a bunch of code and notifiers, and then there's zero way to
trigger, essentially add dead code.
Logically we could already add assert() on things we don't expect to
happen. This case might be slightly risky, but still I think we can also
consider things like error_report_once() instead of introducing slightly
complex notifiers just to cover what we think shouldn't happen.
Or do you have way to trigger any of these notifiers?
I simply followed what's already done for resize(), expecting resize()
does the correct thing and following it won't introduce a regression.
PS: today I went back and I wanted to try how the existing resize()
notifier would trigger, I can't even reproduce it with David's example
here:
https://lore.kernel.org/qemu-devel/[email protected]/#t
I can trap a qemu_ram_resize(), but that's invoked with newsize==rb->size,
so it didn't really notify a thing. I don't really know how to trigger
ram_block_notify_resize(). If you know, please share.
I made an LLM amend the reproducer. Below is its output.
Regards,
Akihiko Odaki
LLM output:
A synthetic but effective variant is to add custom ACPI filler tables so
the initial `etc/acpi/tables` blob is just under the 128 KiB alignment
bucket, then let the normal boot-time fw_cfg ACPI rebuild push it over.
I tested this shape:
```sh
truncate -s 65000 /tmp/fill1
truncate -s 50600 /tmp/fill2
```
Then add to the original-ish command:
```sh
-device pcie-root-port,id=rp0,chassis=1,slot=1 \
-acpitable sig=FI1A,data=/tmp/fill1 \
-acpitable sig=FI2A,data=/tmp/fill2
```
Observed via `info ramblock`:
```text
before cont:
/rom@etc/acpi/tables Used 0x0000000000020000
after cont:
/rom@etc/acpi/tables Used 0x0000000000040000
```
So this does produce a real RAMBlock used-size growth during boot in the
current tree. With migration started before `cont` using a stalled
`exec:` target, `info migrate` moved to `cancelling`, which is
consistent with the current resize-during-precopy abort path.
The key is not the root port itself; the key is making the ACPI table
rebuild cross `ACPI_BUILD_TABLE_SIZE` alignment. The filler is a bit
artificial, but it is a good stress variant for the exact class of bug.
