From: Stefan Hajnoczi <stefanha@redhat.com>
To: Xie Yongji <xieyongji@bytedance.com>
Cc: kwolf@redhat.com, mst@redhat.com, jasowang@redhat.com,
qemu-devel@nongnu.org, raphael.norwitz@nutanix.com,
lingshan.zhu@intel.com, mreitz@redhat.com,
changpeng.liu@intel.com, sgarzare@redhat.com
Subject: Re: [PATCH 0/3] Introduce vhost-vdpa block device
Date: Mon, 26 Apr 2021 16:33:53 +0100 [thread overview]
Message-ID: <YIbdYdxD0CDcX+C2@stefanha-x1.localdomain> (raw)
In-Reply-To: <20210408101252.552-1-xieyongji@bytedance.com>
[-- Attachment #1: Type: text/plain, Size: 2561 bytes --]
On Thu, Apr 08, 2021 at 06:12:49PM +0800, Xie Yongji wrote:
> Since we already have some ways to emulate vDPA block device
> in kernel[1] or userspace[2]. This series tries to introduce a
> new vhost-vdpa block device for that. To use it, we can add
> something like:
>
> qemu-system-x86_64 \
> -device vhost-vdpa-blk-pci,vdpa-dev=/dev/vhost-vdpa-0
This device is similar to vhost-user-blk. QEMU does not see it as a
block device so storage migration, I/O throttling, image formats, etc
are not supported. Stefano Garzarella and I discussed how vdpa-blk
devices could integrate more deeply with QEMU's block layer. The QEMU
block layer could be enabled only when necessary and otherwise bypassed
for maximum performance.
This alternative approach is similar to how vhost-net is implemented in
QEMU. A BlockDriver would handle the vdpa-blk device and the regular
virtio-blk-pci device would still be present. The virtqueues could be
delegated to the vdpa-blk device in order to bypass the QEMU block
layer.
I wanted to mention this since it's likely that this kind of vdpa-blk
device implementation will be posted in the future and you might be
interested. It makes live migration with non-shared storage possible,
for example.
An issue with vhost-user-blk is that the ownership of qdev properties
and VIRTIO Configuration Space fields was not clearly defined. Some
things are handled by QEMU's vhost-user-blk code, some things are
handled by the vhost-user device backend, and some things are negotiated
between both entities. This patch series follows the existing
vhost-user-blk approach, which I think will show serious issues as the
device is more widely used and whenever virtio-blk or the implementation
is extended with new features. It is very hard to provide backwards
compatibility with the current approach where the ownership of qdev
properties and VIRTIO Configuration Space fields is ad-hoc and largely
undefined.
Since vDPA has VIRTIO Configuration Space APIs, I suggest that the
vhost-vDPA device controls the entire configuration space. QEMU should
simply forward accesses between the guest and vhost-vdpa.
Regarding qdev properties, it's a little trickier because QEMU needs to
do the emulated VIRTIO device setup (allocating virtqueues, setting
their sizes, etc). Can QEMU query this information from the vDPA device?
If not, which qdev properties are read-only and must match the
configuration of the vDPA device and which are read-write and can
control the vDPA device?
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2021-04-26 15:36 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-08 10:12 [PATCH 0/3] Introduce vhost-vdpa block device Xie Yongji
2021-04-08 10:12 ` [PATCH 1/3] vhost-vdpa: Remove redundant declaration of address_space_memory Xie Yongji
2021-04-08 10:19 ` Philippe Mathieu-Daudé
2021-04-08 10:12 ` [PATCH 2/3] vhost-blk: Add vhost-blk-common abstraction Xie Yongji
2021-04-08 23:21 ` Raphael Norwitz
2021-04-09 2:38 ` Yongji Xie
2021-04-26 14:49 ` Stefan Hajnoczi
2021-04-27 10:26 ` Yongji Xie
2021-04-08 10:12 ` [PATCH 3/3] vhost-vdpa-blk: Introduce vhost-vdpa-blk host device Xie Yongji
2021-04-09 6:02 ` Jason Wang
2021-04-09 8:17 ` Yongji Xie
2021-04-12 7:14 ` Jason Wang
2021-04-12 7:51 ` Yongji Xie
2021-04-26 15:05 ` Stefan Hajnoczi
2021-04-27 10:33 ` Yongji Xie
2021-04-26 15:33 ` Stefan Hajnoczi [this message]
2021-04-27 10:24 ` Re: [PATCH 0/3] Introduce vhost-vdpa block device Yongji Xie
2021-04-27 14:28 ` Stefan Hajnoczi
2021-04-28 11:27 ` Yongji Xie
2021-04-28 12:21 ` Stefano Garzarella
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=YIbdYdxD0CDcX+C2@stefanha-x1.localdomain \
--to=stefanha@redhat.com \
--cc=changpeng.liu@intel.com \
--cc=jasowang@redhat.com \
--cc=kwolf@redhat.com \
--cc=lingshan.zhu@intel.com \
--cc=mreitz@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=raphael.norwitz@nutanix.com \
--cc=sgarzare@redhat.com \
--cc=xieyongji@bytedance.com \
/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).