On Fri, Nov 23, 2018 at 07:55:07PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> Add thread-based encrypt/decrypt. QCrypto don't support parallel
> operations with one block, so we need QCryptoBlock for each thread.
> +static int qcow2_crypto_blocks_open(BDRVQcow2State *s,
> + const char *optprefix,
> + QCryptoBlockReadFunc readfunc,
> + void *opaque,
> + unsigned int flags,
> + Error **errp)
> +{
> + int i;
> +
> + s->crypto = qcrypto_block_open(s->crypto_opts, optprefix,
> + readfunc, opaque, flags, errp);
> + if (!s->crypto) {
> + qcrypto_block_free(s->crypto);
> + return -EINVAL;
> + }
> +
> + for (i = 0; i < QCOW2_MAX_THREADS; i++) {
> + s->threads.per_thread[i].crypto =
> + qcrypto_block_open(s->crypto_opts, optprefix,
> + readfunc, opaque, flags, errp);
We really don't want to be doing this. LUKS has an intentional time
penalty for opening devices. Each time you open a disk, we expect to
burn 1-2 seconds in CPU time. So this is multiplying that burn by
QCOW2_MAX_THREADS.
What we need todo is modify QCryptoBlock so that it can (optionally)
create many QCryptoCipher instances, allowing each thread to have its
own instance. We'll also need locking around the iv generator calls.
> + if (!s->threads.per_thread[i].crypto) {
> + qcow2_crypto_blocks_free(s);
> + return -EINVAL;
> + }
> + }
> +
> + return 0;
> +}
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
