qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH 0/2] vhost-user-gpu get_edid feature


From: Erico Nunes
Subject: Re: [PATCH 0/2] vhost-user-gpu get_edid feature
Date: Wed, 17 May 2023 18:08:59 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0

On 15/05/2023 13:38, Marc-André Lureau wrote:
> However, I worry about using the new backend (calling GET_EDID) with an
> older front-end/QEMU. It may just hang, since
> vhost_user_gpu_handle_display() won't reply to unknown messages. That's
> what PROTOCOL_FEATURES were meant for, iirc. Can you check? thanks

Indeed as you say, there is a hang with older qemu.

>From what I see there are the generic protocol_features and also a
vhost-user-gpu message for them. I assume it is so that we don't have to
add vhost-user-gpu specific features to the generic set?
In any case, the current vhost-user-gpu specific protocol_features
negotiation happens too late to enable or disable virtio-gpu features
(triggered by VHOST_USER_GPU_SET_SOCKET). I suppose we could move it
earlier to the time the generic protocol_features are negotiated,
through the callback hooks that already exist in the vhost-user layer
(not implemented so far by vhost-user-gpu though).
So I guess we could remove the protocol_features negotiation that is
currently triggered by VHOST_USER_GPU_SET_SOCKET and use that to prevent
exposing VIRTIO_GPU_F_EDID at all. Does that make sense?

Otherwise, if we keep exposing VIRTIO_GPU_F_EDID and just not sending
VHOST_USER_GPU_GET_EDID then the get_edid feature is not quite
functional overall, which doesn't sound too great.

Thanks

Erico




reply via email to

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