On Tue, Sep 17, 2013 at 07:16:15PM +0200, Paolo Bonzini wrote: > Il 17/09/2013 19:07, Michael S. Tsirkin ha scritto: > > After memory_region_del_subregion returns, > > it's a promise that there will not be accesses > > to the region. > > It's racy anyway. You can have memory_region_del_subregion happen one > clock cycle after the other (physical) CPU has done checked that there > will not be accesses to the region.
Fix it then. Stick synchronize_rcu() in memory_region_del_subregion. Are you trying to convince me there's no way to have synchronous APIs in presence of RCU? > A real bus has a "big PCI lock" (there can be only one transaction at a > time), which is exactly what we want to get rid of. Not really, in a bridged setup transactions on the secondary bus are handled in parallel with transactions on the primary bus. Also, there are split transactions completed asynchronously: guests that care about ordering do flushes e.g. using memory reads. The logic is in the device/memory region really. > > So I'm not even sure we really need to move destroy to finalize anymore ... > > We definitely need to move it. Even if we added a flag that we set in > memory_region_del_subregion, we need to check it later when AIO completes. > > Paolo Flag where? region can become subregion of another region entirely. The solution for RCU is to flush on changes, not add more flags and locks. -- MST
