qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Erico Nunes <ernunes@redhat.com>
To: "Marc-André Lureau" <marcandre.lureau@gmail.com>
Cc: qemu-devel@nongnu.org, mst@redhat.com, kraxel@redhat.com
Subject: Re: [PATCH 0/2] vhost-user-gpu get_edid feature
Date: Wed, 31 May 2023 18:14:13 +0200	[thread overview]
Message-ID: <770c292c-9b74-fc68-19b4-09c806de1c4c@redhat.com> (raw)
In-Reply-To: <CAJ+F1C+eGxZtdu033HP-UdowLKrz94LdKwkRB=hfDm3amv1C-g@mail.gmail.com>

On 24/05/2023 13:23, Marc-André Lureau wrote:
> Hi Erico
> 
> On Wed, May 17, 2023 at 8:09 PM Erico Nunes <ernunes@redhat.com
> <mailto:ernunes@redhat.com>> wrote:
> 
>     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?
> 
> 
> Wouldn't this work?
> 
> If VIRTIO_GPU_F_EDID is set and during protocol_features the GET_EDID
> feature is not negotiated, exit the gpu backend with an error.

I sent v2 implementing it this way.
It seems that qemu always requests the virtio feature though (even if
you do pass edid=off to the device, it just doesn't expose it to the
user but does request the feature bit). So given we can't change past
qemu builds I'm not sure if there is a way to make an older qemu with an
updated vhost-user-gpu work at all. The new implementation does print an
error message in that case though.

Thanks

Erico



      reply	other threads:[~2023-05-31 16:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-11 12:58 [PATCH 0/2] vhost-user-gpu get_edid feature Erico Nunes
2023-05-11 12:58 ` [PATCH 1/2] virtio-gpu: refactor generate_edid function to virtio_gpu_base Erico Nunes
2023-05-11 12:58 ` [PATCH 2/2] vhost-user-gpu: implement get_edid feature Erico Nunes
2023-05-15 11:38 ` [PATCH 0/2] vhost-user-gpu " Marc-André Lureau
2023-05-17 16:08   ` Erico Nunes
2023-05-24 11:23     ` Marc-André Lureau
2023-05-31 16:14       ` Erico Nunes [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=770c292c-9b74-fc68-19b4-09c806de1c4c@redhat.com \
    --to=ernunes@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=marcandre.lureau@gmail.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).