[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RfC PATCH 0/4] make display updates thread safe.
From: |
Mark Cave-Ayland |
Subject: |
Re: [Qemu-devel] [RfC PATCH 0/4] make display updates thread safe. |
Date: |
Mon, 3 Apr 2017 06:26:30 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 |
On 30/03/17 14:41, Gerd Hoffmann wrote:
> Hi,
>
>> Excellent! I can help out with converting and/or testing the SPARC
>> devices (cg3/tcx) if required.
>
> Sure, test results and patches are very welcome.
I've spent a bit of time over the weekend attempting to convert the
SPARC CG3/TCX framebuffers over to use your new code and pushed the
result to my github branch here:
https://github.com/mcayland/qemu/commits/vga-fixes-sparc.
Feel free to steal/test/borrow as required. The two main things I've
discovered to date are:
1) Problems with asserts() in cpu_physical_memory_snapshot_get_dirty()
Using your current git branch, I get an assert() using VGA under
qemu-system-ppc on startup unless I change the first assert to
"assert(start >= snap->start)".
I'm also not convinced by the second assert "assert(start + length <
snap->end)" either. In the example CG3/TCX conversions I ended up having
to subtract 1 from the size of the region passed to
memory_region_snapshot_get_dirty() in order to avoid it firing when
accessing the last scanline which seems wrong. I didn't explicitly add a
patch to change this to "<=" in my git patchset just in case it broke
further assumptions in the bitmap code relating to the end address.
2) Redraw issues with CG3/TCX after conversion
Despite the conversion from your patches looking reasonably
straightforward, I still see problems with areas of the screen not
updating after conversion. I can easily reproduce these locally as follows:
./qemu-system-sparc -vga cg3 -prom-env 'auto-boot?=false'
./qemu-system-sparc -vga tcx -g 1024x768x8 -prom-env 'auto-boot?=false'
./qemu-system-sparc -vga tcx -g 1024x768x24 -prom-env 'auto-boot?=false'
You can trigger extra screen updates by typing "show-devs" into OpenBIOS
which will cause a lot of screen activity as it writes the device tree
out to the framebuffer. I'm wondering if maybe this is related to the
difference in sizes between DIRTY_MEMORY_BLOCK_SIZE and TARGET_PAGE_BITS
for qemu-system-sparc?
Finally on a slightly unrelated note, the TCX driver still has old code
for 8 and 16 bpp surfaces in QEMU. Am I right in understanding that all
surfaces in QEMU are now 32-bit and the 8/16 bpp code can be removed?
ATB,
Mark.
- Re: [Qemu-devel] [RfC PATCH 0/4] make display updates thread safe.,
Mark Cave-Ayland <=
- Re: [Qemu-devel] [RfC PATCH 0/4] make display updates thread safe., Paolo Bonzini, 2017/04/03
- Re: [Qemu-devel] [RfC PATCH 0/4] make display updates thread safe., Gerd Hoffmann, 2017/04/03
- Re: [Qemu-devel] [RfC PATCH 0/4] make display updates thread safe., Mark Cave-Ayland, 2017/04/03
- Re: [Qemu-devel] [RfC PATCH 0/4] make display updates thread safe., Gerd Hoffmann, 2017/04/03
- Re: [Qemu-devel] [RfC PATCH 0/4] make display updates thread safe., Mark Cave-Ayland, 2017/04/03
- Re: [Qemu-devel] [RfC PATCH 0/4] make display updates thread safe., Gerd Hoffmann, 2017/04/04
- Re: [Qemu-devel] [RfC PATCH 0/4] make display updates thread safe., Mark Cave-Ayland, 2017/04/04
- Re: [Qemu-devel] [RfC PATCH 0/4] make display updates thread safe., Paolo Bonzini, 2017/04/03