From: "Alex Bennée" <alex.bennee@linaro.org>
To: Gerd Hoffmann <kraxel@redhat.com>
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: Thu, 16 Mar 2017 07:56:56 +0000 [thread overview]
Message-ID: <877f3ppsc7.fsf@linaro.org> (raw)
In-Reply-To: <1489649706.15659.72.camel@redhat.com>
Gerd Hoffmann <kraxel@redhat.com> writes:
> 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 ...
I think so although Paolo has pointed out potential issues with the
other display adaptors.
As this dirty tracking is also used for live migration I also need to
check if the BQL change has broken that for TCG guests or that it just
never worked anyway. If it is the later then that gives a bit more
breathing room for plumbing in the full fix to keep the memory_regions
view of the world consistent with the SoftMMU TLB.
>
> cheers,
> Gerd
--
Alex Bennée
next prev parent reply other threads:[~2017-03-16 7:56 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
2017-03-15 16:20 ` Alex Bennée
2017-03-16 7:35 ` Gerd Hoffmann
2017-03-16 7:56 ` Alex Bennée [this message]
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=877f3ppsc7.fsf@linaro.org \
--to=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=kraxel@redhat.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.