On 5 June 2015 at 16:15, Paolo Bonzini <pbonz...@redhat.com> wrote:
> framebuffer.c expects DIRTY_MEMORY_VGA logging to be always on, but that
> will not be the case soon. Because framebuffer.c computes the memory
> region on the fly for every update (with memory_region_find), it cannot
> enable/disable logging by itself.
>
> Instead, always treat updates as invalidations if dirty logging is
> not enabled, assuming that the board will enable logging on the
> RAM region that includes the framebuffer.
>
> Reviewed-by: Fam Zheng <f...@redhat.com>
> Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
> ---
> hw/display/framebuffer.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/hw/display/framebuffer.c b/hw/display/framebuffer.c
> index 4546e42..2cabced 100644
> --- a/hw/display/framebuffer.c
> +++ b/hw/display/framebuffer.c
> @@ -63,6 +63,10 @@ void framebuffer_update_display(
> assert(mem_section.offset_within_address_space == base);
>
> memory_region_sync_dirty_bitmap(mem);
> + if (!memory_region_is_logging(mem, DIRTY_MEMORY_VGA)) {
> + invalidate = true;
> + }
> +
> src_base = cpu_physical_memory_map(base, &src_len, 0);
> /* If we can't map the framebuffer then bail. We could try harder,
> but it's not really worth it as dirty flag tracking will probably
I've just noticed that one of my vexpress-a9 test images has
regressed, and git bisect suggests this commit (d55d42078bfb50)
is at fault.
Test image (512MB)
http://people.linaro.org/~peter.maydell/vexpress-3.8.tgz
Untar anywhere, and run with
~/path/to/vexpress-3.8/runme path/to/qemu-system-arm
Before this commit it boots, but afterwards it hangs just
after:
[ 7.338111] clcd-pl11x 10020000.clcd: Device Tree CLCD PL111
hardware, XVGA display
[ 7.437573] Console: switching to colour frame buffer device 128x48
[ 7.510028] VD10: at 1000 mV
[ 7.533710] VD10_S2: at 1000 mV
[ 7.552106] VD10_S3: at 1000 mV
[ 7.579775] VCC1V8: at 1800 mV
[ 7.606060] DDR2VTT: at 900 mV
[ 7.619865] VCC3V3: at 3300 mV
[ 7.649775] VIO: at 3300 mV
...eventually the guest's rcu_sched stall detector fires,
so the guest isn't totally dead:
[ 51.405779] INFO: rcu_sched detected stalls on CPUs/tasks: {}
(detected by 0, t=4266 jiffies, g=4294967169, c=4294967168, q=47)
[ 51.407674] INFO: Stall ended before state dump start
[ 75.834733] INFO: rcu_sched self-detected stall on CPU { 0}
(t=2437 jiffies g=4294967174 c=4294967173 q=27)
thanks
-- PMM
