I figure Kevin knows, but you typoed his e-mail address. I fixed it for
you.
Anton Kuchin writes:
> Hello,
>
> I'm trying to switch from -drive parameter to -blockdev + -device and
> having problems. Looks like with this option I have no way to set the
> name of created BlockBackend, but some
On 11/30/18 4:03 PM, Eric Blake wrote:
Our open-coding of strtol handling forgot to handle overflow
conditions. What's more, since we insiste on a user-supplied
partition to be non-zero, we can use 0 rather than -1 for our
initial value to distinguish when a partition is not being
served, for sli
On 12/5/18 9:03 AM, Vladimir Sementsov-Ogievskiy wrote:
01.12.2018 1:03, Eric Blake wrote:
Consolidate on using decimal (not hex) and on outputting the
option reply name (not just value) when the client reports
protocol discrepancies from the server. While it won't affect
normal operation, it m
On 12/10/18 12:50 PM, Vladimir Sementsov-Ogievskiy wrote:
10.12.2018 21:09, Andrey Shinkevich wrote:
In the 'Format specific information' section of the 'qemu-img info'
command output, the supplemental information about existing QCOW2
bitmaps will be shown, such as a bitmap name, flags and granu
Hello,
I'm trying to switch from -drive parameter to -blockdev + -device and
having problems. Looks like with this option I have no way to set the
name of created BlockBackend, but some QMP and HMP commands are trying
to find blk with blk_by_name() and fail to locate my device (e.g.
hmp_comm
On Thu, Dec 06, 2018 at 11:14:23AM +0100, remy.n...@blade-group.com wrote:
> +if (is_new) {
> +new_node->pfd.fd = fd;
> +} else {
> +deleted = aio_remove_fd_handler(ctx, node);
> +new_node->pfd = node->pfd;
Does this drop revents? Imagine revent
10.12.2018 21:09, Andrey Shinkevich wrote:
> In the 'Format specific information' section of the 'qemu-img info'
> command output, the supplemental information about existing QCOW2
> bitmaps will be shown, such as a bitmap name, flags and granularity:
>
[...]
> --- a/block/qcow2.c
> +++ b/block/
In the 'Format specific information' section of the 'qemu-img info'
command output, the supplemental information about existing QCOW2
bitmaps will be shown, such as a bitmap name, flags and granularity:
image: /vz/vmprivate/VM1/harddisk.hdd
file format: qcow2
virtual size: 64G (68719476736 bytes)
On Mon, Dec 10, 2018 at 11:26:49AM +, Peter Maydell wrote:
> Currently qemu_uuid_bswap() takes a pointer to the QemuUUID to
> be byte-swapped. This means it can't be used when the UUID
> to be swapped is in a packed member of a struct. It's also
> out of line with the general bswap*() functions
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 07 December 2018 18:21
> To: Paul Durrant
> Cc: qemu-de...@nongnu.org; qemu-block@nongnu.org; xen-
> de...@lists.xenproject.org; Stefano Stabellini ;
> Kevin Wolf ; Max Reitz
> Subject: Re: [PATCH v2 14
On Mon 10 Dec 2018 04:16:48 PM CET, Daniel P. Berrangé wrote:
>> In other words, the cleanup code won't touch uninitialized elements
>> because it cannot even tell the difference between an index that
>> points to an uninitialized element of the array and an index that
>> points beyond the allocate
On 30.11.18 09:55, Andrey Shinkevich wrote:
> Discards the block duplicated in an intermediate backing file
> after the block have been copied into the active layer during
> QMP block-stream operation.
> It saves the disk space while merging external snapshots.
>
> Signed-off-by: Andrey Shinkevich
On Fri, Dec 07, 2018 at 07:13:46PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> Hi all.
>
> v3:
> 01: add r-b by Daniel and Alberto
> 02: Alberto r-b
> encrypt->encdec for generic
> 03: qcrypto_cipher_*crypt_helper->
> qcrypto_block_cipher_*crypt_helper
> 04: rebased on previous renamings
On Mon, Dec 10, 2018 at 04:09:31PM +0100, Alberto Garcia wrote:
> On Mon 10 Dec 2018 03:52:03 PM CET, Daniel P. Berrangé wrote:
> >> > +int qcrypto_block_init_cipher(QCryptoBlock *block,
> >> > + QCryptoCipherAlgorithm alg,
> >> > + QCryptoC
On Mon 10 Dec 2018 03:52:03 PM CET, Daniel P. Berrangé wrote:
>> > +int qcrypto_block_init_cipher(QCryptoBlock *block,
>> > + QCryptoCipherAlgorithm alg,
>> > + QCryptoCipherMode mode,
>> > + const uint8_t *key,
On Mon, Dec 10, 2018 at 03:06:59PM +0100, Alberto Garcia wrote:
> On Fri 07 Dec 2018 05:13:51 PM CET, Vladimir Sementsov-Ogievskiy wrote:
> > @@ -148,12 +154,97 @@ int qcrypto_block_encrypt(QCryptoBlock *block,
> >
> > QCryptoCipher *qcrypto_block_get_cipher(QCryptoBlock *block)
> > {
> > -
On Fri 07 Dec 2018 05:13:51 PM CET, Vladimir Sementsov-Ogievskiy wrote:
> @@ -148,12 +154,97 @@ int qcrypto_block_encrypt(QCryptoBlock *block,
>
> QCryptoCipher *qcrypto_block_get_cipher(QCryptoBlock *block)
> {
> -return block->cipher;
> +/* Ciphers should be accessed through pop/push
On Mon 10 Dec 2018 02:21:56 PM CET, Daniel P. Berrangé wrote:
> On Mon, Dec 10, 2018 at 11:44:22AM +0100, Alberto Garcia wrote:
>> On Fri 07 Dec 2018 05:13:49 PM CET, Vladimir Sementsov-Ogievskiy wrote:
>> > Rename qcrypto_block_*crypt_helper to qcrypto_cipher_*crypt_helper, as
>>
>> You forgot to
On Mon, Dec 10, 2018 at 11:44:22AM +0100, Alberto Garcia wrote:
> On Fri 07 Dec 2018 05:13:49 PM CET, Vladimir Sementsov-Ogievskiy wrote:
> > Rename qcrypto_block_*crypt_helper to qcrypto_cipher_*crypt_helper, as
>
> You forgot to update the new function names in the commit message.
>
> > -int qc
Please don't use "Content-Transfer-Encoding: base64".
Andrey Shinkevich writes:
> On 07.12.2018 19:20, Eric Blake wrote:
>
>> On 12/7/18 4:00 AM, Andrey Shinkevich wrote:
[...]
>>> +++ b/block/qcow2.c
>>> @@ -4270,6 +4270,12 @@ static ImageInfoSpecific
>>> *qcow2_get_specific_info(BlockDriverSt
On 07.12.2018 19:20, Eric Blake wrote:
> On 12/7/18 4:00 AM, Andrey Shinkevich wrote:
>> In the 'Format specific information' section of the 'qemu-img info'
>> command output, the supplemental information about existing QCOW2
>> bitmaps will be shown, such as a bitmap name, flags and granularity:
On 07.12.2018 15:26, Kevin Wolf wrote:
> Am 05.12.2018 um 13:23 hat Denis Plotnikov geschrieben:
>> At the time, the "drained section" doesn't protect Block Driver State
>> from the requests appearing in the vCPU threads.
>> This could lead to the data loss because of request coming to
>> an unex
Am 10.12.2018 um 13:14 hat Denis Plotnikov geschrieben:
> >> @@ -491,9 +506,17 @@ int64_t aio_compute_timeout(AioContext *ctx);
> >>*/
> >> static inline void aio_disable_external(AioContext *ctx)
> >> {
> >> +aio_context_acquire(ctx);
> >> atomic_inc(&ctx->external_disable_cnt);
On Mon, Dec 10, 2018 at 3:27 PM Peter Maydell wrote:
>
> Currently qemu_uuid_bswap() takes a pointer to the QemuUUID to
> be byte-swapped. This means it can't be used when the UUID
> to be swapped is in a packed member of a struct. It's also
> out of line with the general bswap*() functions we pro
Currently qemu_uuid_bswap() takes a pointer to the QemuUUID to
be byte-swapped. This means it can't be used when the UUID
to be swapped is in a packed member of a struct. It's also
out of line with the general bswap*() functions we provide
in bswap.h, which take the value to be swapped and return i
This patchset fixes the remaining clang warnings in the block/ code
about taking the address of a packed struct member, which are all
in block/vpc and block/vdi code handling UUIDs. Mostly I fix
these by copying the unaligned field to/from a local variable.
In the case of qemu_uuid_bswap() I opted
Taking the address of a field in a packed struct is a bad idea, because
it might not be actually aligned enough for that pointer type (and
thus cause a crash on dereference on some host architectures). Newer
versions of clang warn about this.
Instead of passing UUID related functions the address o
Taking the address of a field in a packed struct is a bad idea, because
it might not be actually aligned enough for that pointer type (and
thus cause a crash on dereference on some host architectures). Newer
versions of clang warn about this. Avoid the bug by generating the
UUID into a local variab
On Fri 07 Dec 2018 05:13:49 PM CET, Vladimir Sementsov-Ogievskiy wrote:
> Rename qcrypto_block_*crypt_helper to qcrypto_cipher_*crypt_helper, as
You forgot to update the new function names in the commit message.
> -int qcrypto_block_decrypt_helper(QCryptoCipher *cipher,
> -int qcrypto_block_encry
On Fri 07 Dec 2018 05:13:50 PM CET, Vladimir Sementsov-Ogievskiy wrote:
> Introduce QCryptoBlock-based functions and use them where possible.
> This is needed to implement thread-safe encrypt/decrypt operations.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> Reviewed-by: Daniel P. Berrangé
Re
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 07 December 2018 15:58
> To: Paul Durrant
> Cc: qemu-de...@nongnu.org; qemu-block@nongnu.org; xen-
> de...@lists.xenproject.org; Kevin Wolf ; Max Reitz
> ; Stefano Stabellini
> Subject: Re: [PATCH v2 05
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 07 December 2018 15:26
> To: Paul Durrant
> Cc: qemu-de...@nongnu.org; qemu-block@nongnu.org; xen-
> de...@lists.xenproject.org; Kevin Wolf ; Max Reitz
> ; Stefano Stabellini
> Subject: Re: [PATCH v2 03
32 matches
Mail list logo
