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 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).