On 13/02/2015 04:29, Matthew Rosato wrote:
FYI, then this probably also affects the places you hit in d8d9581460
memory: convert memory_region_destroy to object_unparent, as that's
what I modeled this approach on -- but I haven't tested any of them.
Luckily not, because only real regions
On 02/12/2015 12:34 PM, Paolo Bonzini wrote:
On 12/02/2015 17:21, Matthew Rosato wrote:
Since 374f2981d1 memory: protect current_map by RCU,
address_space_update_topology unrefs the old_flatview twice,
once by call_rcu and once by direct call. This patch removes
the direct call in favor
On 12/02/2015 20:32, Matthew Rosato wrote:
Could it be that the order in which flatview_unref (and therefore
memory_region_unref) vs object_unparent(mr) matters (ie, object_unparent
should always happen last)? Prior to RCUification, seems like the
old_view was always unreferenced prior to
On 02/12/2015 03:43 PM, Paolo Bonzini wrote:
On 12/02/2015 20:32, Matthew Rosato wrote:
Could it be that the order in which flatview_unref (and therefore
memory_region_unref) vs object_unparent(mr) matters (ie, object_unparent
should always happen last)? Prior to RCUification, seems like
Since 374f2981d1 memory: protect current_map by RCU,
address_space_update_topology unrefs the old_flatview twice,
once by call_rcu and once by direct call. This patch removes
the direct call in favor of the call_rcu. Fixes at least one
assertion failure seen in s390, where a ref count for a
On 12/02/2015 17:21, Matthew Rosato wrote:
Since 374f2981d1 memory: protect current_map by RCU,
address_space_update_topology unrefs the old_flatview twice,
once by call_rcu and once by direct call. This patch removes
the direct call in favor of the call_rcu. Fixes at least one
assertion
On 12/02/2015 17:21, Matthew Rosato wrote:
Since 374f2981d1 memory: protect current_map by RCU,
address_space_update_topology unrefs the old_flatview twice,
once by call_rcu and once by direct call. This patch removes
the direct call in favor of the call_rcu. Fixes at least one
assertion
