Some users of QOM need to be able to iterate over properties
defined against an object instance. Currently they are just
directly using the QTAIL macros against the object properties
data structure.
This is bad because it exposes them to changes in the data
structure used to store properties, as well as changes in
functionality such as ability to register properties against
the class.
This provides an ObjectPropertyIterator struct which will
insulate the callers from the particular data structure
used to store properties. It can be used thus
ObjectProperty *prop;
ObjectPropertyIterator *iter;
iter = object_property_iter_init(obj);
while ((prop = object_property_iter_next(iter))) {
... do something with prop ...
}
object_property_iter_free(iter);
Backports commit a00c94824126901168bca5b89147f9e334a49e87 from qemu
Reduce the boilerplate required for each target. At the same time,
move the test for breakpoint after calling tcg_gen_insn_start.
Note that arm and aarch64 do not use cpu_breakpoint_test, but still
move the inline test down after tcg_gen_insn_start.
Backports commit b933066ae03d924a92b2616b4a24e7d91cd5b841 from qemu
CPUState::crash_occurred field inside CPUState marks
that guest crash occurred. This value is added into
cpu common migration subsection.
Backports commit bac05aa9a77af1ca7972c8dc07560f4daa7c2dfc from qemu
After the previous patch, TLBs will be flushed on every change to
the memory mapping. This patch augments that with synchronization
of the MemoryRegionSections referred to in the iotlb array.
With this change, it is guaranteed that iotlb_to_region will access
the correct memory map, even once the TLB will be accessed outside
the BQL.
Backports commit 9d82b5a792236db31a75b9db5c93af69ac07c7c5 from qemu
This commit fixes the following issues:
- Any unmapped/free'd memory regions (MemoryRegion instances) are not
removed from the object property linked list of its owner (which is
always qdev_get_machine(uc)). This issue makes adding new memory
mapping by calling mem_map() or mem_map_ptr() slower as more and more
memory pages are mapped and unmapped - yes, even if those memory pages
are unmapped, they still impact the speed of future memory page
mappings due to this issue.
- FlatView is not reconstructed after a memory region is freed during
unmapping, which leads to a use-after-free the next time a new memory
region is mapped in address_space_update_topology().
