qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] virtio-gpu: fix crashes upon warm reboot with v


From: Marc-André Lureau
Subject: Re: [Qemu-devel] [PATCH] virtio-gpu: fix crashes upon warm reboot with vga mode
Date: Mon, 6 Aug 2018 15:47:45 +0200

On Mon, Aug 6, 2018 at 3:39 PM, Peter Maydell <address@hidden> wrote:
> On 3 August 2018 at 16:32, Marc-André Lureau
> <address@hidden> wrote:
>> With vga=775 on the Linux command line a first boot of the VM running
>> Linux works fine. After a warm reboot it crashes during Linux boot.
>>
>> Before that, valgrind points out bad memory write to console
>> surface. The VGA code is not aware that virtio-gpu got a message
>> surface scanout when the display is disabled. Let's reset VGA graphic
>> mode when it is the case, so that a new display surface is created
>> when doing further VGA operations.
>>
>> https://bugs.launchpad.net/qemu/+bug/1784900/
>>
>> Reported-by: Stefan Berger <address@hidden>
>> Signed-off-by: Marc-André Lureau <address@hidden>
>> ---
>>  include/hw/virtio/virtio-gpu.h |  1 +
>>  hw/display/virtio-gpu.c        |  5 +++++
>>  hw/display/virtio-vga.c        | 11 +++++++++++
>>  3 files changed, 17 insertions(+)
>>
>> diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
>> index 9780f755ef..d0321672f4 100644
>> --- a/include/hw/virtio/virtio-gpu.h
>> +++ b/include/hw/virtio/virtio-gpu.h
>> @@ -125,6 +125,7 @@ typedef struct VirtIOGPU {
>>          uint32_t bytes_3d;
>>      } stats;
>>
>> +    void (*disable_scanout)(struct VirtIOGPU *g, int scanout_id);
>>      Error *migration_blocker;
>>  } VirtIOGPU;
>
> I guess for a last-minute 3.0 fix this is ok, but it looks
> a bit weird to have a function pointer in a device instance
> struct, which the user of the device has reached in and
> set in order to modify the behaviour of the object...

It's not much different than pointing to a static const structure with
function pointers (I thought that was unnecessary for just one
function)

We could also have a VirtioGPUClass with virtual methods, and subclass
TYPE_VIRTIO_GPU. Also a bit over-complicated, and conflicting with my
vhost-user-gpu series. So we may eventually get there in 3.1 though.

>
> thanks
> -- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]