On 14/03/17 15:41, Alex Bennée wrote: > BALATON Zoltan <bala...@eik.bme.hu> writes: > >> On Tue, 14 Mar 2017, Mark Cave-Ayland wrote: >>> On 14/03/17 10:00, Alex Bennée wrote: >>>> Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk> 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?
Not in a quick local test here. However this does ring a bell - one of Ben's PPC optimisations was to batch TLB flushes so they only occur at certain times - see commit cd0c6f473532bfaf20a095bc90a18e45162981b5 for more detail. Could it be that these underlying assumptions have now changed? ATB, Mark.
