All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Denis Plotnikov <den-plotnikov@yandex-team.ru>
Cc: kwolf@redhat.com, yc-core@yandex-team.ru, qemu-devel@nongnu.org,
	qemu-block@nongnu.org, raphael.norwitz@nutanix.com
Subject: Re: [PATCH v0 1/2] vhost-user-blk: add a new vhost-user-virtio-blk type
Date: Mon, 4 Oct 2021 11:16:24 -0400	[thread overview]
Message-ID: <20211004111133-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20211004150731.191270-2-den-plotnikov@yandex-team.ru>

On Mon, Oct 04, 2021 at 06:07:30PM +0300, Denis Plotnikov wrote:
> Adding the new vhost-user-blk type instead of modifying the existing one
> is convenent. It ease to differ the new virtio-blk-compatible vhost-user-blk
> device from the existing non-compatible one using qemu machinery without any
> other modifiactions. That gives all the variety of qemu device related
> constraints out of box.

Convenient for the developer maybe, but isn't it confusing for the user?
I don't really understand this paragraph. E.g. what are the constraints
here?



> 
> Signed-off-by: Denis Plotnikov <den-plotnikov@yandex-team.ru>
> ---
>  hw/block/vhost-user-blk.c          | 63 ++++++++++++++++++++++++++++++
>  include/hw/virtio/vhost-user-blk.h |  2 +
>  2 files changed, 65 insertions(+)
> 
> diff --git a/hw/block/vhost-user-blk.c b/hw/block/vhost-user-blk.c
> index ba13cb87e520..877fe54e891f 100644
> --- a/hw/block/vhost-user-blk.c
> +++ b/hw/block/vhost-user-blk.c
> @@ -30,6 +30,7 @@
>  #include "hw/virtio/virtio-access.h"
>  #include "sysemu/sysemu.h"
>  #include "sysemu/runstate.h"
> +#include "migration/qemu-file-types.h"
>  
>  #define REALIZE_CONNECTION_RETRIES 3
>  
> @@ -612,9 +613,71 @@ static const TypeInfo vhost_user_blk_info = {
>      .class_init = vhost_user_blk_class_init,
>  };
>  
> +/*
> + * this is the same as vmstate_virtio_blk
> + * we use it to allow virtio-blk <-> vhost-user-virtio-blk migration
> + */
> +static const VMStateDescription vmstate_vhost_user_virtio_blk = {
> +    .name = "virtio-blk",
> +    .minimum_version_id = 2,
> +    .version_id = 2,
> +    .fields = (VMStateField[]) {
> +        VMSTATE_VIRTIO_DEVICE,
> +        VMSTATE_END_OF_LIST()
> +    },
> +};
> +
> +static void vhost_user_virtio_blk_save(VirtIODevice *vdev, QEMUFile *f)
> +{
> +    /*
> +     * put a zero byte in the stream to be compatible with virtio-blk
> +     */
> +    qemu_put_sbyte(f, 0);
> +}
> +
> +static int vhost_user_virtio_blk_load(VirtIODevice *vdev, QEMUFile *f,
> +                                      int version_id)
> +{
> +    if (qemu_get_sbyte(f)) {
> +        /*
> +         * on virtio-blk -> vhost-user-virtio-blk migration we don't expect
> +         * to get any infilght requests in the migration stream because
> +         * we can't load them yet.
> +         * TODO: consider putting those inflight requests to inflight region
> +         */
> +        error_report("%s: can't load in-flight requests",
> +                     TYPE_VHOST_USER_VIRTIO_BLK);
> +        return -EINVAL;
> +    }
> +
> +    return 0;
> +}
> +
> +static void vhost_user_virtio_blk_class_init(ObjectClass *klass, void *data)
> +{
> +    DeviceClass *dc = DEVICE_CLASS(klass);
> +    VirtioDeviceClass *vdc = VIRTIO_DEVICE_CLASS(klass);
> +
> +    /* override vmstate of vhost_user_blk */
> +    dc->vmsd = &vmstate_vhost_user_virtio_blk;

So can't we do something like this in vhost_user_blk_class_init:

	if qemu >= 6.2
		dc->vmsd = &vmstate_vhost_user_virtio_blk;
	else
		dc->vmsd = &vmstate_vhost_user_blk

?

> +
> +    /* adding callbacks to be compatible with virtio-blk migration stream */
> +    vdc->save = vhost_user_virtio_blk_save;
> +    vdc->load = vhost_user_virtio_blk_load;
> +}
> +
> +static const TypeInfo vhost_user_virtio_blk_info = {
> +    .name = TYPE_VHOST_USER_VIRTIO_BLK,
> +    .parent = TYPE_VHOST_USER_BLK,
> +    .instance_size = sizeof(VHostUserBlk),
> +    /* instance_init is the same as in parent type */
> +    .class_init = vhost_user_virtio_blk_class_init,
> +};
> +
>  static void virtio_register_types(void)
>  {
>      type_register_static(&vhost_user_blk_info);
> +    type_register_static(&vhost_user_virtio_blk_info);
>  }
>  
>  type_init(virtio_register_types)
> diff --git a/include/hw/virtio/vhost-user-blk.h b/include/hw/virtio/vhost-user-blk.h
> index 7c91f15040eb..d81f18d22596 100644
> --- a/include/hw/virtio/vhost-user-blk.h
> +++ b/include/hw/virtio/vhost-user-blk.h
> @@ -23,6 +23,8 @@
>  #include "qom/object.h"
>  
>  #define TYPE_VHOST_USER_BLK "vhost-user-blk"
> +#define TYPE_VHOST_USER_VIRTIO_BLK "vhost-user-virtio-blk"
> +
>  OBJECT_DECLARE_SIMPLE_TYPE(VHostUserBlk, VHOST_USER_BLK)
>  
>  #define VHOST_USER_BLK_AUTO_NUM_QUEUES UINT16_MAX
> -- 
> 2.25.1



  reply	other threads:[~2021-10-04 15:19 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-04 15:07 [PATCH v0 0/2] virtio-blk and vhost-user-blk cross-device migration Denis Plotnikov
2021-10-04 15:07 ` [PATCH v0 1/2] vhost-user-blk: add a new vhost-user-virtio-blk type Denis Plotnikov
2021-10-04 15:16   ` Michael S. Tsirkin [this message]
2021-10-04 15:07 ` [PATCH v0 2/2] vhost-user-blk-pci: add new pci device type to support vhost-user-virtio-blk Denis Plotnikov
2021-10-04 15:11 ` [PATCH v0 0/2] virtio-blk and vhost-user-blk cross-device migration Michael S. Tsirkin
2021-10-04 23:18   ` Roman Kagan
2021-10-05  6:51     ` Michael S. Tsirkin
2021-10-05 14:01       ` Dr. David Alan Gilbert
2021-10-05 16:10         ` Eduardo Habkost
2021-10-05 22:06           ` Michael S. Tsirkin
2021-10-06  8:09             ` Dr. David Alan Gilbert
2021-10-06  8:17               ` Michael S. Tsirkin
2021-10-06  8:28                 ` Dr. David Alan Gilbert
2021-10-06  8:36                   ` Michael S. Tsirkin
2021-10-06  8:43                     ` Dr. David Alan Gilbert
2021-10-06 12:18                       ` Michael S. Tsirkin
2021-10-06 13:29                         ` Dr. David Alan Gilbert
2021-10-06 13:39                           ` Michael S. Tsirkin
2021-10-06 14:27                             ` Dr. David Alan Gilbert
2021-10-06 14:37                               ` Michael S. Tsirkin

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=20211004111133-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=den-plotnikov@yandex-team.ru \
    --cc=kwolf@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=raphael.norwitz@nutanix.com \
    --cc=yc-core@yandex-team.ru \
    /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.