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:
> -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
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'
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
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
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
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
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
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 =
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 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 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,
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
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
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
---
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.
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.
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
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,
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
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
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
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
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 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
---
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
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 abc7cf36559f953777faf27d2e0df
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
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
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
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
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
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,
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,
+)
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:46:01 +0100
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
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!
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
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
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: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
> -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
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
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
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
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
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 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
>>
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:
>>
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/
>
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
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:
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
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
54 matches
Mail list logo
