On Fri, 2019-09-13 at 13:20 +0200, Max Reitz wrote:
> On 10.09.19 18:13, Maxim Levitsky wrote:
> > On Tue, 2019-09-10 at 14:41 +0200, Max Reitz wrote:
> > > Background: As of cURL 7.59.0, it verifies that several functions are
> > > not called from within a callback
On Fri, 2019-09-13 at 13:01 +0200, Max Reitz wrote:
> On 13.09.19 00:37, Maxim Levitsky wrote:
> > Signed-off-by: Maxim Levitsky
> > ---
> > tests/qemu-iotests/263 | 91 ++
> > tests/qemu-iotests/263.out | 40 +
&g
simplifies everything.
Best regards,
Maxim Levitsky
Maxim Levitsky (3):
block/qcow2: refactoring of threaded encryption code
block/qcow2: fix the corruption when rebasing luks encrypted files
qemu-iotests: Add test for bz #1745922
block/qcow2-cluster.c | 29 +++-
b
This commit tries to clarify few function arguments,
and add comments describing the encrypt/decrypt interface
Signed-off-by: Maxim Levitsky
---
block/qcow2-cluster.c | 9 ---
block/qcow2-threads.c | 62 ++-
block/qcow2.c | 5 ++--
block
Signed-off-by: Maxim Levitsky
---
tests/qemu-iotests/263 | 91 ++
tests/qemu-iotests/263.out | 40 +
tests/qemu-iotests/group | 1 +
3 files changed, 132 insertions(+)
create mode 100755 tests/qemu-iotests/263
create mode 100644 tests
uch writes, and causes some files
with zero areas to contain garbage there instead.
But as described above it can happen elsewhere as well
Signed-off-by: Maxim Levitsky
Reviewed-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Max Reitz
---
block/qcow2-cluster.c | 30 +---
On Fri, 2019-09-13 at 12:37 +0200, Max Reitz wrote:
> On 13.09.19 00:37, Maxim Levitsky wrote:
> > This commit tries to clarify few function arguments,
> > and add comments describing the encrypt/decrypt interface
> >
> > Signed-off-by: Maxim Levitsky
> > --
is correct or working without a unit test, a spec, or
> some instructions to help me verify any of this does what it looks like
> it does.
>
> On 8/25/19 3:15 AM, Maxim Levitsky wrote:
> > Signed-off-by: Maxim Levitsky
> > ---
> > block/nvme.c | 72
Signed-off-by: Maxim Levitsky
---
block/nvme.c | 83 ++
block/trace-events | 2 ++
2 files changed, 85 insertions(+)
diff --git a/block/nvme.c b/block/nvme.c
index d95265fae4..c17edd6aae 100644
--- a/block/nvme.c
+++ b/block/nvme.c
@@ -112,6
This is the second part of the patches I prepared
for this driver back when I worked on mdev-nvme.
V2: addressed review feedback, no major changes
Best regards,
Maxim Levitsky
Maxim Levitsky (2):
block/nvme: add support for write zeros
block/nvme: add support for discard
block
Signed-off-by: Maxim Levitsky
---
block/nvme.c | 72 +++-
block/trace-events | 1 +
include/block/nvme.h | 19 +++-
3 files changed, 90 insertions(+), 2 deletions(-)
diff --git a/block/nvme.c b/block/nvme.c
index 5be3a39b63..d95265fae4
On Fri, 2019-09-13 at 14:01 +, Vladimir Sementsov-Ogievskiy wrote:
> 13.09.2019 15:59, Maxim Levitsky wrote:
> > This commit tries to clarify few function arguments,
> > and add comments describing the encrypt/decrypt interface
> >
> > Signed-off-by: Maxim Levitsky
On Fri, 2019-09-13 at 16:24 +0200, Kevin Wolf wrote:
> Am 13.09.2019 um 16:07 hat Maxim Levitsky geschrieben:
> > On Fri, 2019-09-13 at 14:01 +, Vladimir Sementsov-Ogievskiy wrote:
> > > 13.09.2019 15:59, Maxim Levitsky wrote:
> > > > This commit tries to
simplifies everything.
V5: reworked the patches so one of them fixes the bug
only and other one is just refactoring
Best regards,
Maxim Levitsky
Maxim Levitsky (3):
Fix qcow2+luks corruption introduced by commit 8ac0f15f335
block/qcow2: refactor threaded encryption code
qemu-io
s.
In the bugreport that was triggered by rebasing a luks image to new,
zero filled base, which lot of such writes, and causes some files
with zero areas to contain garbage there instead.
But as described above it can happen elsewhere as well
Signed-off-by: Maxim Levitsky
---
block/qcow2-clu
Signed-off-by: Maxim Levitsky
---
tests/qemu-iotests/263 | 91 ++
tests/qemu-iotests/263.out | 40 +
tests/qemu-iotests/group | 2 +
3 files changed, 133 insertions(+)
create mode 100755 tests/qemu-iotests/263
create mode 100644 tests
qcow2_co_encrypt arguments to prevent
that bug from happening again
Signed-off-by: Maxim Levitsky
---
block/qcow2-cluster.c | 30 -
block/qcow2-threads.c | 62 ++-
block/qcow2.c | 5 ++--
block/qcow2.h | 8 +++---
4
On Fri, 2019-09-13 at 16:11 +, Vladimir Sementsov-Ogievskiy wrote:
> 13.09.2019 18:28, Maxim Levitsky wrote:
> > Change do_perform_cow_encrypt and its callee qcow2_co_encrypt
> > to just receive full host and guest offsets and in pariticular
> > remove the offset_in
On Fri, 2019-09-13 at 16:27 +, Vladimir Sementsov-Ogievskiy wrote:
> 13.09.2019 18:28, Maxim Levitsky wrote:
> > Signed-off-by: Maxim Levitsky
> > ---
> > tests/qemu-iotests/263 | 91 ++
> > test
On Fri, 2019-09-13 at 16:57 +, Vladimir Sementsov-Ogievskiy wrote:
> 13.09.2019 19:39, Maxim Levitsky wrote:
> > On Fri, 2019-09-13 at 16:27 +, Vladimir Sementsov-Ogievskiy wrote:
> > > 13.09.2019 18:28, Maxim Levitsky wrote:
> > > >
simplifies everything.
V5: reworked the patches so one of them fixes the bug
only and other one is just refactoring
V6: removed do_perform_cow_encrypt
Best regards,
Maxim Levitsky
Maxim Levitsky (3):
Fix qcow2+luks corruption introduced by commit 8ac0f15f335
block/qcow2: refacto
qcow2_co_encrypt
Also document the qcow2_co_encrypt arguments to prevent
that bug from happening again
Signed-off-by: Maxim Levitsky
Reviewed-by: Vladimir Sementsov-Ogievskiy
---
block/qcow2-cluster.c | 35 +--
block/qcow2-threads.c | 81
Signed-off-by: Maxim Levitsky
Tested-by: Vladimir Sementsov-Ogievskiy
---
tests/qemu-iotests/263 | 91 ++
tests/qemu-iotests/263.out | 40 +
tests/qemu-iotests/group | 1 +
3 files changed, 132 insertions(+)
create mode 100755 tests
s.
In the bugreport that was triggered by rebasing a luks image to new,
zero filled base, which lot of such writes, and causes some files
with zero areas to contain garbage there instead.
But as described above it can happen elsewhere as well
Signed-off-by: Maxim Levitsky
Reviewed-by: Vladimir
On Fri, 2019-09-13 at 17:51 +, Vladimir Sementsov-Ogievskiy wrote:
> 13.09.2019 20:27, Maxim Levitsky wrote:
> > Change the qcow2_co_encrypt to just receive full host and
> > guest offsets and in pariticular remove the
> > offset_in_cluster parameter of do_perform_cow_enc
{encrypt|decrypt} arguments
to prevent the bug fixed in former commit from hopefully
happening again.
Signed-off-by: Maxim Levitsky
---
block/qcow2-cluster.c | 41 ++--
block/qcow2-threads.c | 63 +--
block/qcow2.c | 5
bit
Best regards,
Maxim Levitsky
Maxim Levitsky (3):
block/qcow2: Fix corruption introduced by commit 8ac0f15f335
block/qcow2: refactor encryption code
qemu-iotests: Add test for bz #1745922
block/qcow2-cluster.c | 40 ++---
block/qcow2-threads.c
avoid all these
assumptions.
In the bugreport that was triggered by rebasing a luks image to new,
zero filled base, which lot of such writes, and causes some files
with zero areas to contain garbage there instead.
But as described above it can happen elsewhere as well
Signed-off-by: Maxim Levitsky
Signed-off-by: Maxim Levitsky
Tested-by: Vladimir Sementsov-Ogievskiy
---
tests/qemu-iotests/263 | 91 ++
tests/qemu-iotests/263.out | 40 +
tests/qemu-iotests/group | 1 +
3 files changed, 132 insertions(+)
create mode 100755 tests
On Mon, 2019-09-16 at 15:39 +0200, Max Reitz wrote:
> On 15.09.19 22:36, Maxim Levitsky wrote:
> > Commit 8ac0f15f335 accidently broke the COW of non changed areas
> > of newly allocated clusters, when the write spans multiple clusters,
> > and needs COW both prior and afte
On Mon, 2019-09-16 at 16:59 +0300, Maxim Levitsky wrote:
> On Mon, 2019-09-16 at 15:39 +0200, Max Reitz wrote:
> > On 15.09.19 22:36, Maxim Levitsky wrote:
> > > Commit 8ac0f15f335 accidently broke the COW of non changed areas
> > > of newly allocated clusters, wh
s, but I myself
don't mind this :-)
> ret = refresh_total_sectors(bs, offset >> BDRV_SECTOR_BITS);
> if (ret < 0) {
> error_setg_errno(errp, -ret, "Could not refresh total sector count");
Looks all right to me, although I don't know the block filters well yet.
Reviewed-by: Maxim Levitsky
Best regards,
Maxim Levitsky
> .bdrv_child_perm= cor_child_perm,
>
> .bdrv_getlength = cor_getlength,
> -.bdrv_co_truncate = cor_co_truncate,
>
> .bdrv_co_preadv = cor_co_preadv,
> .bdrv_co_pwritev= cor_co_pwritev,
Reviewed-by: Maxim Levitsky
Best regards,
Maxim Levitsky
amp;& exact) {
> + error_setg(errp, "Cannot resize iSCSI devices");
> +return -ENOTSUP;
> +} else if (offset > cur_length) {
> error_setg(errp, "Cannot grow iSCSI devices");
> return -EINVAL;
> }
Reviewed-by: Maxim Levitsky
Best regards,
Maxim Levitsky
goto out;
> -}
> -
> /* Write the header */
> QEMU_BUILD_BUG_ON((1 << MIN_CLUSTER_BITS) < sizeof(*header));
> header = g_malloc0(cluster_size);
As long as bdrv_co_create_ops still creates the underlying file with
bdrv_create_file or so,
I also don't see a reason to truncate it to 0 afterward.
Especially for block devices...
So,
Reviewed-by: Maxim Levitsky
Best regards,
Maxim Levitsky
at.c
> @@ -387,7 +387,7 @@ static int coroutine_fn raw_co_truncate(BlockDriverState
> *bs, int64_t offset,
>
> s->size = offset;
> offset += s->offset;
> -return bdrv_co_truncate(bs->file, offset, false, prealloc, errp);
> +return bdrv_co_truncate(bs->file, offset, exact, prealloc, errp);
> }
>
> static void raw_eject(BlockDriverState *bs, bool eject_flag)
Looks all right.
Reviewed-by: Maxim Levitsky
Best regards,
Maxim Levitsky
ed-by: Maxim Levitsky
Best regards,
Maxim Levitsky
ations evaluate it, so that
> this patch does not change existing behavior. Future patches take care
> of that.
>
> Suggested-by: Maxim Levitsky
> Signed-off-by: Max Reitz
> ---
> include/block/block.h | 6 +++---
> include/block/block_int.h | 17 +
rgv)
> return offset;
> }
>
> -ret = blk_truncate(blk, offset, false, PREALLOC_MODE_OFF, &local_err);
> +/*
> + * qemu-io is a debugging tool, so let us be strict here and pass
> + * exact=true. It is better to err on the "emit more errors" side
> + * than to be overly permissive.
> + */
Also agree.
> +ret = blk_truncate(blk, offset, true, PREALLOC_MODE_OFF, &local_err);
> if (ret < 0) {
> error_report_err(local_err);
> return ret;
Other than few nitpicks which probably aren't important,
Reviewed-by: Maxim Levitsky
Best regards,
Maxim Levitsky
On Fri, 2019-09-20 at 17:14 -0400, John Snow wrote:
>
> On 9/12/19 6:30 PM, Maxim Levitsky wrote:
> > This patch series is continuation of my work to add encryption
> > key managment to luks/qcow2 with luks.
> >
> > This is second version of this patch set.
> &g
On Mon, 2019-09-23 at 08:08 -0500, Eric Blake wrote:
> On 9/12/19 5:30 PM, Maxim Levitsky wrote:
> > This adds the qcrypto_amend_options and corresponding
> > crypto driver callbacks for the for encrypted
>
> grammar is off, did you miss a word where that double space is?
&
d to do so.
However qemu-pr-helper should not crash in this case.
Signed-off-by: Maxim Levitsky
---
scsi/qemu-pr-helper.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/scsi/qemu-pr-helper.c b/scsi/qemu-pr-helper.c
index a8a74d1dba..debb18f4aa 100644
--- a/scsi/qemu-pr-help
an
open bug that waits to be closed.
Its also is form of refactoring, and thus I guess it makes
sense to include it here.
Best regards,
Maxim Levitsky
Maxim Levitsky (13):
block-crypto: misc refactoring
qcrypto-luks: rename some fields in QCryptoBlockLUKSHeader
qcrypto-luks: don&#
* rename the write_func to create_write_func,
and init_func to create_init_func
this is preparation for other write_func that will
be used to update the encryption keys.
No functional changes
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
block/crypto.c | 12
This way we can store the header we loaded, which
will be used in key management code
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
crypto/block-luks.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/crypto/block-luks.c b/crypto/block-luks.c
* key_bytes -> master_key_len
* payload_offset = payload_offset_sector (to emphasise that this isn't byte
offset)
* key_offset -> key_offset_sector - same as above for luks slots
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
crypto/block-
Prior to that patch, the parsed encryption settings
were already stored into the QCryptoBlockLUKS but not
used anywhere but in qcrypto_block_luks_get_info
Using them simplifies the code
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
crypto/block-luks.c | 169
This is just to make qcrypto_block_luks_open more
reasonable in size.
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
crypto/block-luks.c | 223 +---
1 file changed, 125 insertions(+), 98 deletions(-)
diff --git a/crypto/block-luks.c b
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
crypto/block-luks.c | 155 ++--
1 file changed, 93 insertions(+), 62 deletions(-)
diff --git a/crypto/block-luks.c b/crypto/block-luks.c
index b8f9b9c20a..47371edf13 100644
--- a/crypto
This function will be used later to store
new keys to the luks metadata
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
crypto/block-luks.c | 304 ++--
1 file changed, 181 insertions(+), 123 deletions(-)
diff --git a/crypto/block
Let the caller allocate masterkey
Always use master key len from the header
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
crypto/block-luks.c | 44 +---
1 file changed, 21 insertions(+), 23 deletions(-)
diff --git a/crypto/block
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
crypto/block-luks.c | 63 -
1 file changed, 40 insertions(+), 23 deletions(-)
diff --git a/crypto/block-luks.c b/crypto/block-luks.c
index 6d4e9eb348..a53d5d1916 100644
--- a/crypto
Another minor refactoring
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
crypto/block-luks.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/crypto/block-luks.c b/crypto/block-luks.c
index 9e59a791a6..b759cc8d19 100644
--- a/crypto/block-luks.c
These values are not used by generic crypto code anyway
Signed-off-by: Maxim Levitsky
---
crypto/block-luks.c | 45 +
1 file changed, 13 insertions(+), 32 deletions(-)
diff --git a/crypto/block-luks.c b/crypto/block-luks.c
index f3bfc921b2
etter, we can make luks driver,
detect -EFBIG and in this case present a better error message,
which is what this patch does
The new error message is:
qemu-img: error creating test.luks: The requested file size is too large
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1534898
Signed-off-b
Check that keyslots don't overlap with the data,
and check that keyslots don't overlap with each other.
(this is done using naive O(n^2) nested loops,
but since there are just 8 keyslots, this doesn't really matter.
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
--
--
open [--type ] [] - open device as mapping
close - close device (remove mapping)
I guess the documentation was not updated?
I tested both by running the iotest 149, and by doing manually:
dd if=/dev/zero bs=4K count=1000 of=./test
cryptsetup -q -v luksFormat --type luks1 --cipher aes-xts-plain64 --key-size
512 --hash sha1 --key-slot 0 --key-file - --iter-time 10 ./test
Tested-by: Maxim Levitsky
Reviewed-by: Maxim Levitsky
Best regards,
Maxim Levitsky
On Fri, 2019-09-27 at 11:15 +0100, Daniel P. Berrangé wrote:
> On Thu, Sep 26, 2019 at 12:35:15AM +0300, Maxim Levitsky wrote:
> > * rename the write_func to create_write_func,
> > and init_func to create_init_func
> > this is preparation for other write_func that will
&g
This is a repost of the same trivial patch I already, which fell through the
cracks.
Could someone queue it up so I close the bugzilla I have for this?
Best regards,
Maxim Levitsky
Maxim Levitsky (1):
block/crypto: better error message when creating too large files
block/crypto.c
etter, we can make luks driver,
detect -EFBIG and in this case present a better error message,
which is what this patch does
The new error message is:
qemu-img: error creating test.luks: The requested file size is too large
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1534898
Signed-off-by: Maxim
On Thu, 2020-04-16 at 12:50 +0300, Maxim Levitsky wrote:
> This is a repost of the same trivial patch I already, which fell through the
> cracks.
> Could someone queue it up so I close the bugzilla I have for this?
I a word - need more coffee :-)
I mean I already posted this patch few m
On Mon, 2020-04-20 at 11:02 +0200, Kevin Wolf wrote:
> Am 16.04.2020 um 11:50 hat Maxim Levitsky geschrieben:
> > Currently if you attampt to create too large file with luks you
> > get the following error message:
> >
> > Formatting 'test.luks', fmt=luk
This is a repost of the same trivial patch I already, which fell through the
cracks.
Could someone queue it up so I close the bugzilla I have for this?
V2: fixed usage of local_err
Best regards,
Maxim Levitsky
Maxim Levitsky (1):
block/crypto: better error message when creating too
etter, we can make luks driver,
detect -EFBIG and in this case present a better error message,
which is what this patch does
The new error message is:
qemu-img: error creating test.luks: The requested file size is too large
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1534898
Signed-off-b
;num_queues *
> > NVME_DB_SIZE);
>
> Unrelated to this change, but it would be cleaner to initialize reg_size
> using MAX_NUM_QUEUES, then in the I/O handler log GUEST_ERROR when
> registers > n->num_queues accessed. This would model closer to the hardware.
Agree.
Also k
e_err_invalid_setfeat(uint32_t dw10) "invalid set features,
> dw10=0x%"PRIx32"
_dma_read(&n->parent_obj, addr, buf, size);
> }
>
> static int nvme_check_sqid(NvmeCtrl *n, uint16_t sqid)
Looks like I forgot to add reviewed-by to the patch from V6,
but it looks all right after our discussion so,
Reviewed-by: Maxim Levitsky
Best regards,
Maxim Levitsky
me.h b/hw/block/nvme.h
> index 1617787af2e9..7eecfd3a50f6 100644
> --- a/hw/block/nvme.h
> +++ b/hw/block/nvme.h
> @@ -88,8 +88,6 @@ typedef struct NvmeCtrl {
> uint32_tnum_namespaces;
> uint32_tmax_q_ents;
> uint64_tns_size;
> -uint32_tcmbsz;
> -uint32_tcmbloc;
> uint8_t *cmbuf;
> uint64_tirq_status;
> uint64_thost_timestamp; /* Timestamp sent by the
> host */
Reviewed-by: Maxim Levitsky
Best regards,
Maxim levitsky
gt; +
> bs_size = blk_getlength(n->conf.blk);
> if (bs_size < 0) {
> error_setg(errp, "could not get backing file size");
> return;
> }
>
> - if (!n->params.serial) {
> -error_setg(errp, "serial property not set");
> -return;
> -}
> blkconf_blocksizes(&n->conf);
> if (!blkconf_apply_backend_options(&n->conf,
> blk_is_read_only(n->conf.blk),
> false, errp)) {
Reviewed-by: Maxim Levitsky
Best regards,
Maxim Levitsky
->num_namespaces;
>
> -n->namespaces = g_new0(NvmeNamespace, n->num_namespaces);
> -n->sq = g_new0(NvmeSQueue *, n->params.max_ioqpairs + 1);
> - n->cq = g_new0(NvmeCQueue *, n->params.max_ioqpairs + 1);
> -
> memory_region_init_io(&n->iomem, OBJECT(n), &nvme_mmio_ops, n,
>"nvme", n->reg_size);
> pci_register_bar(pci_dev, 0,
Reviewed-by: Maxim Levitsky
Best regards,
Maxim Levitsky
; blk_is_read_only(n->conf.blk),
> - false, errp)) {
> +nvme_init_blk(n, &err);
> + if (err) {
> +error_propagate(errp, err);
> return;
> }
>
Reviewed-by: Maxim Levitsky
Best regards,
Maxim Levitsky
rl;
>
> +static inline uint64_t nvme_ns_nlbas(NvmeCtrl *n, NvmeNamespace *ns)
> +{
> +return n->ns_size >> nvme_ns_lbads(ns);
> +}
> +
> #endif /* HW_NVME_H */
Nitpick: On second thought, these function names do sound quite cryptic, so
maybe
at least for nvme_n
dpc = 0;
> -id_ns->dps = 0;
> - id_ns->lbaf[0].ds = BDRV_SECTOR_BITS;
> -id_ns->ncap = id_ns->nuse = id_ns->nsze =
> -cpu_to_le64(nvme_ns_nlbas(n, ns));
> +nvme_init_namespace(n, &n->namespaces[i], &err);
> +if (err) {
> +error_propagate(errp, err);
> +return;
> +}
> }
> }
>
Reviewed-by: Maxim Levitsky
Best regards,
Maxim Levitsky
> -PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_64,
> -&n->iomem);
> -msix_init_exclusive_bar(pci_dev, n->params.max_ioqpairs + 1, 4, NULL);
> -
> id->vid = cpu_to_le16(pci_get_word(pci_conf + PCI_VENDOR_ID));
> id->ssvid = cpu_to_le16(pci_get_word(pci_conf +
> PCI_SUBSYSTEM_VENDOR_ID));
> strpadcpy((char *)id->mn, sizeof(id->mn), "QEMU NVMe Ctrl", ' ');
Reviewed-by: Maxim Levitsky
Best regards,
Maxim Levitsky
/
> -NVME_CMBSZ_SET_SZ(n->bar.cmbsz, n->params.cmb_size_mb);
> -
> -n->cmbuf = g_malloc0(NVME_CMBSZ_GETSIZE(n->bar.cmbsz));
> -memory_region_init_io(&n->ctrl_mem, OBJECT(n), &nvme_cmb_ops, n,
> - "nvme-cmb", NVME_CMBSZ_GETSIZE(n->
rror_propagate(errp, err);
> +return;
> +}
> +
> +
> +nvme_init_state(n);
> +nvme_init_blk(n, &err);
> +if (err) {
> +error_propagate(errp, err);
> + return;
> +}
> +
> +nvme_init_pci(n, pci_dev);
> +nvme_init_ctrl(n, pci_dev);
> +
> for (i = 0; i < n->num_namespaces; i++) {
> nvme_init_namespace(n, &n->namespaces[i], &err);
> if (err) {
Reviewed-by: Maxim Levitsky
Best regards,
Maxim Levitsky
y setup
>
> hw/block/nvme.c | 433 --
> hw/block/nvme.h | 36 +++-
> hw/block/trace-events | 172 -
> include/block/nvme.h | 8 +
> 4 files changed, 372 insertions(+), 277 deletions(-)
>
Should I also review the V7 series or I should wait for V8 which will not
include these cleanups?
Best regards,
Maxim Levitsky
PROP_LINK("pmrdev", _state, pmrdev, TYPE_MEMORY_BACKEND, \
> + HostMemoryBackend *)
> +
> +typedef struct NvmeParams {
> +char *serial;
> +uint32_t num_queues;
> +uint32_t cmb_size_mb;
> +} NvmeParams;
> +
> typedef struct NvmeAsyncEvent {
> QSIMPLEQ_ENTRY(NvmeAsyncEvent) entry;
> NvmeAerResult result;
> @@ -63,6 +77,7 @@ typedef struct NvmeCtrl {
> MemoryRegion ctrl_mem;
> NvmeBar bar;
> BlockConfconf;
> +NvmeParams params;
>
> uint32_tpage_size;
> uint16_tpage_bits;
> @@ -71,10 +86,8 @@ typedef struct NvmeCtrl {
> uint16_tsqe_size;
> uint32_treg_size;
> uint32_tnum_namespaces;
> -uint32_tnum_queues;
> uint32_tmax_q_ents;
> uint64_tns_size;
> -uint32_tcmb_size_mb;
> uint32_tcmbsz;
> uint32_tcmbloc;
> uint8_t *cmbuf;
> @@ -82,7 +95,6 @@ typedef struct NvmeCtrl {
> uint64_thost_timestamp; /* Timestamp sent by the
> host */
> uint64_ttimestamp_set_qemu_clock_ms;/* QEMU clock time */
>
> -char*serial;
> HostMemoryBackend *pmrdev;
>
> NvmeNamespace *namespaces;
Looks OK.
Reviewed-by: Maxim Levitsky
Best regards,
Maxim Levitsky
On Wed, 2020-04-22 at 09:09 +0200, Klaus Jensen wrote:
> From: Klaus Jensen
>
> Introduce some small helpers to make the next patches easier on the eye.
>
> Signed-off-by: Klaus Jensen
> Reviewed-by: Philippe Mathieu-Daudé
> Reviewed-by: Maxim Levitsky
> Reviewed-by:
| 31 ++-
> hw/block/trace-events | 180 +++---
> include/block/nvme.h | 8 +
> 4 files changed, 429 insertions(+), 333 deletions(-)
>
For the series:
Reviewed-by: Maxim Levitsky
Best regards,
Maxim Levitsky
On Mon, 2019-07-22 at 10:05 +0100, Daniel P. Berrangé wrote:
> On Sun, Jul 21, 2019 at 09:15:07PM +0300, Maxim Levitsky wrote:
> > Currently if you attampt to create too large file with luks you
> > get the following error message:
> >
> > Formatting 'test.luks&#x
On Thu, 2020-04-30 at 15:18 +0300, Maxim Levitsky wrote:
> On Mon, 2019-07-22 at 10:05 +0100, Daniel P. Berrangé wrote:
> > On Sun, Jul 21, 2019 at 09:15:07PM +0300, Maxim Levitsky wrote:
> > > Currently if you attampt to create too large file with luks you
> > > get
On Mon, 2020-04-20 at 12:29 +0300, Maxim Levitsky wrote:
> Currently if you attampt to create too large file with luks you
> get the following error message:
>
> Formatting 'test.luks', fmt=luks size=17592186044416 key-secret=sec0
> qemu-img: test.luks: Could not re
On Tue, 2020-04-28 at 14:16 +0100, Daniel P. Berrangé wrote:
> On Sun, Mar 08, 2020 at 05:18:51PM +0200, Maxim Levitsky wrote:
> > Next few patches will expose that functionality
> > to the user.
> >
> > Signed-off-by: Maxim Levitsky
> > -
ach the actual amend operation anyway
Fixes: f62514b3def5fb2acbef64d0e053c0c31fa45aff
Signed-off-by: Maxim Levitsky
---
tests/qemu-iotests/153 | 2 +-
tests/qemu-iotests/153.out | 12 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/tests/qemu-iotests/153 b/tests/qem
eplacing it will
be better.
Best regards,
Maxim Levitsky
clone of "luks-keymgmnt-v2"
Maxim Levitsky (14):
qcrypto/core: add generic infrastructure for crypto options amendment
qcrypto/luks: implement encryption key management
block/amend: add 'force' option
Some qcow2 create options can't be used for amend.
Remove them from the qcow2 create options and add generic logic to detect
such options in qemu-img
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
block/qcow2.c | 108 ++---
qemu-
This will be used first to implement luks keyslot management.
block_crypto_amend_opts_init will be used to convert
qemu-img cmdline to QCryptoBlockAmendOptions
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
block/crypto.c | 17 +
block/crypto.h
'force' option will be used for some unsafe amend operations.
This includes things like erasing last keyslot in luks based formats
(which destroys the data, unless the master key is backed up
by external means), but that _might_ be desired result.
Signed-off-by: Maxim Levitsky
R
ange for the idea of
unsharing read, rather that write permission which allows
to avoid cases when the other user had opened the image read-only.
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
block/crypto.c | 127 +++--
block/crypto.h |
This commit adds two tests that cover the
new blockdev-amend functionality of luks and qcow2 driver
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
tests/qemu-iotests/302 | 278 +
tests/qemu-iotests/302.out | 40 ++
tests/qemu
it in each action option list.
In future it might be useful to remove some options which are
not supported anyway from amend list, which currently
cause an error message if amended.
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
block/qcow2.c | 160
This allows more tests to be able to have same output on both qcow2 luks
encrypted images
and raw luks images
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
tests/qemu-iotests/087.out | 6 ++---
tests/qemu-iotests/134.out | 2 +-
tests/qemu-iotests/158.out
Next few patches will expose that functionality
to the user.
Signed-off-by: Maxim Levitsky
---
crypto/block-luks.c | 406 +++-
qapi/crypto.json| 61 ++-
2 files changed, 463 insertions(+), 4 deletions(-)
diff --git a/crypto/block-luks.c b/crypto
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
block/crypto.c | 72
qapi/block-core.json | 14 -
2 files changed, 66 insertions(+), 20 deletions(-)
diff --git a/block/crypto.c b/block/crypto.c
index b71e57f777
blockdev-amend will be used similiar to blockdev-create
to allow on the fly changes of the structure of the format based block devices.
Current plan is to first support encryption keyslot management for luks
based formats (raw and embedded in qcow2)
Signed-off-by: Maxim Levitsky
Reviewed-by
This commit adds two tests, which test the new amend interface
of both luks raw images and qcow2 luks encrypted images.
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
tests/qemu-iotests/300 | 207 +
tests/qemu-iotests/300.out | 99
rename the write_func to create_write_func, and init_func to create_init_func.
This is preparation for other write_func that will be used to update the
encryption keys.
No functional changes
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
block/crypto.c | 25
Now that we have all the infrastructure in place,
wire it in the qcow2 driver and expose this to the user.
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
block/qcow2.c | 72 +-
tests/qemu-iotests/082.out | 45
Currently the implementation only supports amending the encryption
options, unlike the qemu-img version
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
block/qcow2.c| 39 +++
qapi/block-core.json | 16 +++-
2 files
201 - 300 of 959 matches
Mail list logo
