From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47403) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cnoZU-0003vv-Gb for qemu-devel@nongnu.org; Tue, 14 Mar 2017 11:41:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cnoZO-0003i5-B3 for qemu-devel@nongnu.org; Tue, 14 Mar 2017 11:41:12 -0400 Received: from mail-wm0-x22f.google.com ([2a00:1450:400c:c09::22f]:35506) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cnoZN-0003h7-U6 for qemu-devel@nongnu.org; Tue, 14 Mar 2017 11:41:06 -0400 Received: by mail-wm0-x22f.google.com with SMTP id v186so67170397wmd.0 for ; Tue, 14 Mar 2017 08:41:05 -0700 (PDT) References: <36e41adf-b0b3-3efa-51c4-f1a70cd05b98@ilande.co.uk> <87wpbsp49a.fsf@linaro.org> <6491a446-bf23-5ab9-3431-c67efaf83f71@ilande.co.uk> From: Alex =?utf-8?Q?Benn=C3=A9e?= In-reply-to: Date: Tue, 14 Mar 2017 15:41:20 +0000 Message-ID: <87shmfq31b.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [Qemu-ppc] qemu-system-ppc video artifacts since "tcg: drop global lock during TCG code execution" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: BALATON Zoltan Cc: Mark Cave-Ayland , jan.kiszka@siemens.com, qemu-devel , cota@braap.org, "qemu-ppc@nongnu.org" , bobby.prani@gmail.com, fred.konrad@greensocs.com, rth@twiddle.net BALATON Zoltan writes: > On Tue, 14 Mar 2017, Mark Cave-Ayland wrote: >> On 14/03/17 10:00, Alex Bennée wrote: >>> Mark Cave-Ayland 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