25.11.2019 18:46, Kevin Wolf wrote:
> Am 25.11.2019 um 11:08 hat Vladimir Sementsov-Ogievskiy geschrieben:
>> Ping?
>>
>> Hi! Why so silent? Postpone this to 5.0? This is fixing the same
>> problem with block commit, like Kevin's series, just commit not to mid
>> but to base..
>
> To be honest, I
25.11.2019 19:00, Kevin Wolf wrote:
> Am 16.11.2019 um 17:34 hat Vladimir Sementsov-Ogievskiy geschrieben:
>> bdrv_co_block_status_above has several problems with handling short
>> backing files:
>>
>> 1. With want_zeros=true, it may return ret with BDRV_BLOCK_ZERO but
>> without
On 25.11.2019 18:30, Eduardo Habkost wrote:
> On Fri, Nov 22, 2019 at 11:36:30AM +, Denis Plotnikov wrote:
>>
>> On 18.11.2019 21:54, Eduardo Habkost wrote:
>>> On Sun, Nov 10, 2019 at 10:03:09PM +0300, Denis Plotnikov wrote:
Some device's property can be changed if the device has been
On 22.11.19 15:22, Maxim Levitsky wrote:
> Hi!
>
> This is the second version of the proposed QMP API for key management,
> after discussion with Keven and Max.
>
> Will this work?
>
> Adding Peter Krempa to CC, to hear his opinion from the
> libvirt side.
>
> Best regards,
> Maxim
When initializing the LUKS header the size with default encryption
parameters will currently be 2068480 bytes. This is rounded up to
a multiple of the cluster size, 2081792, with 64k sectors. If the
end of the header is not the same as the end of the cluster we fill
the extra space with zeros.
Am 16.11.2019 um 17:34 hat Vladimir Sementsov-Ogievskiy geschrieben:
> We are going to reuse bdrv_common_block_status_above in
> bdrv_is_allocated_above. bdrv_is_allocated_above may be called with
> include_base == false and still bs == base (for ex. from img_rebase()).
>
> So, support this
Am 16.11.2019 um 17:34 hat Vladimir Sementsov-Ogievskiy geschrieben:
> In order to reuse bdrv_common_block_status_above in
> bdrv_is_allocated_above, let's support include_base parameter.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Kevin Wolf
Am 25.11.2019 um 16:06 hat Alberto Garcia geschrieben:
> On Fri 22 Nov 2019 05:05:05 PM CET, Kevin Wolf wrote:
>
> > @@ -3405,6 +3412,7 @@ typedef struct TruncateCo {
> > int64_t offset;
> > bool exact;
> > PreallocMode prealloc;
> > +bool no_fallback;
> > Error **errp;
>
Am 16.11.2019 um 17:34 hat Vladimir Sementsov-Ogievskiy geschrieben:
> bdrv_co_block_status_above has several problems with handling short
> backing files:
>
> 1. With want_zeros=true, it may return ret with BDRV_BLOCK_ZERO but
> without BDRV_BLOCK_ALLOCATED flag, when actually short backing file
Am 25.11.2019 um 11:08 hat Vladimir Sementsov-Ogievskiy geschrieben:
> Ping?
>
> Hi! Why so silent? Postpone this to 5.0? This is fixing the same
> problem with block commit, like Kevin's series, just commit not to mid
> but to base..
To be honest, I think by now we've found so many problems
On Fri, Nov 22, 2019 at 11:36:30AM +, Denis Plotnikov wrote:
>
>
> On 18.11.2019 21:54, Eduardo Habkost wrote:
> > On Sun, Nov 10, 2019 at 10:03:09PM +0300, Denis Plotnikov wrote:
> >> Some device's property can be changed if the device has been already
> >> realized. For example, it could
On Fri 22 Nov 2019 05:05:05 PM CET, Kevin Wolf wrote:
> @@ -3405,6 +3412,7 @@ typedef struct TruncateCo {
> int64_t offset;
> bool exact;
> PreallocMode prealloc;
> +bool no_fallback;
> Error **errp;
> int ret;
> } TruncateCo;
You add the 'no_fallback' field here...
On Fri 22 Nov 2019 05:05:06 PM CET, Kevin Wolf wrote:
> In the common case, qcow2_co_pwrite_zeroes() already only modifies
> metadata case, so we're fine with or without BDRV_REQ_NO_FALLBACK set.
>
> The only exception is when using an external data file, where the
> request is passed down to the
On Mon, 25 Nov 2019 at 06:21, Klaus Birkelund wrote:
>
> On Tue, Nov 12, 2019 at 03:25:18PM +, Beata Michalska wrote:
> > Hi Klaus,
> >
> > On Tue, 15 Oct 2019 at 11:57, Klaus Jensen wrote:
> > > +static uint16_t nvme_map_sgl(NvmeCtrl *n, QEMUSGList *qsg,
> > > +NvmeSglDescriptor sgl,
25.11.2019 16:50, Max Reitz wrote:
> On 25.11.19 13:52, Vladimir Sementsov-Ogievskiy wrote:
>> Hi all!
>>
>> We've faced a bug in rhev-2.12.0-33.el7-based Qemu.
>> In upstream, bug introduced in 4.0 by 74da6b943565c45
>> "block/dirty-bitmaps: implement inconsistent bit" commit.
>> At this commit
On Thu, 21 Nov 2019 at 11:57, Klaus Birkelund wrote:
>
> 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,
On 25.11.19 13:52, Vladimir Sementsov-Ogievskiy wrote:
> Hi all!
>
> We've faced a bug in rhev-2.12.0-33.el7-based Qemu.
> In upstream, bug introduced in 4.0 by 74da6b943565c45
> "block/dirty-bitmaps: implement inconsistent bit" commit.
> At this commit we started to load inconsistent bitmap
On Wed, 20 Nov 2019 at 09:39, Klaus Birkelund wrote:
>
> On Tue, Nov 12, 2019 at 03:23:43PM +, Beata Michalska wrote:
> > Hi Klaus,
> >
> > On Tue, 15 Oct 2019 at 11:57, Klaus Jensen wrote:
> > >
> > > Instead of handling both QSGs and IOVs in multiple places, simply use
> > > QSGs
Hi all!
We've faced a bug in rhev-2.12.0-33.el7-based Qemu.
In upstream, bug introduced in 4.0 by 74da6b943565c45
"block/dirty-bitmaps: implement inconsistent bit" commit.
At this commit we started to load inconsistent bitmap instead of
silently ignoring them, and it now I see that it breaks
Add optional pre-shutdown: shutdown/launch vm before migration. This
leads to storing persistent bitmap to the storage, which breaks
migration with dirty-bitmaps capability enabled and shared storage
until fixed by previous commit.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
Fix bitmap migration with dirty-bitmaps capability enabled and shared
storage. We should ignore IN_USE bitmaps in the image on target, when
migrating bitmaps through migration channel, see new comment below.
Fixes: 74da6b943565c451
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
On Tue, 19 Nov 2019 at 19:51, Klaus Birkelund wrote:
>
> On Tue, Nov 12, 2019 at 03:04:59PM +, Beata Michalska wrote:
> > Hi Klaus,
> >
> > On Tue, 15 Oct 2019 at 11:49, Klaus Jensen wrote:
> > > @@ -1188,6 +1326,9 @@ static int nvme_start_ctrl(NvmeCtrl *n)
> > >
> > >
On 22.11.19 17:05, Kevin Wolf wrote:
> See patch 4 for the description of the bug fixed.
>
> v3:
> - Don't allow blocking the monitor for a zero write in block_resize
> (even though we can already blockfor other reasons there). This is
> mainly responsible for the increased complexity
On 22.11.19 17:41, Eric Blake wrote:
> On 11/22/19 10:17 AM, Peter Maydell wrote:
[...]
>> Eyeballing of the diffstat plus the fact we're on v4 of
>> the patchset already makes me a little uneasy about
>> putting it into rc3, but if the bug we're fixing matters
>> enough we can do it.
>
> In
On Mon, 18 Nov 2019 at 09:48, Klaus Birkelund wrote:
>
> On Tue, Nov 12, 2019 at 03:05:06PM +, Beata Michalska wrote:
> > Hi Klaus,
> >
> > On Tue, 15 Oct 2019 at 11:52, Klaus Jensen wrote:
> > >
> > > +static uint16_t nvme_identify_ns_descr_list(NvmeCtrl *n, NvmeCmd *c)
> > > +{
> > > +
On 22.11.19 17:05, 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 22.11.19 17:05, Kevin Wolf wrote:
> Signed-off-by: Kevin Wolf
> ---
> tests/qemu-iotests/274| 152 +
> tests/qemu-iotests/274.out| 203 ++
> tests/qemu-iotests/group | 1 +
> tests/qemu-iotests/iotests.py | 2 +-
> 4
On 22.11.19 17:05, Kevin Wolf wrote:
> In the common case, qcow2_co_pwrite_zeroes() already only modifies
> metadata case, so we're fine with or without BDRV_REQ_NO_FALLBACK set.
>
> The only exception is when using an external data file, where the
> request is passed down to the block driver of
On 22.11.19 17:05, Kevin Wolf wrote:
> This adds a no_fallback parameter to bdrv_co_truncate(), bdrv_truncate()
> and blk_truncate() in preparation for a fix that potentially needs to
> zero-write the new area. no_fallback will use BDRV_REQ_NO_FALLBACK for
> this operation and lets the truncate
Am 20.11.2019 um 19:01 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 20.11.2019 17:03, 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
Alex Bennée writes:
> Thomas Huth writes:
>
>> Travis recently added build hosts for arm64, ppc64le and s390x, so
>> this is a welcome addition to our Travis testing matrix.
>>
>> Unfortunately, the builds are running in quite restricted LXD containers
>> there, for example it is not possible
Ping?
Hi! Why so silent? Postpone this to 5.0? This is fixing the same problem with
block
commit, like Kevin's series, just commit not to mid but to base..
16.11.2019 19:34, Vladimir Sementsov-Ogievskiy wrote:
> Hi all!
>
> I wanted to understand, what is the real difference between
>
22.11.2019 19:05, Kevin Wolf wrote:
> Signed-off-by: Kevin Wolf
Reviewed-by: Vladimir Sementsov-Ogievskiy
Tested-by: Vladimir Sementsov-Ogievskiy
--
Best regards,
Vladimir
33 matches
Mail list logo
