Eric Blake writes:
> On 11/21/19 1:46 PM, Markus Armbruster wrote:
>
The '*' is redundant in this form.
Can anyone think of reasons for keeping it anyway? Against?
>>>
>>> Is there ever a reason to allow an optional member but without a
>>> 'default' value? Or can we just
On 11/21/19 1:46 PM, Markus Armbruster wrote:
The '*' is redundant in this form.
Can anyone think of reasons for keeping it anyway? Against?
Is there ever a reason to allow an optional member but without a
'default' value? Or can we just blindly state that if 'default' is
not present, that
Eric Blake writes:
> On 11/21/19 9:07 AM, Markus Armbruster wrote:
>> Max Reitz writes:
>>
>>> With this change, it is possible to give default values for struct
>>> members, as follows:
>>>
>>>What you had to do so far:
>>>
>>> # @member: Some description, defaults to 42.
>>> {
On 21.11.19 15:33, Kevin Wolf wrote:
> Am 21.11.2019 um 13:21 hat Max Reitz geschrieben:
>> On 21.11.19 12:34, Kevin Wolf wrote:
>>> Am 21.11.2019 um 09:59 hat Max Reitz geschrieben:
On 20.11.19 19:44, Kevin Wolf wrote:
> When extending the size of an image that has a backing file larger
On 11/21/19 9:07 AM, Markus Armbruster wrote:
Max Reitz writes:
With this change, it is possible to give default values for struct
members, as follows:
What you had to do so far:
# @member: Some description, defaults to 42.
{ 'struct': 'Foo',
'data': { '*member': 'int' }
Markus Armbruster writes:
> Max Reitz writes:
>
>> On 13.09.19 13:49, Max Reitz wrote:
>>> Another gentle ping.
>>
>> And another.
>
> Conflicts with the refactoring merged in commit 69717d0f890. Please
> accept my apologies for the inconvenience caused by the excessive delay.
>
> I'll try to
Max Reitz writes:
> Optional discriminators are fine, as long as there is a default value.
>
> Signed-off-by: Max Reitz
> ---
> scripts/qapi/common.py | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/qapi/common.py b/scripts/qapi/common.py
>
Max Reitz writes:
> With this change, it is possible to give default values for struct
> members, as follows:
>
> What you had to do so far:
>
> # @member: Some description, defaults to 42.
> { 'struct': 'Foo',
> 'data': { '*member': 'int' } }
>
> What you can do now:
>
> {
Am 14.11.2019 um 18:25 hat Alexander Popov geschrieben:
> The commit a718978ed58a from July 2015 introduced the assertion which
> implies that the size of successful DMA transfers handled in ide_dma_cb()
> should be multiple of 512 (the size of a sector). But guest systems can
> initiate DMA
Am 21.11.2019 um 13:21 hat Max Reitz geschrieben:
> On 21.11.19 12:34, Kevin Wolf wrote:
> > Am 21.11.2019 um 09:59 hat Max Reitz geschrieben:
> >> On 20.11.19 19:44, Kevin Wolf wrote:
> >>> When extending the size of an image that has a backing file larger than
> >>> its old size, make sure that
On Wed, Nov 20, 2019 at 07:44:55PM +0100, Kevin Wolf wrote:
> See patch 2 for the description of the bug fixed.
>
> v2:
> - Switched order of bs->total_sectors update and zero write [Vladimir]
> - Fixed coding style [Vladimir]
> - Changed the commit message to contain what was in the cover letter
bdrv_try_set_aio_context() requires that the old context is held, and
the new context is not held. Fix all the occurrences where it's not
done this way.
Suggested-by: Max Reitz
Signed-off-by: Sergio Lopez
---
blockdev.c | 67 ++
1 file
Issuing a blockdev-backup from qmp_blockdev_backup takes a slightly
different path than when it's issued from a transaction. In the code,
this is manifested as some redundancy between do_blockdev_backup() and
blockdev_backup_prepare().
This change unifies both paths, merging do_blockdev_backup()
Issuing a drive-backup from qmp_drive_backup takes a slightly
different path than when it's issued from a transaction. In the code,
this is manifested as some redundancy between do_drive_backup() and
drive_backup_prepare().
This change unifies both paths, merging do_drive_backup() and
qmp_drive_backup now creates and starts a transactions, which implies
that the job will transition to pause and running twice. Fix test 141
to be aware of this change.
Signed-off-by: Sergio Lopez
---
tests/qemu-iotests/141.out | 2 ++
1 file changed, 2 insertions(+)
diff --git
do_drive_backup() acquires the AioContext lock of the corresponding
BlockDriverState. This is not a problem when it's called from
qmp_drive_backup(), but drive_backup_prepare() also acquires the lock
before calling it. The same things happens with do_blockdev_backup()
and
Fix a couple of minor coding style issues in drive_backup_prepare.
Signed-off-by: Sergio Lopez
---
blockdev.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/blockdev.c b/blockdev.c
index 8e029e9c01..553e315972 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -3620,7
On Wed 20 Nov 2019 07:44:59 PM CET, Kevin Wolf wrote:
> run_job() accepts a wait parameter for a timeout, but it doesn't
> actually use it. The only thing that is missing is passing it to
> events_wait(), so do that now.
>
> Signed-off-by: Kevin Wolf
> Reviewed-by: Eric Blake
> Reviewed-by:
On Wed 20 Nov 2019 07:44:58 PM CET, Kevin Wolf wrote:
> Add a function that runs qemu-io and logs the output with the
> appropriate filters applied.
>
> Signed-off-by: Kevin Wolf
> Reviewed-by: Eric Blake
> Reviewed-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Alberto Garcia
Berto
On Wed 20 Nov 2019 07:45:00 PM CET, Kevin Wolf wrote:
> Automatically complete jobs that have a 'ready' state and need an
> explicit job-complete. Without this, run_job() would hang for such
> jobs.
>
> Signed-off-by: Kevin Wolf
> Reviewed-by: Eric Blake
> Reviewed-by: Vladimir
21.11.2019 14:39, Kevin Wolf wrote:
> Am 21.11.2019 um 11:30 hat Vladimir Sementsov-Ogievskiy geschrieben:
>> 21.11.2019 13:28, Vladimir Sementsov-Ogievskiy wrote:
>>> 20.11.2019 21:45, Kevin Wolf wrote:
Signed-off-by: Kevin Wolf
>>>
>>> Hmm, allocating 7G will break tests on small disks, for
On 21.11.19 12:34, Kevin Wolf wrote:
> Am 21.11.2019 um 09:59 hat Max Reitz geschrieben:
>> On 20.11.19 19:44, Kevin Wolf wrote:
>>> When extending the size of an image that has a backing file larger than
>>> its old size, make sure that the backing file data doesn't become
>>> visible in the
On Tue, Nov 12, 2019 at 03:25:06PM +, Beata Michalska wrote:
> Hi Klaus,
>
> On Tue, 15 Oct 2019 at 11:55, Klaus Jensen wrote:
> > @@ -341,19 +344,18 @@ static uint16_t nvme_dma_write_prp(NvmeCtrl *n,
> > uint8_t *ptr, uint32_t len,
> Any reason why the nvme_dma_write_prp is missing the
Am 21.11.2019 um 11:30 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 21.11.2019 13:28, Vladimir Sementsov-Ogievskiy wrote:
> > 20.11.2019 21:45, Kevin Wolf wrote:
> >> Signed-off-by: Kevin Wolf
> >
> > Hmm, allocating 7G will break tests on small disks, for example,
> > on my 2G tmpfs.
> >
> >
Am 21.11.2019 um 09:59 hat Max Reitz geschrieben:
> On 20.11.19 19:44, Kevin Wolf wrote:
> > When extending the size of an image that has a backing file larger than
> > its old size, make sure that the backing file data doesn't become
> > visible in the guest, but the added area is properly zeroed
Am 20.11.2019 um 22:15 hat Eric Blake geschrieben:
> On 11/20/19 12:44 PM, Kevin Wolf wrote:
> > When extending the size of an image that has a backing file larger than
> > its old size, make sure that the backing file data doesn't become
> > visible in the guest, but the added area is properly
Am 21.11.2019 um 11:32 hat Stefan Hajnoczi geschrieben:
> On Wed, Nov 06, 2019 at 03:58:00PM +0100, Kevin Wolf wrote:
> > Am 06.11.2019 um 15:37 hat Max Reitz geschrieben:
> > > On 17.10.19 15:01, Kevin Wolf wrote:
> > > The only thing I don’t like is the name, but that’s what is for.
> > > :-)
>
On Wed, Nov 06, 2019 at 03:58:00PM +0100, Kevin Wolf wrote:
> Am 06.11.2019 um 15:37 hat Max Reitz geschrieben:
> > On 17.10.19 15:01, Kevin Wolf wrote:
> > The only thing I don’t like is the name, but that’s what is for.
> > :-)
>
> I'm open for suggestions, but I thought 'qsd' was a bit too
21.11.2019 13:28, Vladimir Sementsov-Ogievskiy wrote:
> 20.11.2019 21:45, Kevin Wolf wrote:
>> Signed-off-by: Kevin Wolf
>
> Hmm, allocating 7G will break tests on small disks, for example,
> on my 2G tmpfs.
>
> So, we probably should
> detect "+qemu-img: Failed to resize underlying file: Could
20.11.2019 21:45, Kevin Wolf wrote:
> Signed-off-by: Kevin Wolf
Hmm, allocating 7G will break tests on small disks, for example,
on my 2G tmpfs.
So, we probably should
detect "+qemu-img: Failed to resize underlying file: Could not write zeros for
preallocation: No space left on device"
errors
20.11.2019 21:45, Kevin Wolf wrote:
> Signed-off-by: Kevin Wolf
Reviewed-by: Vladimir Sementsov-Ogievskiy
--
Best regards,
Vladimir
21.11.2019 11:59, Max Reitz wrote:
> On 20.11.19 19:44, Kevin Wolf wrote:
>> When extending the size of an image that has a backing file larger than
>> its old size, make sure that the backing file data doesn't become
>> visible in the guest, but the added area is properly zeroed out.
>>
>>
21.11.2019 0:27, Eric Blake wrote:
> On 11/20/19 12:45 PM, Kevin Wolf wrote:
>> Signed-off-by: Kevin Wolf
>> ---
>> tests/qemu-iotests/274 | 141 +
>> tests/qemu-iotests/274.out | 227 ++
>> tests/qemu-iotests/group | 1 +
>>
On 20.11.19 19:44, Kevin Wolf wrote:
> When extending the size of an image that has a backing file larger than
> its old size, make sure that the backing file data doesn't become
> visible in the guest, but the added area is properly zeroed out.
>
> Consider the following scenario where the
On 20.11.19 16:58, Vladimir Sementsov-Ogievskiy wrote:
> 20.11.2019 18:18, Alberto Garcia wrote:
>> On Wed 20 Nov 2019 01:27:53 PM CET, Vladimir Semeeausntsov-Ogievskiy wrote:
>>
>>> 3. Also, the latter way is inconsistent with discard. Discarded
>>> regions returns zeroes, not clusters from
35 matches
Mail list logo
