On 09/04/2014 10:34 AM, Daniel P. Berrange wrote:
On Thu, Sep 04, 2014 at 04:19:17PM +0200, Benoît Canet wrote:
The Wednesday 03 Sep 2014 à 17:44:17 (+0100), Stefan Hajnoczi wrote :
Hi,
QEMU offers both NBD client and server functionality. The NBD protocol
runs unencrypted, which is a
On 06/08/2016 02:21 AM, Rudy Zhang wrote:
> Add new function about block backup, it supports the drive-backup function
> in qemu, it supports three modes: full, top, incremental.
>
Cheers Rudy!
I assume you've CC'd me as I authored a lot of the incremental backup
infrastructure in QEMU. I'm
On 03/25/2016 05:34 AM, Maxim Nestratov wrote:
> 23.03.2016 17:27, John Snow пишет:
>>
>> On 03/23/2016 06:36 AM, Kashyap Chamarthy wrote:
>>> On Mon, Mar 21, 2016 at 01:18:19PM +0300, Maxim Nestratov wrote:
>>>> Hi all,
>>>>
>>>> It
ckdev-backup' command, which seems similar in
> operation to 'drive-backup', but differs subtly.
>
> Looking at qmp-commands.hx, I learn that 'blockdev-backup' accepts
> target ID; while 'drive-backup' accept target drive name, otherwise,
> their operation look almost identical, and b
On 10/06/2016 10:25 AM, Eric Blake wrote:
On 10/06/2016 06:34 AM, Peter Krempa wrote:
Currently libvirt block APIs (& consequently higher-level applications
like Nova which use these APIs) rely on polling for job completion via
libvirt is _not_ polling the data. Libvirt relies on the
CC: Daniel Erez
CC: Yaniv Dary
CC: Allon Mureinik
full thread:
https://www.redhat.com/archives/libvir-list/2018-June/msg01066.html
On 06/13/2018 12:42 PM, Eric Blake wrote:
> I'm offline the rest of this week, but wanted to post the
> progress I've made on patches towards the Incremental
On 04/11/2018 09:56 AM, Eric Blake wrote:
> On 04/03/2018 07:01 AM, Nikolay Shirokovskiy wrote:
>> Hi, all.
>>
>>
>>
On 04/03/2018 08:01 AM, Nikolay Shirokovskiy wrote:
> Hi, all.
>
>
>
> This is another RFC on pull backup
On 04/12/2018 04:58 AM, Nikolay Shirokovskiy wrote:
> On 11.04.2018 19:32, Eric Blake wrote:
>> On 04/03/2018 07:01 AM, Nikolay Shirokovskiy wrote:
[snip]
>>
>> I'm trying to figure out how BlockCheckpoint and BlockSnapshots relate.
>> Maybe it will be more clear when I read the
On 04/13/2018 05:16 AM, Nikolay Shirokovskiy wrote:
>
>
> On 13.04.2018 00:16, John Snow wrote:
>>
>>
>> On 04/03/2018 08:01 AM, Nikolay Shir
On 04/13/2018 08:01 AM, Vladimir Sementsov-Ogievskiy wrote:
>>> 1. It looks unsafe to use nbd server + backup(sync=none) on same node,
>>> synchronization is needed, like in block/replication, which uses
>>> backup_wait_for_overlapping_requests, backup_cow_request_begin,
>>>
On 04/12/2018 10:08 AM, Vladimir Sementsov-Ogievskiy wrote:
>
> I propose, not to say that bitmap represents a checkpoint. It is simpler
> to say (and it reflects the reality) that bitmap is a difference between
> two consecutive checkpoints. And we can say, that active state is some
> kind of
On 04/12/2018 08:57 AM, Nikolay Shirokovskiy wrote:
>
>
> On 12.04.2018 07:14, John Snow wrote:
>>
>>
>> On 04/11/2018 12:32 PM, Eric Blake wrote:
>>> On 04/03/2018 07:01 AM, Niko
On 04/11/2018 12:32 PM, Eric Blake wrote:
> On 04/03/2018 07:01 AM, Nikolay Shirokovskiy wrote:
>> Hi, all.
>>
>>
>>
On 04/20/2018 08:22 AM, Nikolay Shirokovskiy wrote:
>
>
> On 19.04.2018 20:28, John Snow wrote:
>>
>>
>> On 04/16/2018 06:20 AM, Vladimir Sementsov-Ogievskiy wrote:
>>>
>>> So my point is: if we are going to implement something complicated,
>>
On 04/12/2018 08:26 AM, Vladimir Sementsov-Ogievskiy wrote:
> 1. It looks unsafe to use nbd server + backup(sync=none) on same node,
> synchronization is needed, like in block/replication, which uses
> backup_wait_for_overlapping_requests, backup_cow_request_begin,
> backup_cow_request_end. We
On 04/13/2018 05:47 AM, Nikolay Shirokovskiy wrote:
>>> However as we use chain of disabled bitmaps with one active bitmap on tip
>>> of the chain and qemu does not track their order we need to do it in
>>> libvirt.
>>>
>> Well, you seem to be tracking it in *qemu*, by using the name field.
>>
On 04/12/2018 10:08 AM, Vladimir Sementsov-Ogievskiy wrote:
> It's not easier, as we'll have to implement either separate of bitmaps
> concept of checkpoints, which will be based on bitmaps, and we'll have
> to negotiate and implement storing these objects to qcow2 and migrate
> them. Or we'll
On 04/16/2018 06:20 AM, Vladimir Sementsov-Ogievskiy wrote:
>
> So my point is: if we are going to implement something complicated,
> let's implement entirely what we want, not a semi-solution. Otherwise,
> implement a minimal and simple thing, to just make it all work (my
> current solution).
On 04/23/2018 06:38 AM, Nikolay Shirokovskiy wrote:
>
>
> On 21.04.2018 00:26, Eric Blake wrote:
>> On 04/20/2018 01:24 PM, John Snow wrote:
>>
>>>>> Why is option 3 unworkable, exactly?:
>>>>>
>>>>> (3) Checkpoints exist as
On 04/23/2018 05:31 AM, Vladimir Sementsov-Ogievskiy wrote:
> 21.04.2018 00:26, Eric Blake wrote:
>> On 04/20/2018 01:24 PM, John Snow wrote:
>>
>>>>> Why is option 3 unworkable, exactly?:
>>>>>
>>>>> (3) Checkpoints exist as struc
On 04/25/2018 03:19 AM, Nikolay Shirokovskiy wrote:
>
>
> On 24.04.2018 23:02, John Snow wrote:
>>
>>
>> On 04/23/2018 06:38 AM, Nikolay Shirokovskiy wrote:
>>>
>>>
>>> On 21.04.2018 00:26, Eric Blake wrote:
>>>> On 04/20/2018
On 10/25/2018 03:20 PM, Eric Blake wrote:
> The following is the latest version of my API proposal for
> incremental backups, and matches the demo I will be presenting
> as part of my KVM Forum 2018 talk tomorrow afternoon:
>
On 2/18/19 8:57 AM, Vladimir Sementsov-Ogievskiy wrote:
> 14.02.2019 2:23, John Snow wrote:
>> "Frozen" was a good description a long time ago, but it isn't adequate now.
>> Rename the frozen predicate to has_successor to make the semantics of the
>> predicat
On 2/18/19 11:39 AM, Vladimir Sementsov-Ogievskiy wrote:
> 14.02.2019 2:23, John Snow wrote:
>> Currently, enabled means something like "the status of the bitmap
>> is ACTIVE." After this patch, it should mean exclusively: "This
>> bitmap is recording g
On 2/18/19 12:39 PM, Vladimir Sementsov-Ogievskiy wrote:
> 14.02.2019 2:23, John Snow wrote:
>> Simply move the big status enum comment block to above the status
>> function, and document it as being deprecated. The whole confusing
>> block can get deleted in three releas
On 2/25/19 2:01 AM, Vladimir Sementsov-Ogievskiy wrote:
> 23.02.2019 3:06, John Snow wrote:
>> "Frozen" was a good description a long time ago, but it isn't adequate now.
>> Rename the frozen predicate to has_successor to make the semantics of the
>> predicat
On 2/23/19 5:06 PM, Eric Blake wrote:
> On 2/22/19 6:06 PM, John Snow wrote:
>> This adds a simple test that ensures the busy bit works for push backups,
>> as well as doubling as bonus test for incremental backups that get
>> interrupted
>> by EIO errors.
>
On 2/25/19 7:03 AM, Vladimir Sementsov-Ogievskiy wrote:
> 23.02.2019 3:06, John Snow wrote:
>> These mean the same thing now. Unify them and rename the merged call
>> bdrv_dirty_bitmap_busy to indicate semantically what we are describing,
>> as well as help disambiguate fro
On 2/22/19 7:06 PM, John Snow wrote:
> The current internal meanings of "locked", "user_locked",
> "qmp_locked", "frozen", "enabled", and "disabled" are all
> a little muddled.
>
> Deprecate the @status field in
On 2/18/19 11:52 AM, Vladimir Sementsov-Ogievskiy wrote:
> 14.02.2019 2:23, John Snow wrote:
>> Instead of implying a locked status, make it explicit.
>
> locked interferes with bitmap mutex, so may be better "qmp_locked state", but
> not sure.
>
I agree that
On 2/19/19 5:17 AM, Vladimir Sementsov-Ogievskiy wrote:
> 19.02.2019 1:32, John Snow wrote:
>>
>>
>> On 2/18/19 8:57 AM, Vladimir Sementsov-Ogievskiy wrote:
>>> 14.02.2019 2:23, John Snow wrote:
>>>> "Frozen" was a good description a l
This adds a simple test that ensures the busy bit works for push backups,
as well as doubling as bonus test for incremental backups that get interrupted
by EIO errors.
Recording bit tests are already handled sufficiently by 236.
Signed-off-by: John Snow
---
tests/qemu-iotests/124 | 110
These mean the same thing now. Unify them and rename the merged call
bdrv_dirty_bitmap_busy to indicate semantically what we are describing,
as well as help disambiguate from the various _locked and _unlocked
versions of bitmap helpers that refer to mutex locks.
Signed-off-by: John Snow
Simply move the big status enum comment block to above the status
function, and document it as being deprecated. The whole confusing
block can get deleted in three releases time.
Signed-off-by: John Snow
---
block/dirty-bitmap.c | 36 +++-
1 file changed, 19
nt helpers that are addressed in
forthcoming patches.
Signed-off-by: John Snow
---
block/dirty-bitmap.c | 32 +---
include/block/dirty-bitmap.h | 2 +-
migration/block-dirty-bitmap.c | 2 +-
3 files changed, 19 insertions(+), 17 deletions(-)
diff --git a/b
dy check user_locked separately.
Signed-off-by: John Snow
---
block/dirty-bitmap.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/block/dirty-bitmap.c b/block/dirty-bitmap.c
index 9ea5738420..976831e765 100644
--- a/block/dirty-bitmap.c
+++ b/block/dirty-bitmap.c
@@ -
.
The problem is that both "Frozen" and "Locked" mean nearly the same thing,
and that both of them do not intuit whether they are recording guest writes
or not.
This patch deprecates that status field and introduces two orthogonal
properties instead to replace it.
Sign
Check that the bitmap is not in use prior to it checking if it is
not enabled/recording guest writes. The bitmap being busy was likely
at the behest of the user, so this error has a greater chance of being
understood by the user.
Signed-off-by: John Snow
---
nbd/server.c | 10 +-
1 file
message adjustment
007: BdrvDirtyBitmap struct comment adjustments
Comment change to create_successor (lock --> busy)
Incidental changes from 004's changes
008: Grammar fix (Eric)
009: New, trivial, unrelated fix tagging along.
010: iotest 124 added.
John Snow (10):
block/dirty-bitmap: add recordin
they have to be.
Modify these internal APIs to drop this assertion.
Signed-off-by: John Snow
---
block/dirty-bitmap.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/block/dirty-bitmap.c b/block/dirty-bitmap.c
index aa3f86bb73..9ea5738420 100644
--- a/block/dirty-bitmap.c
+++ b/block/dirt
This field isn't present anymore.
Signed-off-by: John Snow
---
blockdev.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/blockdev.c b/blockdev.c
index 1aaadb6128..cbce44877d 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -1255,7 +1255,6 @@ out_aio_context:
* @node: The name of the BDS node
Instead of implying a user_locked/busy status, make it explicit.
Now, bitmaps in use by migration, NBD or backup operations
are all treated the same way with the same code paths.
Signed-off-by: John Snow
Reviewed-by: Eric Blake
---
block/dirty-bitmap.c | 11 ++-
1 file changed, 6
.
The problem is that both "Frozen" and "Locked" mean nearly the same thing,
and that both of them do not intuit whether they are recording guest writes
or not.
This patch deprecates that status field and introduces two orthogonal
properties instead to replace it.
Sign
t will
let me pause an incremental backup so I can test race-free.
Maybe for V3, sorry.
John Snow (6):
block/dirty-bitmap: add recording and busy properties
block/dirty-bitmaps: rename frozen predicate helper
block/dirty-bitmap: change semantics of enabled predicate
block/dirty-bitmap: e
qmp_locked function for this instead, which
presently also checks for has_successor.
Signed-off-by: John Snow
---
block/dirty-bitmap.c | 32 +---
include/block/dirty-bitmap.h | 2 +-
migration/block-dirty-bitmap.c | 2 +-
3 files changed, 19 insertions(+), 17
t the
literal bit, and already checked for user_locked beforehand.
7. block_dirty_bitmap_disable_prepare ditto as above.
8. init_dirty_bitmap_migration also already checks user_locked,
so this call can be a simple enabled/disabled check.
Signed-off-by: John Snow
Reviewed-by: Eric Bla
Simply move the big status enum comment block to above the status
function, and document it as being deprecated. The whole confusing
block can get deleted in three releases time.
Signed-off-by: John Snow
---
block/dirty-bitmap.c | 36 +++-
1 file changed, 19
These mean the same thing now. Unify them and rename the merged call
bdrv_dirty_bitmap_busy to indicate semantically what we are describing,
as well as help disambiguate from the various _locked and _unlocked
versions of bitmap helpers that refer to mutex locks.
Signed-off-by: John Snow
Reviewed
Instead of implying a locked status, make it explicit.
Now, bitmaps in use by migration, NBD or backup operations
are all treated the same way with the same code paths.
Signed-off-by: John Snow
Reviewed-by: Eric Blake
---
block/dirty-bitmap.c | 9 +
1 file changed, 5 insertions(+), 4
On 2/18/19 12:27 PM, Vladimir Sementsov-Ogievskiy wrote:
> 14.02.2019 2:23, John Snow wrote:
>> These mean the same thing now. Unify them and rename the merged call
>> bdrv_dirty_bitmap_busy to indicate semantically what we are describing,
>> as well as help disambig
On 8/15/19 6:49 AM, Kevin Wolf wrote:
> Am 14.08.2019 um 21:27 hat John Snow geschrieben:
>>
>>
>> On 8/14/19 6:07 AM, Vladimir Sementsov-Ogievskiy wrote:
>>> To get rid of implicit filters related workarounds in future let's
>>> deprecate them now.
&g
On 8/15/19 12:48 PM, Kevin Wolf wrote:
> Am 15.08.2019 um 18:07 hat John Snow geschrieben:
>> On 8/15/19 6:49 AM, Kevin Wolf wrote:
>>> Am 14.08.2019 um 21:27 hat John Snow geschrieben:
>>>>
>>>> This might be OK to do right away, though.
>>>>
On 8/15/19 10:16 AM, Markus Armbruster wrote:
> John Snow writes:
>
>> On 8/14/19 6:07 AM, Vladimir Sementsov-Ogievskiy wrote:
>>> To get rid of implicit filters related workarounds in future let's
>>> deprecate them now.
>>>
>>
On 8/15/19 3:44 AM, Peter Krempa wrote:
> On Wed, Aug 14, 2019 at 15:22:15 -0400, John Snow wrote:
>>
>>
>> On 8/14/19 6:07 AM, Vladimir Sementsov-Ogievskiy wrote:
>>> It's hard and not necessary to maintain outdated versions of these
>>> commands.
&g
On 8/14/19 6:07 AM, Vladimir Sementsov-Ogievskiy wrote:
> It's hard and not necessary to maintain outdated versions of these
> commands.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> qemu-deprecated.texi | 4
> qapi/block-core.json | 4
> qapi/transaction.json | 2 +-
On 8/14/19 6:07 AM, Vladimir Sementsov-Ogievskiy wrote:
> To get rid of implicit filters related workarounds in future let's
> deprecate them now.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> qemu-deprecated.texi | 7 +++
> qapi/block-core.json | 6 --
>
On 8/21/19 10:21 AM, Vladimir Sementsov-Ogievskiy wrote:
> [CC Nikolay]
>
> 21.08.2019 1:25, John Snow wrote:
>> Hi, downstream here at Red Hat I've been fielding some questions about
>> the usability and feature readiness of Bitmaps (and related features) in
>>
Hi, downstream here at Red Hat I've been fielding some questions about
the usability and feature readiness of Bitmaps (and related features) in
QEMU.
Here are some questions I answered internally that I am copying to the
list for two reasons:
(1) To make sure my answers are actually correct, and
On 8/23/19 5:22 AM, Vladimir Sementsov-Ogievskiy wrote:
> 14.08.2019 13:07, Vladimir Sementsov-Ogievskiy wrote:
>> To get rid of implicit filters related workarounds in future let's
>> deprecate them now.
>
> Interesting, could we deprecate implicit filter without deprecation of
> unnecessity
On 8/30/19 6:07 AM, Christophe de Dinechin wrote:
>
> John Snow writes:
>
>> On 8/29/19 12:45 PM, Christophe de Dinechin wrote:
>>>
> [...]
>
>>> Sorry for catching up late, this mail thread happened during my PTO.
>>>
>>> I remem
On 9/3/19 3:02 PM, Eric Blake wrote:
> [adding libvirt list]
>
> On 9/3/19 1:50 PM, John Snow wrote:
>>
>>
>> On 9/3/19 10:56 AM, Eric Blake wrote:
>>> Mention the preferred URI form, especially since NBD is trying to
>>> standardize that form:
(Peter: search for "pkrempa" down below.)
On 8/28/19 5:20 AM, Vladimir Sementsov-Ogievskiy wrote:
> 27.08.2019 23:12, John Snow wrote:
>>
>>
>> On 8/23/19 5:22 AM, Vladimir Sementsov-Ogievskiy wrote:
>>> 14.08.2019 13:07, Vladimir Sementsov-Ogievskiy wr
On 8/29/19 11:59 AM, Christophe de Dinechin wrote:
>
> John Snow writes:
> [...]
>>
>> This might be OK to do right away, though.
>>
>> I asked Markus this not too long ago; do we want to amend the QAPI
>> schema specification to allow co
On 8/29/19 11:17 AM, Vladimir Sementsov-Ogievskiy wrote:
> Aren't you going to deprecate and drop it at some moment?
Libvirt's going to keep supporting older versions of QEMU in perpetuity.
Apparently, there are still some barriers (SD cards?) to using only
blockdev API for new versions, too:
On 8/29/19 12:45 PM, Christophe de Dinechin wrote:
>
> Markus Armbruster writes:
>
>> Peter Krempa writes:
>>
> [...]
>>> From my experience users report non-fatal messages mostly only if it is
>>> spamming the system log. One of instances are very unlikely to be
>>> noticed.
>>>
>>> In my
On 7/17/19 1:39 PM, John Snow wrote:
> From: Vladimir Sementsov-Ogievskiy
>
> Let's add a possibility to query dirty-bitmaps not only on root nodes.
> It is useful when dealing both with snapshots and incremental backups.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
&g
From: Vladimir Sementsov-Ogievskiy
Let's add a possibility to query dirty-bitmaps not only on root nodes.
It is useful when dealing both with snapshots and incremental backups.
Signed-off-by: Vladimir Sementsov-Ogievskiy
[Added deprecation information. --js]
Signed-off-by: John Snow
On 7/17/19 3:13 PM, Eric Blake wrote:
> On 7/17/19 12:39 PM, John Snow wrote:
>> From: Vladimir Sementsov-Ogievskiy
>>
>> Let's add a possibility to query dirty-bitmaps not only on root nodes.
>> It is useful when dealing both with snapshots and incrementa
On 7/17/19 4:05 PM, Eric Blake wrote:
> On 7/17/19 2:21 PM, John Snow wrote:
>>>
>>> Is this worth squeezing into 4.1, to start the deprecation clock one
>>> cycle earlier (on the grounds that the missing information for anonymous
>>> nodes is a bug)?
On 7/17/19 1:39 PM, John Snow wrote:
> From: Vladimir Sementsov-Ogievskiy
>
> Let's add a possibility to query dirty-bitmaps not only on root nodes.
> It is useful when dealing both with snapshots and incremental backups.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
&g
On 7/18/19 6:20 AM, no-re...@patchew.org wrote:
> PASS 17 test-bdrv-drain /bdrv-drain/graph-change/drain_all
> =
> ==10263==ERROR: AddressSanitizer: heap-use-after-free on address
> 0x6122c1f0 at pc 0x555fd5bd7cb6 bp
-by: John Snow
---
block/qapi.c | 5 +
qapi/block-core.json | 14 +-
qemu-deprecated.texi | 12
3 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/block/qapi.c b/block/qapi.c
index 917435f022..15f1030264 100644
--- a/block/qapi.c
+++ b/block/qapi.c
On 7/24/19 12:47 AM, Markus Armbruster wrote:
> John Snow writes:
>
>> From: Vladimir Sementsov-Ogievskiy
>>
>> Let's add a possibility to query dirty-bitmaps not only on root nodes.
>> It is useful when dealing both with snapshots and incremental backups.
On 7/25/19 2:06 AM, Markus Armbruster wrote:
> John Snow writes:
>
>> On 7/24/19 12:47 AM, Markus Armbruster wrote:
>>> John Snow writes:
>>>
>>>> From: Vladimir Sementsov-Ogievskiy
>>>>
>>>> Let's add a possibility to
-by: Philippe Mathieu-Daudé
Signed-off-by: John Snow
---
include/sysemu/sysemu.h | 3 +++
bootdevice.c| 55 +
2 files changed, 58 insertions(+)
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 44f18eb739..5bc5c79cbc 100644
From: Sam Eiderman
Fixing tabbing in block related macros.
Signed-off-by: Sam Eiderman
Signed-off-by: Sam Eiderman
Reviewed-by: Karl Heubaum
Reviewed-by: Arbel Moshe
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: John Snow
---
include/hw/block/block.h | 16
hw/ide
It's an old compatibility shim that just delegates to ide-cd or ide-hd.
I'd like to refactor these some day, and getting rid of the super-object
will make that easier.
Either way, we don't need this.
Signed-off-by: John Snow
Reviewed-by: Thomas Huth
Reviewed-by: Markus Armbruster
ACKed
-request
for you to fetch changes up to dc237c45aee52f268369dc6a485c623f1232e1d3:
hd-geo-test: Add tests for lchs override (2019-10-31 11:47:43 -0400)
Pull request
John
Reviewed-by: Arbel Moshe
Signed-off-by: Sam Eiderman
Signed-off-by: Sam Eiderman
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
Signed-off-by: John Snow
---
hw/block/virtio-blk.c | 6 ++
hw/ide/qdev.c | 5 +
hw/scsi/scsi-disk.c | 12
3
n
Signed-off-by: Sam Eiderman
Tested-by: Philippe Mathieu-Daudé
Signed-off-by: John Snow
---
include/sysemu/sysemu.h | 1 +
bootdevice.c| 31 +++
hw/nvram/fw_cfg.c | 14 +++---
3 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/inc
.
Reviewed-by: Karl Heubaum
Reviewed-by: Arbel Moshe
Signed-off-by: Sam Eiderman
Signed-off-by: Sam Eiderman
Signed-off-by: John Snow
---
tests/hd-geo-test.c| 551 +
tests/Makefile.include | 2 +-
2 files changed, 552 insertions(+), 1 deletion(-)
diff
On 10/31/19 11:02 AM, Peter Maydell wrote:
> On Thu, 31 Oct 2019 at 10:59, John Snow wrote:
>>
>> The following changes since commit 68d8ef4ec540682c3538d4963e836e43a211dd17:
>>
>> Merge remote-tracking branch
>> 'remotes/stsquad/tags/pull-tcg-plugins-2
* virtio-blk-pci
In future commits we will use the provided LCHS and pass it to the BIOS
through fw_cfg to be supplied using INT13 routines.
Reviewed-by: Karl Heubaum
Reviewed-by: Arbel Moshe
Signed-off-by: Sam Eiderman
Signed-off-by: Sam Eiderman
Reviewed-by: Philippe Mathieu-Da
-off-by: John Snow
---
include/hw/scsi/scsi.h | 1 +
hw/scsi/scsi-bus.c | 16
2 files changed, 17 insertions(+)
diff --git a/include/hw/scsi/scsi.h b/include/hw/scsi/scsi.h
index d77a92361b..332ef602f4 100644
--- a/include/hw/scsi/scsi.h
+++ b/include/hw/scsi/scsi.h
@@ -59,6
-Daudé
Signed-off-by: Sam Eiderman
Signed-off-by: Sam Eiderman
Tested-by: Philippe Mathieu-Daudé
Signed-off-by: John Snow
---
bootdevice.c | 61 +---
1 file changed, 34 insertions(+), 27 deletions(-)
diff --git a/bootdevice.c b/bootdevice.c
index
On 12/5/19 3:09 PM, Eric Blake wrote:
> On 12/5/19 1:30 PM, Vladimir Sementsov-Ogievskiy wrote:
>> Here is double bug:
>>
>> First, return error but not set errp. This may lead to:
>> qmp block-dirty-bitmap-remove may report success when actually failed
>>
>> block-dirty-bitmap-remove used in a
On 12/5/19 4:53 PM, Eric Blake wrote:
> On 12/5/19 2:16 PM, John Snow wrote:
>
>>>> Last minute edit: hmm, actually, transaction action introduced in
>>>> 4.2, so crash is not a regression, only broken
>>>> block-dirty-bitmap-remove
>>>&g
This has come up in the past, and I believe we discussed this at KVM
Forum, too:
There have been requests from oVirt (via Nir Soffer) to add some offline
bitmap manipulation functionality. In the past, our stance has generally
been "Use QEMU without an accelerator, and use QMP to manipulate the
On 12/6/19 9:36 AM, Eric Blake wrote:
> [adding in Peter Maydell, as there is now potential talk of other
> 4.2-worthy patches]
>
> On 12/6/19 4:18 AM, Vladimir Sementsov-Ogievskiy wrote:
>> 05.12.2019 23:16, John Snow wrote:
>>>
>>>
>>> On 12/5/19
On 12/6/19 5:37 AM, Vladimir Sementsov-Ogievskiy wrote:
> 06.12.2019 1:37, John Snow wrote:
>> This has come up in the past, and I believe we discussed this at KVM
>> Forum, too:
>>
>> There have been requests from oVirt (via Nir Soffer) to add some offline
>>
On 10/17/19 7:07 AM, Peter Maydell wrote:
> On Mon, 14 Oct 2019 at 20:29, John Snow wrote:
>>
>> The following changes since commit c760cb77e511eb05094df67c1b30029a952efa35:
>>
>> Merge remote-tracking branch
>> 'remotes/dgilbert/tags/pull-migration-20
On 10/15/19 4:44 AM, Kevin Wolf wrote:
> Am 14.10.2019 um 20:10 hat John Snow geschrieben:
>>
>>
>> On 10/11/19 7:18 PM, John Snow wrote:
>>>
>>>
>>> On 10/11/19 5:48 PM, Eric Blake wrote:
>>>> On 10/11/19 4:25 P
qcow2_can_store_new_dirty_bitmap and
qcow2_remove_persistent_dirty_bitmap to coroutine context.
Since we work in coroutines in correct aio context, we don't need
context acquiring in blockdev.c anymore, drop it.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: John Snow
Message-id
From: Vladimir Sementsov-Ogievskiy
Drop meta bitmaps, as they are unused.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: John Snow
Message-id: 20190916141911.5255-2-vsement...@virtuozzo.com
Signed-off-by: John Snow
---
include/block/dirty-bitmap.h | 5
block/dirty-bitmap.c
ore obvious that it's not per-bitmap
lock. Still, for simplicity, leave bdrv_dirty_bitmap_lock/unlock
functions as an external API.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: John Snow
Message-id: 20190916141911.5255-4-vsement...@virtuozzo.com
Signed-off-by: John Snow
---
block/di
drop IN_USE flag
for unchanged bitmaps in the image.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: John Snow
Message-id: 20190927122355.7344-5-vsement...@virtuozzo.com
Signed-off-by: John Snow
---
include/block/dirty-bitmap.h | 1 -
block/dirty-bitmap.c | 12
hb->orig_size.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Max Reitz
Message-Id: <20190806152611.280389-1-vsement...@virtuozzo.com>
[Maintainer edit: Max's suggestions from on-list. --js]
[Maintainer edit: Eric's suggestion for aligned macro. --js]
Signed-off-by: John S
John Snow (2):
MAINTAINERS: Add Vladimir as a reviewer for bitmaps
dirty-bitmaps: remove deprecated autoload parameter
Vladimir Sementsov-Ogievskiy (17):
util/hbitmap: strict hbitmap_reset
block: move bdrv_can_store_new_dirty_bitmap to block/dirty-bitmap.c
block/dirty-bitmap: return int
reopen commit. Reverse
reopen order to fix it.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Acked-by: Max Reitz
Acked-by: John Snow
Message-id: 20190927122355.7344-3-vsement...@virtuozzo.com
Signed-off-by: John Snow
---
block.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions
1 - 100 of 240 matches
Mail list logo
