On Tue, 05/26 18:54, Paolo Bonzini 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.
>
> Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
Reviewed-by: Fam Zheng <f...@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
> --
> 1.8.3.1
>
>
>
