qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC v4 01/11] blkio: add libblkio block driver


From: Stefan Hajnoczi
Subject: Re: [RFC v4 01/11] blkio: add libblkio block driver
Date: Tue, 30 Aug 2022 16:18:52 -0400

On Tue, Aug 30, 2022 at 09:30:16AM +0200, Markus Armbruster wrote:
> Stefan Hajnoczi <stefanha@redhat.com> writes:
> 
> > libblkio (https://gitlab.com/libblkio/libblkio/) is a library for
> > high-performance disk I/O. It currently supports io_uring,
> > virtio-blk-vhost-user, and virtio-blk-vhost-vdpa with additional drivers
> > under development.
> >
> > One of the reasons for developing libblkio is that other applications
> > besides QEMU can use it. This will be particularly useful for
> > virtio-blk-vhost-user which applications may wish to use for connecting
> > to qemu-storage-daemon.
> >
> > libblkio also gives us an opportunity to develop in Rust behind a C API
> > that is easy to consume from QEMU.
> >
> > This commit adds io_uring, virtio-blk-vhost-user, and
> > virtio-blk-vhost-vdpa BlockDrivers to QEMU using libblkio. It will be
> > easy to add other libblkio drivers since they will share the majority of
> > code.
> >
> > For now I/O buffers are copied through bounce buffers if the libblkio
> > driver requires it. Later commits add an optimization for
> > pre-registering guest RAM to avoid bounce buffers.
> >
> > The syntax is:
> >
> >   --blockdev 
> > io_uring,node-name=drive0,filename=test.img,readonly=on|off,cache.direct=on|off
> >
> > and:
> >
> >   --blockdev 
> > virtio-blk-vhost-vdpa,node-name=drive0,path=/dev/vdpa...,readonly=on|off
> >
> > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> > ---
> >  MAINTAINERS                   |   6 +
> >  meson_options.txt             |   2 +
> >  qapi/block-core.json          |  53 ++-
> >  meson.build                   |   9 +
> >  block/blkio.c                 | 725 ++++++++++++++++++++++++++++++++++
> >  tests/qtest/modules-test.c    |   3 +
> >  block/meson.build             |   1 +
> >  scripts/meson-buildoptions.sh |   3 +
> >  8 files changed, 800 insertions(+), 2 deletions(-)
> >  create mode 100644 block/blkio.c
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 5ce4227ff6..f8ccd5954c 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -3397,6 +3397,12 @@ L: qemu-block@nongnu.org
> >  S: Maintained
> >  F: block/vdi.c
> >  
> > +blkio
> > +M: Stefan Hajnoczi <stefanha@redhat.com>
> > +L: qemu-block@nongnu.org
> > +S: Maintained
> > +F: block/blkio.c
> > +
> >  iSCSI
> >  M: Ronnie Sahlberg <ronniesahlberg@gmail.com>
> >  M: Paolo Bonzini <pbonzini@redhat.com>
> > diff --git a/meson_options.txt b/meson_options.txt
> > index e58e158396..67d841a8d2 100644
> > --- a/meson_options.txt
> > +++ b/meson_options.txt
> > @@ -117,6 +117,8 @@ option('bzip2', type : 'feature', value : 'auto',
> >         description: 'bzip2 support for DMG images')
> >  option('cap_ng', type : 'feature', value : 'auto',
> >         description: 'cap_ng support')
> > +option('blkio', type : 'feature', value : 'auto',
> > +       description: 'libblkio block device driver')
> >  option('bpf', type : 'feature', value : 'auto',
> >          description: 'eBPF support')
> >  option('cocoa', type : 'feature', value : 'auto',
> > diff --git a/qapi/block-core.json b/qapi/block-core.json
> > index 2173e7734a..c8d217b50c 100644
> > --- a/qapi/block-core.json
> > +++ b/qapi/block-core.json
> > @@ -2951,11 +2951,16 @@
> >              'file', 'snapshot-access', 'ftp', 'ftps', 'gluster',
> >              {'name': 'host_cdrom', 'if': 'HAVE_HOST_BLOCK_DEVICE' },
> >              {'name': 'host_device', 'if': 'HAVE_HOST_BLOCK_DEVICE' },
> > -            'http', 'https', 'iscsi',
> > +            'http', 'https',
> > +            { 'name': 'io_uring', 'if': 'CONFIG_BLKIO' },
> > +            'iscsi',
> >              'luks', 'nbd', 'nfs', 'null-aio', 'null-co', 'nvme', 
> > 'parallels',
> >              'preallocate', 'qcow', 'qcow2', 'qed', 'quorum', 'raw', 'rbd',
> >              { 'name': 'replication', 'if': 'CONFIG_REPLICATION' },
> > -            'ssh', 'throttle', 'vdi', 'vhdx', 'vmdk', 'vpc', 'vvfat' ] }
> > +            'ssh', 'throttle', 'vdi', 'vhdx',
> > +            { 'name': 'virtio-blk-vhost-user', 'if': 'CONFIG_BLKIO' },
> > +            { 'name': 'virtio-blk-vhost-vdpa', 'if': 'CONFIG_BLKIO' },
> > +            'vmdk', 'vpc', 'vvfat' ] }
> >  
> >  ##
> >  # @BlockdevOptionsFile:
> > @@ -3678,6 +3683,42 @@
> >              '*debug': 'int',
> >              '*logfile': 'str' } }
> >  
> > +##
> > +# @BlockdevOptionsIoUring:
> > +#
> > +# Driver specific block device options for the io_uring backend.
> > +#
> > +# @filename: path to the image file
> > +#
> > +# Since: 7.2
> > +##
> > +{ 'struct': 'BlockdevOptionsIoUring',
> > +  'data': { 'filename': 'str' } }
> > +
> > +##
> > +# @BlockdevOptionsVirtioBlkVhostUser:
> > +#
> > +# Driver specific block device options for the virtio-blk-vhost-user 
> > backend.
> > +#
> > +# @path: path to the vhost-user UNIX domain socket.
> > +#
> > +# Since: 7.2
> > +##
> > +{ 'struct': 'BlockdevOptionsVirtioBlkVhostUser',
> > +  'data': { 'path': 'str' } }
> > +
> > +##
> > +# @BlockdevOptionsVirtioBlkVhostVdpa:
> > +#
> > +# Driver specific block device options for the virtio-blk-vhost-vdpa 
> > backend.
> > +#
> > +# @path: path to the vhost-vdpa character device.
> > +#
> > +# Since: 7.2
> > +##
> > +{ 'struct': 'BlockdevOptionsVirtioBlkVhostVdpa',
> > +  'data': { 'path': 'str' } }
> > +
> 
> We seem to be evenly split between 'filename' and 'path'.  Before the
> patch we have four uses of 'filename' in this schema file (ImageInfo,
> ImageCheck, BlockDriverOptionsFile, BlockdevCreateOptionsFile), and
> three of 'path' (BlockdevOptionsSsh, BlockdevOptionsGluster,
> BlockdevOptionsNfs).  There's also 'backing-file', 'data-file',
> 'backing-filename', 'file', and probably more (I stopped looking).
> 
> I dislike 'path'.  For what it's worth, POSIX calls this "pathname", and
> the components "filename".  Everyday use hardly ever distinguishes
> between the two.  Plain "path", however, is commonly used for lists of
> directories.

Yes :/

Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]