From: Gerd Hoffmann <kraxel@redhat.com>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
BALATON Zoltan <balaton@eik.bme.hu>,
jan.kiszka@siemens.com, qemu-devel <qemu-devel@nongnu.org>,
cota@braap.org, "qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>,
bobby.prani@gmail.com, fred.konrad@greensocs.com,
rth@twiddle.net
Subject: Re: [Qemu-devel] [Qemu-ppc] qemu-system-ppc video artifacts since "tcg: drop global lock during TCG code execution"
Date: Wed, 15 Mar 2017 16:25:39 +0100 [thread overview]
Message-ID: <1489591539.15659.60.camel@redhat.com> (raw)
In-Reply-To: <87efxypqug.fsf@linaro.org>
Hi,
> Instead of having MMIO register spaces we use the dirty tracking
> mechanism. Here regions are marked as for dirty tracking and when the
> SoftMMU helper first comes to this bit of memory it will follow the slow
> path and mark region as visited.
visited? Do you mean dirty bit is set for the page? Or is this
something else?
> Once done this bit is cleared and all
> future writes to that page are written directly from the translated
> code. This no longer has an implicit synchronisation from the BQL so
> there is now a race and you can have memory being updated which might
> miss this flagging.
Not fully following what you are trying to say. But pages being updated
without dirty bit getting set (if clear) certainly is a problem for the
vga emulation (and live migration too).
> 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.
> Now there are mechanisms we can use to ensure there are no races happen
> and return to the situation that the display is only updated when the
> TCG cores are not running.
tcg and display updates running in parallel isn't a problem, we have
that with kvm anyway. Dirty bit handling must be correct though.
With kvm at the start of each display update vga fetches the dirty
bitmap from the kernel (memory_region_sync_dirty_bitmap). Then it goes
use memory_region_get_dirty to figure which pages have been touched.
When memory_region_sync_dirty_bitmap is called the kernel will clear the
memory bitmap of the region and also map all pages read-only. Next
guest update will pagefault and the kernel can set the dirty bit for the
page (maybe there is a more efficient way with EPT available).
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.
cheers,
Gerd
next prev parent reply other threads:[~2017-03-15 15:33 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <36e41adf-b0b3-3efa-51c4-f1a70cd05b98@ilande.co.uk>
2017-03-13 21:28 ` [Qemu-devel] qemu-system-ppc video artifacts since "tcg: drop global lock during TCG code execution" Mark Cave-Ayland
[not found] ` <87wpbsp49a.fsf@linaro.org>
2017-03-14 11:12 ` Mark Cave-Ayland
2017-03-14 13:56 ` [Qemu-devel] [Qemu-ppc] " BALATON Zoltan
2017-03-14 15:02 ` luigi burdo
2017-03-14 15:41 ` Alex Bennée
2017-03-14 15:52 ` Mark Cave-Ayland
2017-03-14 16:48 ` Alex Bennée
2017-03-14 17:34 ` BALATON Zoltan
2017-03-14 17:53 ` luigi burdo
2017-03-15 11:14 ` Alex Bennée
2017-03-15 13:26 ` Mark Cave-Ayland
2017-03-15 14:19 ` Alex Bennée
2017-03-16 6:39 ` Paolo Bonzini
2017-03-16 7:51 ` Alex Bennée
2017-03-16 8:34 ` Paolo Bonzini
2017-03-16 15:34 ` Gerd Hoffmann
2017-03-16 17:00 ` Paolo Bonzini
2017-03-28 13:40 ` Gerd Hoffmann
2017-03-28 14:13 ` Paolo Bonzini
2017-03-15 14:16 ` Alex Bennée
2017-03-15 15:25 ` Gerd Hoffmann [this message]
2017-03-15 16:20 ` Alex Bennée
2017-03-16 7:35 ` Gerd Hoffmann
2017-03-16 7:56 ` Alex Bennée
2017-03-16 14:22 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1489591539.15659.60.camel@redhat.com \
--to=kraxel@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=balaton@eik.bme.hu \
--cc=bobby.prani@gmail.com \
--cc=cota@braap.org \
--cc=fred.konrad@greensocs.com \
--cc=jan.kiszka@siemens.com \
--cc=mark.cave-ayland@ilande.co.uk \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=rth@twiddle.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.