[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] qemu-system-ppc video artifacts since "tcg: drop global l

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.
>>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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]