qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Qemu-ppc] qemu-system-ppc video artifacts since "tcg:


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [Qemu-ppc] qemu-system-ppc video artifacts since "tcg: drop global lock during TCG code execution"
Date: Thu, 16 Mar 2017 15:22:05 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0


On 16/03/2017 08:35, Gerd Hoffmann wrote:
>   Hi,
> 
>>>> Note that KVM has some similar hacks to avoid trapping all writes to
>>>> video memory with its coalesced mmio mechanism however I'm not familiar
>>>> with all the details.
>>>
>>> Normal linear framebuffer access doesn't use this.
>>
>> Ahh OK - as I said I wasn't super familiar with what coalesced mmio was
>> trying to achieve. I assume it is trying to avoid trapping on every
>> single MMIO access?
> 
> You can't avoid the trap, but you can avoid notifying userspace about
> each and every single trap and batch things.
> 
> But vga framebuffer is normal ram in most video modes, it doesn't trap
> (except on first access with dirty bit clear, for dirty bit tracking).  
> 
> IIRC some of the historic video modes which are pretty much unused these
> days (planar 4bit) trap on each access and perform better with coalesced
> mmio.  Also nics which use mmio instead of dma for package xfer.
> 
>>> I suspect the memory_region_sync_dirty_bitmap call on tcg should reset
>>> the fast path optimization, so the slow path can update the dirty bits
>>> correctly.
>>
>> Sure. And for the low level cputlb implementation we can clear those
>> bits atomically. However when the memory region is synced we also need
>> to flush any entries in the TLB that have already been hit and cleared
>> TLB_NOTDIRTY to we can trigger the slow path again. This is tricky from
>> outside of a vCPU context because we can't just queue the work and exit
>> the vCPU run loop to reach a known CPU state.
> 
> Hmm, ok.
> 
>> The RFC PATCH I sent earlier solves this by ensuring the update runs in
>> a quiescent period (i.e. when the vCPUs are not running) but it is
>> sub-optimal as it means the display code has to have a basic knowledge
>> of vCPUs and when they run.
> 
> Still the best option for 2.9 I guess ...

For both VGA and SM501, it should be the issue I pointed out in
https://lists.gnu.org/archive/html/qemu-devel/2017-03/msg03197.html.
The dirty bitmap has been thread-safe for a long time now.

Paolo



reply via email to

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