On Thu, Feb 07, 2019 at 01:24:28PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> Hi all!
>
> Here is a new simple helper for a very often patter
> around qemu_iovec_init_external, when we need simple qiov with only
> one iov, initialized from external buffer.
>
> v3:
> 01-02: tiny improvements,
On Tue, Feb 12, 2019 at 12:58:40PM +0100, Kevin Wolf wrote:
> Am 12.02.2019 um 04:22 hat Stefan Hajnoczi geschrieben:
> > On Mon, Feb 11, 2019 at 09:38:37AM +, Vladimir Sementsov-Ogievskiy
> > wrote:
> > > 11.02.2019 6:42, Stefan Hajnoczi wrote:
> > > > On Fri, Feb 08, 2019 at 05:11:22PM
Cc'ing the QCOW2 folks.
Drew DeVault writes:
> I recently ran into an issue where I found I couldn't combine the
> -loadvm and -snapshot flags, nor any conceivable combination of
> alternate approaches like loadvm via the monitor. Independently, both
> options work as expected, but together I
On 2/12/19 3:37 PM, John Snow wrote:
>
>
> On 2/12/19 3:16 PM, Eric Blake wrote:
>> On 2/12/19 2:07 PM, John Snow wrote:
>>> When bitmaps are persistent, they may incur a disk read or write when
>>> bitmaps
>>> are added or removed. For configurations like virtio-dataplane, failing to
>>>
On 2/12/19 3:16 PM, Eric Blake wrote:
> On 2/12/19 2:07 PM, John Snow wrote:
>> When bitmaps are persistent, they may incur a disk read or write when bitmaps
>> are added or removed. For configurations like virtio-dataplane, failing to
>> acquire this lock will abort QEMU when disk IO occurs.
On 1/11/19 7:00 AM, Max Reitz wrote:
On 12.11.18 08:06, Marc Olson wrote:
Add a new rule type for blkdebug that instead of returning an error, can
inject latency to an IO.
Signed-off-by: Marc Olson
---
block/blkdebug.c | 79 +++---
On 2/12/19 2:07 PM, John Snow wrote:
> When bitmaps are persistent, they may incur a disk read or write when bitmaps
> are added or removed. For configurations like virtio-dataplane, failing to
> acquire this lock will abort QEMU when disk IO occurs.
>
> We used to acquire aio_context as part of
When bitmaps are persistent, they may incur a disk read or write when bitmaps
are added or removed. For configurations like virtio-dataplane, failing to
acquire this lock will abort QEMU when disk IO occurs.
We used to acquire aio_context as part of the bitmap lookup, so re-introduce
the lock for
On 2/6/19 11:02 AM, John Snow wrote:
> When bitmaps are persistent, they may incur a disk read or write when bitmaps
> are added or removed. For configurations like virtio-dataplane, failing to
> acquire this lock will abort QEMU when disk IO occurs.
>
> We used to acquire aio_context as part of
On 2/12/19 2:36 PM, Eric Blake wrote:
> On 2/6/19 11:02 AM, John Snow wrote:
>> When bitmaps are persistent, they may incur a disk read or write when bitmaps
>> are added or removed. For configurations like virtio-dataplane, failing to
>> acquire this lock will abort QEMU when disk IO occurs.
On 2/12/19 2:27 PM, Eric Blake wrote:
> On 2/11/19 7:02 PM, 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 from the various _locked and _unlocked
On 2/11/19 7:02 PM, 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 from the various _locked and _unlocked
> versions of bitmap helpers that refer to
On 2/12/19 1:58 PM, Eric Blake wrote:
> On 2/11/19 7:02 PM, 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 guest writes, and is allowed to do so."
>>
>> In many
On 2/11/19 7:02 PM, 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 guest writes, and is allowed to do so."
>
> In many places, this is how this predicate was already used.
On 2/11/19 7:02 PM, John Snow wrote:
> 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.
> ---
> block/dirty-bitmap.c | 9 +
> 1 file changed, 5 insertions(+), 4
On 2/12/19 1:26 PM, Eric Blake wrote:
> On 2/11/19 7:02 PM, 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
>> predicate more clear to outside callers.
>>
>> In the
On 2/11/19 7:02 PM, 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
> predicate more clear to outside callers.
>
> In the process, remove some calls to frozen() that no
On 2/12/19 1:17 PM, Eric Blake wrote:
> On 2/11/19 7:02 PM, John Snow wrote:
>> The current API allows us to report a single status, which we've defined as:
>>
>> Frozen: has a successor, treated as qmp_locked, may or may not be enabled.
>> Locked: no successor, qmp_locked. may or may not be
On 2/11/19 7:02 PM, John Snow wrote:
> The current API allows us to report a single status, which we've defined as:
>
> Frozen: has a successor, treated as qmp_locked, may or may not be enabled.
> Locked: no successor, qmp_locked. may or may not be enabled.
> Disabled: Not frozen or locked,
Am 17.01.2019 um 16:34 hat Alberto Garcia geschrieben:
> This patch adds two new fields to BlockDriver:
>
>- runtime_opts: list of runtime options for a particular block
> driver. We'll use this list later to detect what options are
> missing when we try to reopen a block device.
>
On 2/11/19 7:02 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 favor of two new booleans
> that carry very specific meanings. Then, rename and
On Tue, Feb 12, 2019 at 6:04 PM Peter Maydell wrote:
>
> On Tue, 12 Feb 2019 at 14:12, Stefan Hajnoczi wrote:
> >
> > Block pull request for testing
> >
> > Peter hit a virtio-blk-test failure caused by the new DISCARD/WRITE_ZEROES
On 2/12/19 1:12 PM, Eric Blake wrote:
> On 2/11/19 7:02 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 favor of two new booleans
>> that
On 11.02.2019 6:04, Stefan Hajnoczi wrote:
> On Thu, Feb 07, 2019 at 01:24:28PM +0300, Vladimir Sementsov-Ogievskiy wrote:
>> v3:
>
> Will you send a v4 based on Eric's comments or do you want to keep the
> series as it is?
>
I don't really want to resend, and I don't think that open-coding
Am 17.01.2019 um 16:33 hat Alberto Garcia geschrieben:
> This patch allows the user to change the backing file of an image that
> is being reopened. Here's what it does:
>
> - In bdrv_reopen_prepare(): check that the value of 'backing' points
>to an existing node or is null. If it points to
On Tue, 12 Feb 2019 at 14:12, Stefan Hajnoczi wrote:
>
> Block pull request for testing
>
> Peter hit a virtio-blk-test failure caused by the new DISCARD/WRITE_ZEROES
> patches that Stefano and I have been unable to reproduce. Here
Am 12.02.2019 um 17:28 hat Kevin Wolf geschrieben:
> > -child_key_dot = g_strdup_printf("%s.", child->name);
> > -qdict_extract_subqdict(explicit_options, NULL, child_key_dot);
> > -qdict_extract_subqdict(options, _child_options, child_key_dot);
> > -
Am 17.01.2019 um 16:33 hat Alberto Garcia geschrieben:
> Of all options of type BlockdevRef used to specify children in
> BlockdevOptions, 'backing' is the only one that is optional.
>
> For "x-blockdev-reopen" we want that if an option is omitted then it
> must be reset to its default value. The
Am 17.01.2019 um 16:33 hat Alberto Garcia geschrieben:
> Children in QMP are specified with BlockdevRef / BlockdevRefOrNull,
> which can contain a set of child options, a child reference, or
> NULL. In optional attributes like "backing" it can also be missing.
>
> Only the first case (set of
On Tue 12 Feb 2019 04:15:58 PM CET, Kevin Wolf wrote:
> Am 17.01.2019 um 16:33 hat Alberto Garcia geschrieben:
>> Signed-off-by: Alberto Garcia
>> ---
>> block/stream.c | 16
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/block/stream.c b/block/stream.c
>> index
Am 17.01.2019 um 16:33 hat Alberto Garcia geschrieben:
> Signed-off-by: Alberto Garcia
> ---
> block/stream.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/block/stream.c b/block/stream.c
> index 7a49ac0992..39a2e10892 100644
> --- a/block/stream.c
> +++
Am 17.01.2019 um 16:33 hat Alberto Garcia geschrieben:
> Signed-off-by: Alberto Garcia
> ---
> block/commit.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/block/commit.c b/block/commit.c
> index 53148e610b..8824d135e0 100644
> --- a/block/commit.c
> +++ b/block/commit.c
> @@
Am 17.01.2019 um 16:33 hat Alberto Garcia geschrieben:
> Our permission system is useful to define what operations are allowed
> on a certain block node and includes things like BLK_PERM_WRITE or
> BLK_PERM_RESIZE among others.
>
> One of the permissions is BLK_PERM_GRAPH_MOD which allows
From: Stefano Garzarella
In order to avoid migration issues, we enable DISCARD and
WRITE_ZEROES features only for machine type >= 4.0
As discussed with Michael S. Tsirkin and Stefan Hajnoczi on the
list [1], DISCARD operation should not have security implications
(eg. page cache attacks), so we
The following changes since commit 22c5f446514a2a4bb0dbe1fea26713da92fc85fa:
Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20190211' into
staging (2019-02-11 17:04:57 +)
are available in the Git repository at:
git://github.com/stefanha/qemu.git
From: Stefano Garzarella
The size of data in the virtio_blk_request must be a multiple
of 512 bytes for IN and OUT requests, or a multiple of the size
of struct virtio_blk_discard_write_zeroes for DISCARD and
WRITE_ZEROES requests.
Reviewed-by: Michael S. Tsirkin
Reviewed-by: Stefan Hajnoczi
From: Stefano Garzarella
We add acct_failed param in order to use virtio_blk_handle_rw_error()
also when is not required to call block_acct_failed(). (eg. a discard
operation is failed)
Reviewed-by: Michael S. Tsirkin
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Stefano Garzarella
Acked-by:
From: Stefano Garzarella
Since configurable features for virtio-blk are growing, this patch
adds host_features field in the struct VirtIOBlock. (as in virtio-net)
In this way, we can avoid to add new fields for new properties and
we can directly set VIRTIO_BLK_F* flags in the host_features.
We
From: Stefano Garzarella
This patch adds the support of DISCARD and WRITE_ZEROES commands,
that have been introduced in the virtio-blk protocol to have
better performance when using SSD backend.
We support only one segment per request since multiple segments
are not widely used and there are no
On Fri, Feb 08, 2019 at 02:49:44PM +0100, Stefano Garzarella wrote:
> This series adds the support of DISCARD and WRITE_ZEROES commands
> and extends the virtio-blk-test to test WRITE_ZEROES command when
> the feature is enabled.
Looking at how this wasn't merged yet, maybe it's not too late.
From: Stefano Garzarella
If the WRITE_ZEROES feature is enabled, we check this command
in the test_basic().
Reviewed-by: Michael S. Tsirkin
Reviewed-by: Stefan Hajnoczi
Acked-by: Thomas Huth
Signed-off-by: Stefano Garzarella
Acked-by: Pankaj Gupta
Message-id:
From: Stefano Garzarella
In order to avoid migration issues, we enable DISCARD and
WRITE_ZEROES features only for machine type >= 4.0
As discussed with Michael S. Tsirkin and Stefan Hajnoczi on the
list [1], DISCARD operation should not have security implications
(eg. page cache attacks), so we
From: Stefano Garzarella
This patch adds the support of DISCARD and WRITE_ZEROES commands,
that have been introduced in the virtio-blk protocol to have
better performance when using SSD backend.
We support only one segment per request since multiple segments
are not widely used and there are no
From: Stefano Garzarella
The size of data in the virtio_blk_request must be a multiple
of 512 bytes for IN and OUT requests, or a multiple of the size
of struct virtio_blk_discard_write_zeroes for DISCARD and
WRITE_ZEROES requests.
Reviewed-by: Michael S. Tsirkin
Reviewed-by: Stefan Hajnoczi
From: Stefano Garzarella
Since configurable features for virtio-blk are growing, this patch
adds host_features field in the struct VirtIOBlock. (as in virtio-net)
In this way, we can avoid to add new fields for new properties and
we can directly set VIRTIO_BLK_F* flags in the host_features.
We
From: Stefano Garzarella
We add acct_failed param in order to use virtio_blk_handle_rw_error()
also when is not required to call block_acct_failed(). (eg. a discard
operation is failed)
Reviewed-by: Michael S. Tsirkin
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Stefano Garzarella
Acked-by:
From: Stefano Garzarella
If the WRITE_ZEROES feature is enabled, we check this command
in the test_basic().
Reviewed-by: Michael S. Tsirkin
Reviewed-by: Stefan Hajnoczi
Acked-by: Thomas Huth
Signed-off-by: Stefano Garzarella
Acked-by: Pankaj Gupta
Message-id:
Peter hit a virtio-blk-test failure caused by the new DISCARD/WRITE_ZEROES
patches that Stefano and I have been unable to reproduce. Here are the patches
so they can be tested again in Peter's environment.
Stefano Garzarella (6):
virtio-blk: add acct_failed param to
On Tue, 12 Feb 2019 at 04:01, Stefan Hajnoczi wrote:
>
> The following changes since commit 22c5f446514a2a4bb0dbe1fea26713da92fc85fa:
>
> Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20190211' into
> staging (2019-02-11 17:04:57 +)
>
> are available in the Git repository at:
>
>
Clean QCOW2 image from bitmap obsolete directory when a new one
is allocated and stored. It slows down the image growth a little bit.
The flag QCOW2_DISCARD_ALWAYS allows a call to raw_co_pdiscard()
that does the actual cleaning of the image on disk.
With the flag QCOW2_DISCARD_OTHER, a reference
Am 12.02.2019 um 04:22 hat Stefan Hajnoczi geschrieben:
> On Mon, Feb 11, 2019 at 09:38:37AM +, Vladimir Sementsov-Ogievskiy wrote:
> > 11.02.2019 6:42, Stefan Hajnoczi wrote:
> > > On Fri, Feb 08, 2019 at 05:11:22PM +0300, Vladimir Sementsov-Ogievskiy
> > > wrote:
> > >> Hi all!
> > >>
> >
On Mon 11 Feb 2019 05:58:05 PM CET, Vladimir Sementsov-Ogievskiy wrote:
>>> The problem is in the concept of "base" node. The code written in
>>> manner that base is not changed during block job. However, job don't
>>> own base and there is no guarantee that it will not change during
>>> the job.
On Tue, Feb 12, 2019 at 10:03:19AM +, Vladimir Sementsov-Ogievskiy wrote:
> 12.02.2019 6:22, Stefan Hajnoczi wrote:
> > On Mon, Feb 11, 2019 at 09:38:37AM +, Vladimir Sementsov-Ogievskiy
> > wrote:
> >> 11.02.2019 6:42, Stefan Hajnoczi wrote:
> >>> On Fri, Feb 08, 2019 at 05:11:22PM
On Mon, Feb 11, 2019 at 03:55:58PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> Expose attached aio context. It will be used in nbd code, to
> understand, in which aio context negotiation should be done.
I'm not especially objecting to the idea of adding the API to the
QIOChannel class, but I'm
12.02.2019 6:22, Stefan Hajnoczi wrote:
> On Mon, Feb 11, 2019 at 09:38:37AM +, Vladimir Sementsov-Ogievskiy wrote:
>> 11.02.2019 6:42, Stefan Hajnoczi wrote:
>>> On Fri, Feb 08, 2019 at 05:11:22PM +0300, Vladimir Sementsov-Ogievskiy
>>> wrote:
Hi all!
We have a very frequent
12.02.2019 12:07, Kevin Wolf wrote:
> Am 11.02.2019 um 19:30 hat Vladimir Sementsov-Ogievskiy geschrieben:
>> 11.02.2019 20:54, Kevin Wolf wrote:
>>> Am 21.12.2018 um 17:53 hat Vladimir Sementsov-Ogievskiy geschrieben:
Move to way of device selecting, however fall back to device name if
On Tue, 12 Feb 2019 at 03:51, Stefan Hajnoczi wrote:
>
> On Mon, Feb 11, 2019 at 11:42:14AM +, Peter Maydell wrote:
> > Hi; this fails to pass "make check" (all platforms):
> >
> > MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}
> >
Am 11.02.2019 um 19:30 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 11.02.2019 20:54, Kevin Wolf wrote:
> > Am 21.12.2018 um 17:53 hat Vladimir Sementsov-Ogievskiy geschrieben:
> >> Move to way of device selecting, however fall back to device name if
> >> path is not found.
> >>
> >>
On Tue, Feb 12, 2019 at 11:51:18AM +0800, Stefan Hajnoczi wrote:
> On Mon, Feb 11, 2019 at 11:42:14AM +, Peter Maydell wrote:
> >
> > Hi; this fails to pass "make check" (all platforms):
> >
> > MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}
> >
59 matches
Mail list logo
