[Top][All Lists]

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

Re: [Qemu-ppc] qemu-system-ppc video artifacts since "tcg: drop global l

From: Alex Bennée
Subject: Re: [Qemu-ppc] qemu-system-ppc video artifacts since "tcg: drop global lock during TCG code execution"
Date: Tue, 14 Mar 2017 15:41:20 +0000
User-agent: mu4e 0.9.19; emacs 25.2.9

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.
>>> Interesting. Is the video hardware in this case a simple framebuffer or
>>> is there some sort of GPU involved?
>> For the mac99 machine it's just the normal QEMU PCI std-vga card, so
>> nothing special. Having run tests across SPARC which uses its own
>> framebuffer, there have been no obvious artifacts that I've spotted
>> there to date.
>>>> The horizontal lines tend to appear at different positions with
>>>> different lengths, although it seems to be more common that a complete
>>>> scanline is affected. Reproducing the issue is fairly easy with a MacOS
>>>> 9.2.1 ISO and the command line below:
>>>> ./qemu-system-ppc -cdrom MacOS921.iso -boot d -m 512 -M mac99
>>>> Could it be that this patch is still missing a lock somewhere which
>>>> causes these artifacts to appear?
>>> It depends. If the hardware is accessed via MMIO then the BQL is taken
>>> automatically (unless the area is explicitly marked as doing its own
>>> locking see: mr->global_locking).
>>> Is the artefact temporary or permanent? Could it be a change in
>>> synchronisation between the emulator updating the framebuffer and
>>> whatever backend updating its display?
>> AFAICT they are temporary in that they appear randomly on the display,
>> but the next time that particular area of the display is updated by the
>> guest then they tend to either change/disappear.
> I've also noticed artifacts when testing the SM501 changes with
> MorphOS on recent QEMU so it may not be related to just the std vga.
> It's shown as bands (larger number of adjacent scanlines) not updating
> when the client first wrote to the framebuffer but then they
> disappeared during the next refresh. I'm guessing it may be related to
> dirty checking of the framebuffer memory which is used to decide when
> a scan line needs update?

Interesting. I guess if the corrupted scan lines are in blocks of
PAGE_SIZE that might make sense.

Commit (b0706b716769494f321a0d2bfd9fa9893992f995) made
tlb_reset_dirty_range update the SoftMMU addr_write entry atomically.
Now I don't see how that could race in single threaded TCG mode but it
could explain things.

I notice that tlb_set_dirty/tlb_set_dirty1 should maybe do the same. The
currently assume they are only called from the CPU's context. If you
enable #define DEBUG_TLB in cputlb.c does the assert fire?

> Regards,
> BALATON Zoltan

Alex Bennée

reply via email to

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