Re: [Qemu-devel] [PULL 12/62] framebuffer: check memory_region_is_logging

[Peter Maydell]

On 5 June 2015 at 16:15, Paolo Bonzini <address@hidden> 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 <address@hidden>
> Signed-off-by: Paolo Bonzini <address@hidden>
> ---
>  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