|
From: | Alex Bennée |
Subject: | Re: [Qemu-ppc] qemu-system-ppc video artifacts since "tcg: drop global lock during TCG code execution" |
Date: | Wed, 15 Mar 2017 11:14:52 +0000 |
User-agent: | mu4e 0.9.19; emacs 25.2.9 |
BALATON Zoltan <address@hidden> 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
[Prev in Thread] | Current Thread | [Next in Thread] |