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? Thanks, -- Peter Xu
