BALATON Zoltan <bala...@eik.bme.hu> writes: > On Tue, 14 Mar 2017, Alex Bennée wrote: >> So from a single-threaded -smp guest case there should be no difference >> in behaviour. <snip> >>However this shouldn't affect >> anything in the single-threaded world. > > I think we have a single CPU and thread for these ppc machines here so > I'm not sure how this could be relevant. > >> However delaying tlb_flushes() could certainly expose/hide stuff that is >> accessing the dirty mechanism. tlb_flush itself now takes the tb_lock() to >> avoid racing with the TB invalidation logic. The act of the flush will >> certainly wipe all existing SoftMMU entries and force a re-load on each >> memory access. >> >> So is the dirty status of memory being read from outside a vCPU >> execution context? > > Like from the display controller models that use > memory_region_get_dirty() to check if the frambuffer needs to be > updated? But all display adaptors seem to do this and the problem was > only seem on ppc so it may be related to something ppc specific.
So this accesses the memory_region API which is under RCU control. AFAIUI this should mean the dirty status may be read late (e.g. next update) but should never be incorrect (e.g. miss a dirtying operation). -- Alex Bennée
