Re: [Qemu-devel] [Qemu-ppc] qemu-system-ppc video artifacts since "tcg: drop global lock during TCG code execution"

[Alex Bennée]

Mark Cave-Ayland <address@hidden> writes:

> On 14/03/17 15:41, Alex Bennée wrote:
>
>> BALATON Zoltan <address@hidden> writes:
>>
>>> On Tue, 14 Mar 2017, Mark Cave-Ayland wrote:
>>>> On 14/03/17 10:00, Alex Bennée wrote:
>>>>> Mark Cave-Ayland <address@hidden> writes:
>>>>>
>>>>>> I've recently noticed some video artifacts appearing in the form of
>>>>>> horizontal lines whilst testing OpenBIOS boot on some qemu-system-ppc
>>>>>> images (see https://www.ilande.co.uk/tmp/qemu/macos9-stripe.png for an
>>>>>> example) which I've finally bisected down to this commit.
<snip>
>
> Could it be that these underlying assumptions have now changed?

So there is an assumption that has changed. It used to be the TCG code
and the gui_update code could not run at the same time as they both
needed to take the BQL.

When drop global lock patch went in this was reversed. The BQL is no
longer held while running the TCG until it needs it.

It certainly needs it when it is doing HW emulation and for MMIO mapped
registers this is what happens. Every time we write to a MMIO register
the SoftMMU helper routines follow the slow path, through the memory API
(which takes a lock) and into the hw emulation code. However for
framebuffers our behaviour is slightly different.

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

I've sort of confirmed that by hacking full_update = 1 in
vga_update_display and the artefacts go away.

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.

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. We simply queue up update function to run as
async safe work which will guarantee the TCG vCPUs will not be running
while stuff is updated. I'm a little hesitant to do that globally as it
may well slow down KVM by introducing an unneeded pause.

This also involves making a tweak into the ui/console.c code
(gui_update) so I'm CC'ing Gerd who might have an insight on how to do
this neatly.

--
Alex Bennée