Am 19.10.2015 um 16:15 hat Alberto Garcia geschrieben:
> On Mon 19 Oct 2015 01:27:45 PM CEST, Kevin Wolf wrote:
> > I've been thinking a bit about the creation and deletion of
> > BlockBackends a bit last week, and honestly it still feels a bit messy
> > (or maybe I just don't fully understand it y
Make use of the QCryptoSecret object to support loading of
encrypted x509 keys. The optional 'passwordid' parameter
to the tls-creds-x509 object type, provides the ID of a
secret object instance that holds the decryption password
for the PEM file.
# echo "123456" > mypasswd.txt
# $QEMU \
-ob
The iSCSI driver currently accepts the CHAP password in plain text
as a block driver property. This change adds a new "passwordid"
property that accepts the ID of a QCryptoSecret instance.
$QEMU \
-object secret,id=sec0,filename=/home/berrange/example.pw \
-drive driver=iscsi,url=iscsi
If connecting to a web server which has authentication
turned on, QEMU gets a 401 as curl has not been configured
with any authentication credentials.
This adds 4 new parameters to the curl block driver
options, username, passwordid, proxyusername and
proxypasswordid.
$QEMU \
-object secret
Currently RBD passwords must be provided on the command line
via
$QEMU -drive file=rbd:pool/image:id=myname:\
key=QVFDVm41aE82SHpGQWhBQXEwTkN2OGp0SmNJY0UrSE9CbE1RMUE=:\
auth_supported=cephx
This is insecure because the key is visible in the OS process
listing.
This adds support for an
There are a variety of places where QEMU needs to have access
to passwords, encryption keys or similar kinds of secrets.
- VNC / SPICE user passwords
- Curl block http / proxy passwords
- RBD auth password
- iSCSI CHAP password
- x509 private key password
- QCow/QCow2 encryption key
QEMU ha
Allow creation of user creatable object types with qemu-img
via a --object command line arg. This will be used to supply
passwords and/or encryption keys to the various block driver
backends via the recently added 'secret' object type.
# echo -n letmein > mypasswd.txt
# qemu-img info --object se
Refuse to open a qcow/qcow2 image with encryption if write
access has been requested. To enable historic data to be
liberated support for reading images is retained, as it
does not pose an unreasonable support burden now that the
new key handling infrastructure is inplace.
Signed-off-by: Daniel P.
On 19/10/2015 17:09, Daniel P. Berrange wrote:
> +
> +switch (secret->format) {
> +case QCRYPTO_SECRET_FORMAT_UTF8:
> +if (!g_utf8_validate(input, strlen(input), NULL)) {
> +error_setg(errp,
> + "Data from secret %s is not valid UTF-8",
> +
Currently qemu-io allows an image filename to be passed on the
command line, but does not have a way to set any options except
the format eg
qemu-io https://127.0.0.1/images/centos7.iso
qemu-io /home/berrange/demo.qcow2
This adds a --source arg (that is mutually exclusive with a
positional file
On 19/10/2015 17:24, Daniel P. Berrange wrote:
> JSON doesn't accept arbitrary 8-bit binary data, so the alternative
> 'base64' is effectively providing binary data facility. Having to
> use base64 for plain passwords is rather tedious though, so allowing
> utf8 is a much more developer friendly
On Mon, Oct 19, 2015 at 05:40:08PM +0200, Paolo Bonzini wrote:
>
>
> On 19/10/2015 17:24, Daniel P. Berrange wrote:
> > JSON doesn't accept arbitrary 8-bit binary data, so the alternative
> > 'base64' is effectively providing binary data facility. Having to
> > use base64 for plain passwords is r
Currently qemu-nbd allows an image filename to be passed on the
command line, but does not have a way to set any options except
the format eg
qemu-nbd https://127.0.0.1/images/centos7.iso
qemu-nbd /home/berrange/demo.qcow2
This adds a --source arg (that is mutually exclusive with a
position
Allow creation of user creatable object types with qemu-io
via a --object command line arg. This will be used to supply
passwords and/or encryption keys to the various block driver
backends via the recently added 'secret' object type.
# echo -n letmein > mypasswd.txt
# qemu-io --object secret,id
On Mon, Oct 19, 2015 at 05:18:56PM +0200, Paolo Bonzini wrote:
>
>
> On 19/10/2015 17:09, Daniel P. Berrange wrote:
> > +
> > +switch (secret->format) {
> > +case QCRYPTO_SECRET_FORMAT_UTF8:
> > +if (!g_utf8_validate(input, strlen(input), NULL)) {
> > +error_setg(errp,
Now that all encryption keys must be provided upfront via
the QCryptoSecret API and associated block driver properties
there is no need for any explicit encryption handling APIs
in the block layer. Encryption can be handled transparently
within the block driver. We only retain an API for querying
w
The QMP monitor code has two helper methods object_add
and qmp_object_del that are called from several places
in the code (QMP, HMP and main emulator startup).
We soon need to use this code from qemu-img, qemu-io
and qemu-nbd too, but don't want those to depend on
the monitor.
To avoid this, move
It has been deprecated as of 2.3, so we can now remove it.
Signed-off-by: Max Reitz
Reviewed-by: Eric Blake
Reviewed-by: Kevin Wolf
---
block/raw-posix.c| 222 ++-
qapi/block-core.json | 9 +--
2 files changed, 9 insertions(+), 222 deletion
This series reworks a lot regarding BlockBackend and media. Basically,
it allows empty BlockBackends, that is BBs without a BDS tree.
Before this series, empty drives are represented by a BlockBackend with
an empty BDS attached to it (a BDS with a NULL driver). However, now we
have BlockBackends,
With the new automatically-recursive implementation of
bdrv_is_inserted() checking by default whether all the children of a BDS
are inserted, we can drop raw's own implementation.
Signed-off-by: Max Reitz
Reviewed-by: Eric Blake
Reviewed-by: Kevin Wolf
Reviewed-by: Alberto Garcia
---
block/ra
Introduce a new QCryptoSecret object class which will be used
for providing passwords and keys to other objects which need
sensitive credentials.
The new object can provide secret values directly as properties,
or indirectly via a file. The latter includes support for file
descriptor passing synta
Tests 071 and 081 test giving references in blockdev-add. It is not
necessary to create a BlockBackend here, so omit it.
While at it, fix up some blockdev-add invocations in the vicinity
(s/raw/$IMGFMT/ in 081, drop the format BDS for blkverify's raw child in
071).
Signed-off-by: Max Reitz
---
blk_is_available() returns true iff the BDS is inserted (which means
blk_bs() is not NULL and bdrv_is_inserted() returns true) and if the
tray of the guest device is closed.
blk_is_inserted() is changed to return true only if blk_bs() is not
NULL.
Signed-off-by: Max Reitz
Reviewed-by: Eric Blake
If the "id" field is missing from the options given to blockdev-add,
just omit the BlockBackend and create the BlockDriverState tree alone.
However, if "id" is missing, "node-name" must be specified; otherwise,
the BDS tree would no longer be accessible.
Many BDS options which are not parsed by b
Make bdrv_is_inserted(), blk_is_inserted(), and the callback
BlockDriver.bdrv_is_inserted() return a bool.
Suggested-by: Eric Blake
Signed-off-by: Max Reitz
Reviewed-by: Eric Blake
Reviewed-by: Alberto Garcia
Reviewed-by: Kevin Wolf
---
block.c| 12 +++-
block
This flag should not be set for the root BDS only, but for any BDS that
is being created while incoming migration is pending, so setting it is
moved from blockdev_init() to bdrv_fill_options().
Signed-off-by: Max Reitz
Reviewed-by: Eric Blake
Reviewed-by: Kevin Wolf
Reviewed-by: Alberto Garcia
Add a 'keyid' parameter that refers to the ID of a
QCryptoSecret instance that provides the encryption key.
eg
$QEMU \
-object secret,id=sec0,filename=/home/berrange/encrypted.pw \
-drive file=/home/berrange/encrypted.qcow,keyid=sec0
Signed-off-by: Daniel P. Berrange
---
block/qcow.c
If bdrv_is_inserted() is called on the top level BDS, it should make
sure all nodes in the BDS tree are actually inserted.
Signed-off-by: Max Reitz
Reviewed-by: Eric Blake
Reviewed-by: Kevin Wolf
---
block.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/block
guest_block_size is a guest device property so it should be moved into
the interface between block layer and guest devices, which is the
BlockBackend.
Signed-off-by: Max Reitz
Reviewed-by: Eric Blake
Reviewed-by: Alberto Garcia
Reviewed-by: Kevin Wolf
---
block.c | 7 ---
Throttle groups are not necessarily referenced by BDSs alone; a later
patch will essentially allow BBs to reference them, too. Make the
ref/unref functions public so that reference can be properly accounted
for.
Their interface is slightly adjusted in that they return and take a
ThrottleState poin
There are several BlockBackend functions which, in theory, cannot fail.
This patch makes them cope with the BlockDriverState pointer being NULL
by making them fall back to some default action like ignoring the value
in setters and returning the default in getters.
Signed-off-by: Max Reitz
Reviewe
Signed-off-by: Max Reitz
---
blockdev.c | 49 +
qapi/block-core.json | 23 +++
qmp-commands.hx | 39 +++
3 files changed, 111 insertions(+)
diff --git a/blockdev.c b/blockdev.c
Only call bdrv_add_key() on the BlockDriverState if it is not NULL.
Signed-off-by: Max Reitz
Reviewed-by: Eric Blake
Reviewed-by: Alberto Garcia
Reviewed-by: Kevin Wolf
---
hw/usb/dev-storage.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git
BlockAcctStats contains statistics about the data transferred from and
to the device; wr_highest_sector does not fit in with the rest.
Furthermore, those statistics are supposed to be specific for a certain
device and not necessarily for a BDS (see the comment above
bdrv_get_stats()); on the other
In order to handle host device passthrough, some guest device models
may call blk_is_inserted() to check whether the medium is inserted on
the host, when checking the guest tray status.
This tray status is inquired by blk_dev_change_media_cb(); because
bdrv_is_inserted() (invoked by blk_is_inserte
And a helper function for that, which directly takes a pointer to the
BDS to be inserted instead of its node-name (which will be used for
implementing 'change' using blockdev-insert-medium).
Signed-off-by: Max Reitz
---
blockdev.c | 54 ++
Signed-off-by: Max Reitz
---
blockdev.c | 30 ++
qapi/block-core.json | 15 +++
qmp-commands.hx | 45 +
3 files changed, 90 insertions(+)
diff --git a/blockdev.c b/blockdev.c
index 743e5ca..a8601ca
As the comment above bdrv_get_stats() says, BlockAcctStats is something
which belongs to the device instead of each BlockDriverState. This patch
therefore moves it into the BlockBackend.
Signed-off-by: Max Reitz
Reviewed-by: Eric Blake
Reviewed-by: Alberto Garcia
Reviewed-by: Kevin Wolf
---
b
These options are only relevant for the user of a whole BDS tree (like a
guest device or a block job) and should thus be moved into the
BlockBackend.
Signed-off-by: Max Reitz
---
block.c| 125 -
block/backup.c | 17
Currently qemu-img allows an image filename to be passed on the
command line, but does not have a way to set any options except
the format eg
qemu-img info https://127.0.0.1/images/centos7.iso
This adds a --source arg (that is mutually exclusive with a
positional filename arg and -f arg) that
If there is no BDS tree attached to a BlockBackend, functions that can
do so should fall back to the BlockBackendRootState structure.
Signed-off-by: Max Reitz
Reviewed-by: Kevin Wolf
---
block/block-backend.c | 28
1 file changed, 24 insertions(+), 4 deletions(-)
d
Fix the BlockBackend's AIOCB AioContext for aborting AIO in case there
is no BDS. If there is no implementation of AIOCBInfo::get_aio_context()
the AioContext is derived from the BDS the AIOCB belongs to. If that BDS
is NULL (because it has been removed from the BB) this will not work.
This patch
Expose the new read-only-mode option of 'blockdev-change-medium' for the
'change' HMP command.
Signed-off-by: Max Reitz
Reviewed-by: Eric Blake
---
hmp-commands.hx | 20 +---
hmp.c | 22 +-
2 files changed, 38 insertions(+), 4 deletions(-)
diff --g
Extract some of the blockdev option extraction code from blockdev_init()
into its own function. This simplifies blockdev_init() and will allow
reusing the code in a different function added in a follow-up patch.
Signed-off-by: Max Reitz
---
blockdev.c | 213 ++
Signed-off-by: Max Reitz
---
blockdev.c | 23 +++
qapi/block-core.json | 16
qmp-commands.hx | 35 +++
3 files changed, 74 insertions(+)
diff --git a/blockdev.c b/blockdev.c
index aa68c36..743e5ca 100644
--- a/bl
Implement 'eject' by calling blockdev-open-tray and
blockdev-remove-medium.
Signed-off-by: Max Reitz
---
blockdev.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/blockdev.c b/blockdev.c
index a4c278f..0481686 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -1941,16
This function removes the BlockDriverState associated with the given
BlockBackend from that BB and sets the BDS pointer in the BB to NULL.
Signed-off-by: Max Reitz
---
block/block-backend.c | 12
include/sysemu/block-backend.h | 1 +
2 files changed, 13 insertions(+)
diff
Signed-off-by: Max Reitz
Reviewed-by: Eric Blake
---
tests/qemu-iotests/118 | 638 +
tests/qemu-iotests/118.out | 5 +
tests/qemu-iotests/group | 1 +
3 files changed, 644 insertions(+)
create mode 100755 tests/qemu-iotests/118
create mode
Implement 'change' on block devices by calling blockdev-open-tray,
blockdev-remove-medium, blockdev-insert-medium (a variation of that
which does not need a node-name) and blockdev-close-tray.
Signed-off-by: Max Reitz
---
blockdev.c | 184 +
Introduce a new QMP command 'blockdev-change-medium' which is intended
to replace the 'change' command for block devices. The existing function
qmp_change_blockdev() is accordingly renamed to
qmp_blockdev_change_medium().
Signed-off-by: Max Reitz
---
blockdev.c| 7 ---
inclu
Daniel P. Berrange writes:
> There are a variety of places where QEMU needs to have access
> to passwords, encryption keys or similar kinds of secrets.
>
>
> Example usage for creating secrets...
>
> Direct password, insecure, for ad-hoc developer testing only
>
> $QEMU -object secret,id=sec0
Add a 'keyid' parameter that refers to the ID of a
QCryptoSecret instance that provides the encryption key.
$QEMU \
-object secret,id=sec0,filename=/home/berrange/encrypted.pw \
-drive file=/home/berrange/encrypted.qcow2,keyid=sec0
Signed-off-by: Daniel P. Berrange
---
block/qcow2.c
The tray of an FDD is open iff there is no medium inserted (there are
only two states for an FDD: "medium inserted" or "no medium inserted").
Signed-off-by: Max Reitz
Reviewed-by: Eric Blake
Reviewed-by: Kevin Wolf
---
hw/block/fdc.c | 20
tests/fdc-test.c | 4 +---
2 f
blk_dev_change_media_cb() is called for all potential tray movements;
however, it is possible to request closing the tray but nothing actually
happening (on a floppy disk drive without a medium).
Thus, the actual tray status should be inquired before sending a
tray-moved event (and an event should
Now that qcow & qcow2 are wired up to get encryption keys
via the QCryptoSecret object, all traces of code which
had to deal with prompting for passwords can be ripped
out.
When the image is initially opened, the encryption key
must be available immediately, or an error will be
reported.
$ qemu-s
Use separate code paths for the two overloaded functions of the 'change'
HMP command, and invoke the 'blockdev-change-medium' QMP command if used
on a block device (by calling qmp_blockdev_change_medium()).
Signed-off-by: Max Reitz
Reviewed-by: Eric Blake
---
hmp.c | 27 +++-
Add an option to qmp_blockdev_change_medium() which allows changing the
read-only status of the block device whose medium is changed.
Some drives do not have a inherently fixed read-only status; for
instance, floppy disks can be set read-only or writable independently of
the drive. Some users may
On 19/10/2015 17:46, Daniel P. Berrange wrote:
>> > The difference is that guest-file-read/write have the payload in JSON;
>> > for file-based secrets the payload is not JSON.
> For non-file based secrets though, the payload *is* in the JSON,
> and per the cover letter, I actually anticipate pass
On Mon, Oct 19, 2015 at 06:12:53PM +0200, Paolo Bonzini wrote:
>
>
> On 19/10/2015 17:46, Daniel P. Berrange wrote:
> >> > The difference is that guest-file-read/write have the payload in JSON;
> >> > for file-based secrets the payload is not JSON.
> > For non-file based secrets though, the paylo
On 19/10/2015 18:24, Daniel P. Berrange wrote:
> The input format, eg the encoding of the data= value, or the contents
> of the file, and the output format, which is that required by the consumer
> inside QEMU. We convert between the two. eg you can provide data in base64
> even if QEMU ultim
On Mon, Oct 19, 2015 at 06:28:26PM +0200, Paolo Bonzini wrote:
>
>
> On 19/10/2015 18:24, Daniel P. Berrange wrote:
> > The input format, eg the encoding of the data= value, or the contents
> > of the file, and the output format, which is that required by the consumer
> > inside QEMU. We conv
blk_bs() will not necessarily return a non-NULL value any more (unless
blk_is_available() is true or it can be assumed to otherwise, e.g.
because it is called immediately after a successful blk_new_with_bs() or
blk_new_open()).
Signed-off-by: Max Reitz
---
block.c | 5 ++
block/qap
If there is no BlockDriverState in a BlockBackend or if the tray of the
guest device is open, fail all requests (where that is possible) with
-ENOMEDIUM.
The reason the status of the guest device is taken into account is
because once the guest device's tray is opened, any request on the same
Block
Do not use "rudimentary" BDSs for empty drives any longer (for
freshly created drives).
After a follow-up patch, empty drives will generally use a NULL BDS, not
only the freshly created drives.
Signed-off-by: Max Reitz
---
blockdev.c | 68
This structure will store some of the state of the root BDS if the BDS
tree is removed, so that state can be restored once a new BDS tree is
inserted.
Signed-off-by: Max Reitz
Reviewed-by: Kevin Wolf
---
block/block-backend.c | 40
include/block
* Daniel P. Berrange (berra...@redhat.com) wrote:
> It is obvious there there is a wide variety of functionality
> in QEMU that needs access to "secrets". This need will only
> grow over time. We need to stop having everyone invent their
> own dangerous wheels and provide a standard mechanism fo
Allow creation of user creatable object types with qemu-nbd
via a --object command line arg. This will be used to supply
passwords and/or encryption keys to the various block driver
backends via the recently added 'secret' object type.
# echo -n letmein > mypasswd.txt
# qemu-nbd --object secret,
This function associates the given BlockDriverState with the given
BlockBackend.
Signed-off-by: Max Reitz
Reviewed-by: Kevin Wolf
---
block/block-backend.c | 11 +++
include/sysemu/block-backend.h | 1 +
2 files changed, 12 insertions(+)
diff --git a/block/block-backend.c b/b
Most of the options which blockdev_init() parses for both the
BlockBackend and the root BDS are valid for just the root BDS as well
(e.g. read-only). This patch allows specifying these options even if not
creating a BlockBackend.
Signed-off-by: Max Reitz
---
blockdev.c | 97 +
On Mon, Oct 19, 2015 at 05:05:58PM +0100, Alex Bennée wrote:
> Daniel P. Berrange writes:
>
> > There are a variety of places where QEMU needs to have access
> > to passwords, encryption keys or similar kinds of secrets.
> >
>
> >
> > Example usage for creating secrets...
> >
> > Direct password
On Mon, Oct 19, 2015 at 06:13:24PM +0100, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrange (berra...@redhat.com) wrote:
>
>
>
> > It is obvious there there is a wide variety of functionality
> > in QEMU that needs access to "secrets". This need will only
> > grow over time. We need to stop h
In places which directly pass a filename to the OS, we should not use
the filename field at all but exact_filename instead (although the
former currently equals the latter if that is set).
In raw_open_common(), we do not need to access BDS.filename because we
already have a local variable pointing
Instead of returning a pointer to the filename, g_strdup() it. This will
become necessary once we do not have BlockDriverState.filename anymore.
Signed-off-by: Max Reitz
---
block.c | 17 ++---
include/block/block.h | 2 +-
monitor.c | 5 -
3 files cha
*** This series is based on v7 of my ***
*** "blockdev: BlockBackend and media" series ***
The BDS filename field is generally only used when opening disk images
or emitting error or warning messages, the only exception to this rule
is the map command of qemu-img. However, using exact_filename th
After drive-mirror replacing a Quorum child, the filename of the Quorum
BDS should reflect the change. This patch replaces the existing test for
whether the operation did actually exchange the BDS (which simply tested
whether the new BDS existed) by a test which examines the children list
contained
Replaces bs->filename by the result of bdrv_filename() in the
qemu-img map subcommand. Since that value is queried relatively often,
however, it should be cached.
Signed-off-by: Max Reitz
---
qemu-img.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/qemu-img.c
That field is now only used during initialization of BlockDriverStates
(opening images) and for error or warning messages. Performance is not
that much of an issue here, so we can drop the field and replace its use
by a call to bdrv_filename(). By doing so we can ensure the result
always to be rece
Split the part which actually refreshes the BlockDriverState.filename
field off of bdrv_refresh_filename() into a more generic function
bdrv_filename(), which first calls bdrv_refresh_filename() and then
stores a qemu-usable filename in the given buffer instead of
BlockDriverState.filename.
Since
On 10/19/2015 12:49 PM, Max Reitz wrote:
> Instead of returning a pointer to the filename, g_strdup() it. This will
> become necessary once we do not have BlockDriverState.filename anymore.
>
> Signed-off-by: Max Reitz
> ---
> block.c | 17 ++---
> include/block/block.h
On 10/16/15 21:09, Laszlo Ersek wrote:
> On 10/16/15 13:34, Fabio Fantoni wrote:
>> Il 16/10/2015 12:47, Stefano Stabellini ha scritto:
>>> On Fri, 16 Oct 2015, Fabio Fantoni wrote:
Il 16/10/2015 12:13, Anthony PERARD ha scritto:
> On Fri, Oct 16, 2015 at 10:32:44AM +0200, Fabio Fantoni wr
On 10/19/2015 12:49 PM, Max Reitz wrote:
> In places which directly pass a filename to the OS, we should not use
> the filename field at all but exact_filename instead (although the
> former currently equals the latter if that is set).
>
> In raw_open_common(), we do not need to access BDS.filenam
On 10/19/2015 12:49 PM, Max Reitz wrote:
> Split the part which actually refreshes the BlockDriverState.filename
> field off of bdrv_refresh_filename() into a more generic function
> bdrv_filename(), which first calls bdrv_refresh_filename() and then
> stores a qemu-usable filename in the given buf
On 10/19/2015 12:49 PM, Max Reitz wrote:
> Replaces bs->filename by the result of bdrv_filename() in the
> qemu-img map subcommand. Since that value is queried relatively often,
> however, it should be cached.
>
> Signed-off-by: Max Reitz
> ---
> qemu-img.c | 14 +-
> 1 file changed,
On 10/19/2015 12:49 PM, Max Reitz wrote:
> That field is now only used during initialization of BlockDriverStates
> (opening images) and for error or warning messages. Performance is not
> that much of an issue here, so we can drop the field and replace its use
> by a call to bdrv_filename(). By do
On 10/19/2015 12:49 PM, Max Reitz wrote:
> After drive-mirror replacing a Quorum child, the filename of the Quorum
> BDS should reflect the change. This patch replaces the existing test for
> whether the operation did actually exchange the BDS (which simply tested
> whether the new BDS existed) by
On 10/19/2015 08:09 AM, Daniel P. Berrange wrote:
Currently RBD passwords must be provided on the command line
via
$QEMU -drive file=rbd:pool/image:id=myname:\
key=QVFDVm41aE82SHpGQWhBQXEwTkN2OGp0SmNJY0UrSE9CbE1RMUE=:\
auth_supported=cephx
This is insecure because the key is visibl
On 10/19/2015 09:09 AM, Daniel P. Berrange wrote:
> Add a 'keyid' parameter that refers to the ID of a
> QCryptoSecret instance that provides the encryption key.
>
> $QEMU \
> -object secret,id=sec0,filename=/home/berrange/encrypted.pw \
> -drive file=/home/berrange/encrypted.qcow2,keyid=s
On Mon, 10/19 09:27, Markus Armbruster wrote:
> John Snow writes:
>
> > On 10/16/2015 08:23 AM, Stefan Hajnoczi wrote:
> >> On Mon, Oct 12, 2015 at 12:50:20PM -0400, John Snow wrote:
> >>> Ping -- any consensus on how we should implement the "do-or-die"
> >>> argument for transactions that start
The semantics is that after bdrv_drained_begin(bs), bs will not get new external
requests until the matching bdrv_drained_end(bs).
Signed-off-by: Fam Zheng
---
block/io.c| 17 +
include/block/block.h | 19 +++
include/block/block_int.h | 2 ++
This ensures the atomicity of the transaction by avoiding processing of
external requests such as those from ioeventfd.
Signed-off-by: Fam Zheng
---
blockdev.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/blockdev.c b/blockdev.c
index 8141b6b..fc63c3d 100644
--
Signed-off-by: Fam Zheng
---
tests/test-aio.c | 24
1 file changed, 24 insertions(+)
diff --git a/tests/test-aio.c b/tests/test-aio.c
index 03cd45d..1623803 100644
--- a/tests/test-aio.c
+++ b/tests/test-aio.c
@@ -374,6 +374,29 @@ static void test_flush_event_notifier(vo
Similar to the previous patch, make sure that external events are not
dispatched during transaction operations.
Signed-off-by: Fam Zheng
---
blockdev.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/blockdev.c b/blockdev.c
index e3e68e6..6ab98e3 100644
--- a/blockdev.c
++
This ensures the atomicity of the transaction by avoiding processing of
external requests such as those from ioeventfd.
state->bs is assigned right after bdrv_drained_begin. Because it was
used as the flag for deletion or not in abort, now we need a separate
flag - InternalSnapshotState.created.
This ensures the atomicity of the transaction by avoiding processing of
external requests such as those from ioeventfd.
Move the assignment to state->bs up right after bdrv_drained_begin, so
that we can use it in the clean callback. The abort callback will still
check bs->job and state->job, so it
They will be excluded by type in the nested event loops in block layer,
so that unwanted events won't be processed there.
Signed-off-by: Fam Zheng
---
hw/block/dataplane/virtio-blk.c | 5 ++---
hw/scsi/virtio-scsi-dataplane.c | 18 --
2 files changed, 10 insertions(+), 13 deleti
v4: Rebase on to master so fix the "bdrv_move_feature_fields" issue.
v3: Call bdrv_drain unconditionally in bdrv_drained_begin.
Document the internal I/O implications between bdrv_drain_begin and end.
The nested aio_poll()'s in block layer has a bug that new r/w requests from
ioeventfds and n
So we could distinguish it from internal used fds, thus avoid handling
unwanted events in nested aio polls.
Signed-off-by: Fam Zheng
---
nbd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/nbd.c b/nbd.c
index fbc66be..dab1ebb 100644
--- a/nbd.c
+++ b/nbd.c
@@ -1446,7 +1
All callers pass in false, and the real external ones will switch to
true in coming patches.
Signed-off-by: Fam Zheng
---
aio-posix.c | 6 -
aio-win32.c | 5
async.c | 3 ++-
block/curl.c| 14 +---
The "need_check_timer" is used to clear the "NEED_CHECK" flag in the
image header after a grace period once metadata update has finished. In
compliance to the bdrv_drain semantics we should make sure it remains
deleted once .bdrv_drain is called.
Call the qed_need_check_timer_cb manually to update
Signed-off-by: Fam Zheng
---
aio-posix.c | 3 ++-
aio-win32.c | 3 ++-
include/block/aio.h | 37 +
3 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/aio-posix.c b/aio-posix.c
index f0f9122..0467f23 100644
--- a/aio-posix.c
+++ b/
1 - 100 of 116 matches
Mail list logo