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
