On 12.11.19 12:30, Sergio Lopez wrote:
> Consolidate drive_backup_prepare() with do_drive_backup() as a first
> step towards streamlining all functionality through transactions.
>
> Signed-off-by: Sergio Lopez
> ---
> blockdev.c | 58 +++---
> 1 fi
On 13.11.19 14:24, Sergio Lopez wrote:
>
> Sergio Lopez writes:
>
>> no-re...@patchew.org writes:
>>
>>> Patchew URL: https://patchew.org/QEMU/20191112113012.71136-1-...@redhat.com/
>>>
>>>
>>>
>>> Hi,
>>>
>>> This series failed the docker-quick@centos7 build test. Please find the
>>> testing c
On 16.11.19 17:34, Vladimir Sementsov-Ogievskiy wrote:
> Hi all!
>
> I wanted to understand, what is the real difference between
> bdrv_block_status_above
> and bdrv_is_allocated_above, IMHO bdrv_is_allocated_above should work through
> bdrv_block_status_above..
>
> And I found the problem: bdrv
Max Reitz writes:
> On 13.11.19 14:24, Sergio Lopez wrote:
>>
>> Sergio Lopez writes:
>>
>>> no-re...@patchew.org writes:
>>>
Patchew URL:
https://patchew.org/QEMU/20191112113012.71136-1-...@redhat.com/
Hi,
This series failed the docker-quick@centos7 b
Am 19.11.2019 um 11:54 hat Sergio Lopez geschrieben:
>
> Max Reitz writes:
>
> > On 13.11.19 14:24, Sergio Lopez wrote:
> >>
> >> Sergio Lopez writes:
> >>
> >>> no-re...@patchew.org writes:
> >>>
> Patchew URL:
> https://patchew.org/QEMU/20191112113012.71136-1-...@redhat.com/
> >>
Kevin Wolf writes:
> Am 19.11.2019 um 11:54 hat Sergio Lopez geschrieben:
>>
>> Max Reitz writes:
>>
>> > On 13.11.19 14:24, Sergio Lopez wrote:
>> >>
>> >> Sergio Lopez writes:
>> >>
>> >>> no-re...@patchew.org writes:
>> >>>
>> Patchew URL:
>> https://patchew.org/QEMU/20191112
On 11/19/19 1:22 PM, Max Reitz wrote:
> On 16.11.19 17:34, Vladimir Sementsov-Ogievskiy wrote:
>> Hi all!
>>
>> I wanted to understand, what is the real difference between
>> bdrv_block_status_above
>> and bdrv_is_allocated_above, IMHO bdrv_is_allocated_above should work through
>> bdrv_block_stat
Am 16.11.2019 um 17:34 hat Vladimir Sementsov-Ogievskiy geschrieben:
> Hi all!
>
> I wanted to understand, what is the real difference between
> bdrv_block_status_above and bdrv_is_allocated_above, IMHO
> bdrv_is_allocated_above should work through bdrv_block_status_above..
>
> And I found the pr
19.11.2019 15:02, Denis Lunev wrote:
> On 11/19/19 1:22 PM, Max Reitz wrote:
>> On 16.11.19 17:34, Vladimir Sementsov-Ogievskiy wrote:
>>> Hi all!
>>>
>>> I wanted to understand, what is the real difference between
>>> bdrv_block_status_above
>>> and bdrv_is_allocated_above, IMHO bdrv_is_allocated
Am 19.11.2019 um 12:35 hat Sergio Lopez geschrieben:
>
> Kevin Wolf writes:
>
> > Am 19.11.2019 um 11:54 hat Sergio Lopez geschrieben:
> >>
> >> Max Reitz writes:
> >>
> >> > On 13.11.19 14:24, Sergio Lopez wrote:
> >> >>
> >> >> Sergio Lopez writes:
> >> >>
> >> >>> no-re...@patchew.org w
19.11.2019 15:05, Kevin Wolf wrote:
> Am 16.11.2019 um 17:34 hat Vladimir Sementsov-Ogievskiy geschrieben:
>> Hi all!
>>
>> I wanted to understand, what is the real difference between
>> bdrv_block_status_above and bdrv_is_allocated_above, IMHO
>> bdrv_is_allocated_above should work through bdrv_bl
On 19.11.19 13:02, Denis V. Lunev wrote:
> On 11/19/19 1:22 PM, Max Reitz wrote:
>> On 16.11.19 17:34, Vladimir Sementsov-Ogievskiy wrote:
>>> Hi all!
>>>
>>> I wanted to understand, what is the real difference between
>>> bdrv_block_status_above
>>> and bdrv_is_allocated_above, IMHO bdrv_is_alloc
> -Original Message-
> From: Lukas Straub
> Sent: Thursday, November 14, 2019 12:36 AM
> To: qemu-devel
> Cc: Zhang, Chen ; Jason Wang
> ; Wen Congyang ;
> Xie Changlong ; Kevin Wolf
> ; Max Reitz ; qemu-block
>
> Subject: Re: [PATCH v7 0/4] colo: Add support for continuous replicatio
19.11.2019 15:20, Max Reitz wrote:
> On 19.11.19 13:02, Denis V. Lunev wrote:
>> On 11/19/19 1:22 PM, Max Reitz wrote:
>>> On 16.11.19 17:34, Vladimir Sementsov-Ogievskiy wrote:
Hi all!
I wanted to understand, what is the real difference between
bdrv_block_status_above
and
Kevin Wolf writes:
> Am 19.11.2019 um 12:35 hat Sergio Lopez geschrieben:
>>
>> Kevin Wolf writes:
>>
>> > Am 19.11.2019 um 11:54 hat Sergio Lopez geschrieben:
>> >>
>> >> Max Reitz writes:
>> >>
>> >> > On 13.11.19 14:24, Sergio Lopez wrote:
>> >> >>
>> >> >> Sergio Lopez writes:
>> >>
19.11.2019 15:17, Vladimir Sementsov-Ogievskiy wrote:
> 19.11.2019 15:05, Kevin Wolf wrote:
>> Am 16.11.2019 um 17:34 hat Vladimir Sementsov-Ogievskiy geschrieben:
>>> Hi all!
>>>
>>> I wanted to understand, what is the real difference between
>>> bdrv_block_status_above and bdrv_is_allocated_above
19.11.2019 15:32, Vladimir Sementsov-Ogievskiy wrote:
> 19.11.2019 15:17, Vladimir Sementsov-Ogievskiy wrote:
>> 19.11.2019 15:05, Kevin Wolf wrote:
>>> Am 16.11.2019 um 17:34 hat Vladimir Sementsov-Ogievskiy geschrieben:
Hi all!
I wanted to understand, what is the real difference be
19.11.2019 15:34, Vladimir Sementsov-Ogievskiy wrote:
> 19.11.2019 15:32, Vladimir Sementsov-Ogievskiy wrote:
>> 19.11.2019 15:17, Vladimir Sementsov-Ogievskiy wrote:
>>> 19.11.2019 15:05, Kevin Wolf wrote:
Am 16.11.2019 um 17:34 hat Vladimir Sementsov-Ogievskiy geschrieben:
> Hi all!
Am 19.11.2019 um 13:30 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 19.11.2019 15:20, Max Reitz wrote:
> > On 19.11.19 13:02, Denis V. Lunev wrote:
> >> On 11/19/19 1:22 PM, Max Reitz wrote:
> >>> On 16.11.19 17:34, Vladimir Sementsov-Ogievskiy wrote:
> Hi all!
>
> I wanted to und
9 09:17:24 +)
are available in the Git repository at:
https://gitlab.com/philmd/qemu.git tags/mips-next-20191119
for you to fetch changes up to abc7cf36559f953777faf27d2e0dfb561ac533a5:
hw/mips/gt64xxx: Remove dynamic field width from trace events (2019-11-19
14:4
Since not all trace backends support dynamic field width in
format (dtrace via stap does not), replace by a static field
width instead.
We previously passed to the trace API 'width << 1' as the number
of hex characters to display (the dynamic field width). We don't
need this anymore. Instead, disp
Since not all trace backends support dynamic field width in
format (dtrace via stap does not), replace by a static field
width instead.
We previously passed to the trace API 'width << 1' as the number
of hex characters to display (the dynamic field width). We don't
need this anymore. Instead, disp
Am 19.11.2019 um 13:17 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 19.11.2019 15:05, Kevin Wolf wrote:
> > Am 16.11.2019 um 17:34 hat Vladimir Sementsov-Ogievskiy geschrieben:
> >> Hi all!
> >>
> >> I wanted to understand, what is the real difference between
> >> bdrv_block_status_above and bdr
Am 16.11.2019 um 17:34 hat Vladimir Sementsov-Ogievskiy geschrieben:
> Hi all!
>
> I wanted to understand, what is the real difference between
> bdrv_block_status_above
> and bdrv_is_allocated_above, IMHO bdrv_is_allocated_above should work through
> bdrv_block_status_above..
>
> And I found the
On 2019/11/19 下午8:28, Zhang, Chen wrote:
-Original Message-
From: Lukas Straub
Sent: Thursday, November 14, 2019 12:36 AM
To: qemu-devel
Cc: Zhang, Chen ; Jason Wang
; Wen Congyang ;
Xie Changlong ; Kevin Wolf
; Max Reitz ; qemu-block
Subject: Re: [PATCH v7 0/4] colo: Add support f
On 11/19/19 5:21 PM, Stefan Hajnoczi wrote:
On Mon, Nov 18, 2019 at 11:27:44PM +0100, Philippe Mathieu-Daudé wrote:
This series fixes LP#1844817 [2].
(Eric noted in [1] the dtrace via stap backend can not support
the dynamic '*' width format.)
If they are trivial/block/tracing pull in preparat
On Mon, Nov 18, 2019 at 11:27:44PM +0100, Philippe Mathieu-Daudé wrote:
> This series fixes LP#1844817 [2].
>
> (Eric noted in [1] the dtrace via stap backend can not support
> the dynamic '*' width format.)
>
> If they are trivial/block/tracing pull in preparation, this
> series will be happy to
emote-tracking branch 'remotes/ericb/tags/pull-nbd-2019-11-19' into
> staging (2019-11-19 09:17:24 +)
>
> are available in the Git repository at:
>
> https://gitlab.com/philmd/qemu.git tags/mips-next-20191119
>
> for you to fetch changes up to abc7cf36559f953777f
On Sat, Nov 16, 2019 at 07:34:06PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> Hi all!
>
> I wanted to understand, what is the real difference between
> bdrv_block_status_above
> and bdrv_is_allocated_above, IMHO bdrv_is_allocated_above should work through
> bdrv_block_status_above..
>
> And I
Test 079 fails in the arm64, s390x and ppc64le LXD containers, which
apparently do not allow large files to be created. Test 079 tries to
create a 4G sparse file, so check first whether we can really create
such files before executing the test.
Signed-off-by: Thomas Huth
---
tests/qemu-iotests/0
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 to create huge files there (even
if they are just sparse), and
Test 060 fails in the arm64, s390x and ppc64le LXD containers, which
apparently do not allow large files to be created. The repair process
in test 060 creates a file of 64 GiB, so test first whether such large
files are possible and skip the test if that's not the case.
Signed-off-by: Thomas Huth
test-util-filemonitor fails in restricted non-x86 Travis containers
since they apparently blacklisted some required system calls there.
Let's simply skip the test if we detect such an environment.
Signed-off-by: Thomas Huth
---
tests/test-util-filemonitor.c | 11 +++
1 file changed, 11 i
From: Alex Bennée
The older clangs are still struggling to build and run everything
withing the 50 minute timeout so lets lighten the load a bit more. We
still have coverage for GCC and hopefully no obscure 32 bit guest only
breakages slip through the cracks.
Signed-off-by: Alex Bennée
Signed-o
In certain environments like restricted containers, we can not create
huge test images. To be able to use "make check" in such container
environments, too, let's skip the hd-geo-test instead of failing when
the test images could not be created.
Signed-off-by: Thomas Huth
---
tests/hd-geo-test.c
Travis recently added the possibility to test on these architectures,
too, so let's enable them in our travis.yml file to extend our test
coverage.
Unfortunately, the libssh in this Ubuntu version (bionic) is in a pretty
unusable Frankenstein state and libspice-server-dev is not available here,
so
19.11.2019 19:58, Stefan Hajnoczi wrote:
> On Sat, Nov 16, 2019 at 07:34:06PM +0300, Vladimir Sementsov-Ogievskiy wrote:
>> Hi all!
>>
>> I wanted to understand, what is the real difference between
>> bdrv_block_status_above
>> and bdrv_is_allocated_above, IMHO bdrv_is_allocated_above should work
On 11/19/19 6:08 PM, Thomas Huth wrote:
In certain environments like restricted containers, we can not create
huge test images. To be able to use "make check" in such container
environments, too, let's skip the hd-geo-test instead of failing when
the test images could not be created.
Signed-off-
On 11/19/19 6:08 PM, Thomas Huth wrote:
Test 079 fails in the arm64, s390x and ppc64le LXD containers, which
apparently do not allow large files to be created. Test 079 tries to
create a 4G sparse file, so check first whether we can really create
such files before executing the test.
Signed-off-
On 11/19/19 6:08 PM, Thomas Huth wrote:
test-util-filemonitor fails in restricted non-x86 Travis containers
since they apparently blacklisted some required system calls there.
Let's simply skip the test if we detect such an environment.
Signed-off-by: Thomas Huth
---
tests/test-util-filemonit
On 11/19/19 6:08 PM, Thomas Huth wrote:
From: Alex Bennée
The older clangs are still struggling to build and run everything
withing the 50 minute timeout so lets lighten the load a bit more. We
still have coverage for GCC and hopefully no obscure 32 bit guest only
breakages slip through the cra
On 19/11/2019 18.29, Philippe Mathieu-Daudé wrote:
> On 11/19/19 6:08 PM, Thomas Huth wrote:
>> Test 079 fails in the arm64, s390x and ppc64le LXD containers, which
>> apparently do not allow large files to be created. Test 079 tries to
>> create a 4G sparse file, so check first whether we can real
On 11/19/19 6:34 PM, Thomas Huth wrote:
On 19/11/2019 18.29, Philippe Mathieu-Daudé wrote:
On 11/19/19 6:08 PM, Thomas Huth wrote:
Test 079 fails in the arm64, s390x and ppc64le LXD containers, which
apparently do not allow large files to be created. Test 079 tries to
create a 4G sparse file, s
On Tue, Nov 19, 2019 at 06:38:20PM +0100, Philippe Mathieu-Daudé wrote:
> On 11/19/19 6:34 PM, Thomas Huth wrote:
> > On 19/11/2019 18.29, Philippe Mathieu-Daudé wrote:
> > > On 11/19/19 6:08 PM, Thomas Huth wrote:
> > > > Test 079 fails in the arm64, s390x and ppc64le LXD containers, which
> > > >
On 19/11/2019 18.50, Daniel P. Berrangé wrote:
> On Tue, Nov 19, 2019 at 06:38:20PM +0100, Philippe Mathieu-Daudé wrote:
>> On 11/19/19 6:34 PM, Thomas Huth wrote:
>>> On 19/11/2019 18.29, Philippe Mathieu-Daudé wrote:
On 11/19/19 6:08 PM, Thomas Huth wrote:
> Test 079 fails in the arm64,
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)
> >
> > nvme_set_timestamp(n, 0ULL);
> >
> > +n->aer_timer = timer_new_ns(QEMU_CLOCK_VIRTUA
On Tue, Nov 12, 2019 at 03:04:52PM +, Beata Michalska wrote:
> Hi Klaus,
>
>
> On Tue, 15 Oct 2019 at 11:45, Klaus Jensen wrote:
> > +if (!nsid || (nsid != 0x && nsid > n->num_namespaces)) {
> > +trace_nvme_err_invalid_ns(nsid, n->num_namespaces);
> > +return NVME
The following changes since commit f086f22d6c068ba151b0f6e81e75a64f130df712:
Merge remote-tracking branch 'remotes/awilliam/tags/vfio-fixes-20191118.0'
into staging (2019-11-18 21:35:48 +)
are available in the Git repository at:
https://github.com/stefanha/qemu.git tags/tracing-pull-req
From: Philippe Mathieu-Daudé
Since not all trace backends support dynamic field width in
format (dtrace via stap does not), replace by a static field
width instead.
We previously passed to the trace API 'width << 1' as the number
of hex characters to display (the dynamic field width). We don't
n
From: Philippe Mathieu-Daudé
Since not all trace backends support dynamic field width in
format (dtrace via stap does not), replace by a static field
width instead.
We previously passed to the trace API 'width << 1' as the number
of hex characters to display (the dynamic field width). We don't
n
On Tue, Nov 19, 2019 at 9:46 PM Stefan Hajnoczi wrote:
>
> The following changes since commit f086f22d6c068ba151b0f6e81e75a64f130df712:
>
> Merge remote-tracking branch 'remotes/awilliam/tags/vfio-fixes-20191118.0'
> into staging (2019-11-18 21:35:48 +)
>
> are available in the Git reposito
On Tue, Nov 19, 2019 at 10:14 PM Aleksandar Markovic
wrote:
>
> On Tue, Nov 19, 2019 at 9:46 PM Stefan Hajnoczi wrote:
> >
> > The following changes since commit f086f22d6c068ba151b0f6e81e75a64f130df712:
> >
> > Merge remote-tracking branch
> > 'remotes/awilliam/tags/vfio-fixes-20191118.0' int
> -Original Message-
> From: Jason Wang
> Sent: Tuesday, November 19, 2019 11:03 PM
> To: Zhang, Chen ; Lukas Straub
> ; qemu-devel
> Cc: Kevin Wolf ; qemu-block bl...@nongnu.org>; Wen Congyang ; Max
> Reitz ; Xie Changlong
> Subject: Re: [PATCH v7 0/4] colo: Add support for continuou
Patchew URL:
https://patchew.org/QEMU/20191119204551.240792-1-stefa...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [PULL for-4.2-rc2 0/2] Tracing patches
Type: series
Message-id: 20191119204551.240792-1-stefa...@redhat.
54 matches
Mail list logo