qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Michael S. Tsirkin <mst@redhat.com>, qemu-devel <qemu-devel@nongnu.org>
Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Raphael Norwitz" <raphael.norwitz@nutanix.com>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"Mathieu Poirier" <mathieu.poirier@linaro.org>,
	"Viresh Kumar" <viresh.kumar@linaro.org>
Subject: What is the correct way to handle the VirtIO config space in vhost-user?
Subject: What is the correct way to handle the VirtIO config space in vhost-user?
Date: Fri, 25 Feb 2022 17:32:43 +0000	[thread overview]
Message-ID: <87a6ee3l5e.fsf@linaro.org> (raw)
In-Reply-To: 87ee3q3mos.fsf@linaro.org


[Apologies to CC list for repost due to fat fingering the mailing list address]

Hi Michael,

I was updating my vhost-user-rpmb implementation when I realised it
wasn't handling config space access properly. However when I went to
implement it I realised there seems to be two ways of doing this. For
example in vhost-user-gpu we have:

  static void
  vhost_user_gpu_get_config(VirtIODevice *vdev, uint8_t *config_data)
  {
      VhostUserGPU *g = VHOST_USER_GPU(vdev);
      VirtIOGPUBase *b = VIRTIO_GPU_BASE(vdev);
      struct virtio_gpu_config *vgconfig =
          (struct virtio_gpu_config *)config_data;
      Error *local_err = NULL;
      int ret;

      memset(config_data, 0, sizeof(struct virtio_gpu_config));

      ret = vhost_dev_get_config(&g->vhost->dev,
                                 config_data, sizeof(struct virtio_gpu_config),
                                 &local_err);
      if (ret) {
          error_report_err(local_err);
          return;
      }

      /* those fields are managed by qemu */
      vgconfig->num_scanouts = b->virtio_config.num_scanouts;
      vgconfig->events_read = b->virtio_config.events_read;
      vgconfig->events_clear = b->virtio_config.events_clear;
  }

which is setup with .get_config and .set_config functions that poke the
appropriate vhost communication. However to do this needs an instance
init to create a vhost just so it can jump the g->vhost->dev indirection:

  static void
  vhost_user_gpu_instance_init(Object *obj)
  {
      VhostUserGPU *g = VHOST_USER_GPU(obj);

      g->vhost = VHOST_USER_BACKEND(object_new(TYPE_VHOST_USER_BACKEND));
      object_property_add_alias(obj, "chardev",
                                OBJECT(g->vhost), "chardev");
  }

(aside: this continues my QOM confusion about when things should be in a
class or instance init, up until this point I hadn't needed it in my
stub).

However when grepping around I found some vhost-user devices do it
differently, for example vhost-user-blk has:

  static int vhost_user_blk_handle_config_change(struct vhost_dev *dev)
  {
      int ret;
      struct virtio_blk_config blkcfg;
      VHostUserBlk *s = VHOST_USER_BLK(dev->vdev);
      Error *local_err = NULL;

      ret = vhost_dev_get_config(dev, (uint8_t *)&blkcfg,
                                 sizeof(struct virtio_blk_config),
                                 &local_err);
      if (ret < 0) {
          error_report_err(local_err);
          return ret;
      }

      /* valid for resize only */
      if (blkcfg.capacity != s->blkcfg.capacity) {
          s->blkcfg.capacity = blkcfg.capacity;
          memcpy(dev->vdev->config, &s->blkcfg, sizeof(struct virtio_blk_config));
          virtio_notify_config(dev->vdev);
      }

      return 0;
  }

Although this seems to miss the ability to "set" a config - although
that seems confusing anyway, surely the guest only ever reads the config
space?

So my question is which approach is the correct one? Is one a legacy
approach or is it "depends on what you are doing"?

Ultimately I guess this points to the need for a bit more API
documentation to make it clear when certain methods should be used.

-- 
Alex Bennée


       reply	other threads:[~2022-02-25 17:57 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87ee3q3mos.fsf@linaro.org>
2022-02-25 17:32 ` Alex Bennée [this message]
2022-02-28 14:03   ` What is the correct way to handle the VirtIO config space in vhost-user? Stefan Hajnoczi
2022-02-28 16:16     ` Alex Bennée
2022-02-28 16:44       ` Peter Maydell
2022-03-01  9:19         ` Stefan Hajnoczi
2022-02-28 17:24       ` Stefan Hajnoczi
2022-03-04 16:49         ` Alex Bennée
2022-03-07  9:21           ` Stefan Hajnoczi
2022-03-07 12:09             ` Alex Bennée
2022-03-08 10:31               ` Stefan Hajnoczi

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=87a6ee3l5e.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=marcandre.lureau@redhat.com \
    --cc=mathieu.poirier@linaro.org \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=raphael.norwitz@nutanix.com \
    --cc=stefanha@redhat.com \
    --cc=viresh.kumar@linaro.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).