From: Stefan Hajnoczi <stefanha@redhat.com>
To: Daniil Tatianin <d-tatianin@yandex-team.ru>
Cc: qemu-devel@nongnu.org, mst@redhat.com,
raphael.norwitz@nutanix.com, kwolf@redhat.com, hreitz@redhat.com,
qemu-block@nongnu.org, yc-core@yandex-team.ru
Subject: Re: [PATCH v1 5/5] vhost-user-blk: dynamically resize config space based on features
Date: Wed, 24 Aug 2022 14:28:31 -0400 [thread overview]
Message-ID: <YwZtz4z6kZMZyDRN@fedora> (raw)
In-Reply-To: <20220824091837.301708-6-d-tatianin@yandex-team.ru>
[-- Attachment #1: Type: text/plain, Size: 3058 bytes --]
On Wed, Aug 24, 2022 at 12:18:37PM +0300, Daniil Tatianin wrote:
> Make vhost-user-blk backwards compatible when migrating from older VMs
> running with modern features turned off, the same way it was done for
> virtio-blk in 20764be0421c ("virtio-blk: set config size depending on the features enabled")
>
> It's currently impossible to migrate from an older VM with
> vhost-user-blk (with disable-legacy=off) because of errors like this:
>
> qemu-system-x86_64: get_pci_config_device: Bad config data: i=0x10 read: 41 device: 1 cmask: ff wmask: 80 w1cmask:0
> qemu-system-x86_64: Failed to load PCIDevice:config
> qemu-system-x86_64: Failed to load virtio-blk:virtio
> qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:05.0:00.0:02.0/virtio-blk'
> qemu-system-x86_64: load of migration failed: Invalid argument
>
> This is caused by the newer (destination) VM requiring a bigger BAR0
> alignment because it has to cover a bigger configuration space, which
> isn't actually needed since those additional config fields are not
> active (write-zeroes/discard).
>
> Signed-off-by: Daniil Tatianin <d-tatianin@yandex-team.ru>
> ---
> hw/block/vhost-user-blk.c | 15 ++++++++-------
> include/hw/virtio/vhost-user-blk.h | 1 +
> 2 files changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/hw/block/vhost-user-blk.c b/hw/block/vhost-user-blk.c
> index 64f3457373..d18a7a2cd4 100644
> --- a/hw/block/vhost-user-blk.c
> +++ b/hw/block/vhost-user-blk.c
> @@ -23,6 +23,7 @@
> #include "hw/qdev-core.h"
> #include "hw/qdev-properties.h"
> #include "hw/qdev-properties-system.h"
> +#include "hw/virtio/virtio-blk-common.h"
> #include "hw/virtio/vhost.h"
> #include "hw/virtio/vhost-user-blk.h"
> #include "hw/virtio/virtio.h"
> @@ -63,7 +64,7 @@ static void vhost_user_blk_update_config(VirtIODevice *vdev, uint8_t *config)
> /* Our num_queues overrides the device backend */
> virtio_stw_p(vdev, &s->blkcfg.num_queues, s->num_queues);
>
> - memcpy(config, &s->blkcfg, sizeof(struct virtio_blk_config));
> + memcpy(config, &s->blkcfg, s->config_size);
Please drop the s->config_size field introduced in this patch and use
vdev->config_len instead. When the same value is stored in multiple
places it's hard to be sure each copy remains identical and bugs can
creep in.
For example, if vdev->config_len is used consistently then it's clear
that buffer overflows and information leaks are prevented by common
code:
uint32_t virtio_config_readb(VirtIODevice *vdev, uint32_t addr)
{
VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(vdev);
uint8_t val;
if (addr + sizeof(val) > vdev->config_len) {
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
return (uint32_t)-1;
}
k->get_config(vdev, vdev->config);
It's safe because vdev->config is g_malloc0(vdev->config_len).
Buf if I see s->config_size, I don't really know whether it's safe and I
need to audit the code to be sure.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
prev parent reply other threads:[~2022-08-24 18:31 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-24 9:18 [PATCH v1 0/5] vhost-user-blk: dynamically resize config space based on features Daniil Tatianin
2022-08-24 9:18 ` [PATCH v1 1/5] virtio-blk: decouple config size determination code from VirtIOBlock Daniil Tatianin
2022-08-24 9:18 ` [PATCH v1 2/5] virtio-blk: move config space sizing code to virtio-blk-common Daniil Tatianin
2022-08-24 18:13 ` Stefan Hajnoczi
2022-08-24 21:11 ` Daniil Tatianin
2022-08-25 13:45 ` Stefan Hajnoczi
2022-08-24 9:18 ` [PATCH v1 3/5] vhost-user-blk: make it possible to disable write-zeroes/discard Daniil Tatianin
2022-08-24 18:00 ` Stefan Hajnoczi
2022-08-24 20:24 ` Daniil Tatianin
2022-08-25 13:34 ` Stefan Hajnoczi
2022-08-24 9:18 ` [PATCH v1 4/5] vhost-user-blk: make 'config_wce' part of 'host_features' Daniil Tatianin
2022-08-24 18:01 ` Stefan Hajnoczi
2022-08-24 9:18 ` [PATCH v1 5/5] vhost-user-blk: dynamically resize config space based on features Daniil Tatianin
2022-08-24 18:28 ` Stefan Hajnoczi [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=YwZtz4z6kZMZyDRN@fedora \
--to=stefanha@redhat.com \
--cc=d-tatianin@yandex-team.ru \
--cc=hreitz@redhat.com \
--cc=kwolf@redhat.com \
--cc=mst@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.