Re: [PATCH] hw/display/virtio-gpu: Remove the bytes_pp field
Akihiko Odaki <[email protected]>
| Newsgroups | gmane.comp.emulators.qemu,gmane.comp.emulators.qemu.stable |
|---|---|
| Message-ID | <[email protected]> |
On 2026/07/28 6:17, Michael Tokarev wrote:
> On 7/19/26 14:35, Akihiko Odaki wrote:
>> virtio_gpu_do_set_scanout() validates the stride field of struct
>> virtio_gpu_framebuffer against the bytes_pp field, but bytes_pp in the
>> migration stream may be inconsistent with the format field, which
>> pixman_image_create_bits() uses when it accesses the framebuffer.
>> That validation is therefore incomplete.
>>
>> To avoid the trouble of synchronizing the two fields, remove bytes_pp,
>> and always derive its value from format. Removing bytes_pp is safe
>> because no released version of QEMU uses its migrated value.
>>
>> Fixes: 7b5574225429 ("hw/display: check frame buffer can hold blob")
>> Cc: [email protected]
>> Signed-off-by: Akihiko Odaki <[email protected]>
>> ---
>> Based-on: <[email protected]>
>> ("[PATCH] hw/display/virtio-gpu: validate stride against width on
>> scanout")
>> ---
>> include/hw/virtio/virtio-gpu.h | 1 -
>> hw/display/virtio-gpu.c | 27 +++++++++++++++++----------
>> 2 files changed, 17 insertions(+), 11 deletions(-)
> ...
>> @@ -1219,8 +1227,7 @@ static const VMStateDescription
>> vmstate_virtio_gpu_scanout = {
>> VMSTATE_UINT32(cursor.pos.y, struct virtio_gpu_scanout),
>> VMSTATE_UINT32_TEST(fb.format, struct virtio_gpu_scanout,
>> scanout_vmstate_after_v2),
>> - VMSTATE_UINT32_TEST(fb.bytes_pp, struct virtio_gpu_scanout,
>> - scanout_vmstate_after_v2),
>> + VMSTATE_UNUSED_TEST(scanout_vmstate_after_v2, 4),
>
> Can we send this field when doing migration to an older version?
> When doing migration from older to current (with this patch), this
> field is being ignored, which is ok. But not setting this field
> on migration in reverse direction means the older version wont work.
Removing bytes_pp is safe because no released version of QEMU uses its
migrated value, as the commit message notes.
Regards,
Akihiko Odaki