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
next parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.