On 2025/10/03 3:47, Peter Xu wrote:
On Wed, Sep 17, 2025 at 07:32:47PM +0900, Akihiko Odaki wrote:
When updating memory mappings, pci_bridge_update_mappings() performed
the following operations:
1. Start a transaction
2. Delete the subregions from the container
3. Unparent the subregions
4. Initialize the subregions
5. End the transaction
This assumes the old subregion instances are finalized immediately after
3, but it is not true; the finalization is delayed until 5. Remove the
assumption by using functions to dynamically update MemoryRegions.
To Paolo - you can ignore this if you'll merge it. However I'm still
raising this as a pure question.
Could there be an explanation why it'll be delayed until step 5?
All the MRs involved in this patch are all aliases. I believe this rules
out any map() ref-takers. IIUC it is exactly what was marked exceptions in
the memory.rst here:
There is an exception to the above rule: it is okay to call
object_unparent at any time for an alias or a container region. It is
therefore also okay to create or destroy alias and container regions
dynamically during a device's lifetime.
This exceptional usage is valid because aliases and containers only help
QEMU building the guest's memory map; they are never accessed directly.
memory_region_ref and memory_region_unref are never called on aliases
or containers, and the above situation then cannot happen. Exploiting
this exception is rarely necessary, and therefore it is discouraged,
but nevertheless it is used in a few places.
I was expecting the current code should at least be fine, no?
You are right. This patch does nothing good so I'll drop it.
Regards,
Akihiko Odaki
