On 26.02.2021 18:07, Tim Deegan wrote:
> At 14:03 +0100 on 25 Feb (1614261809), Jan Beulich wrote:
>> When none of the physical address bits in PTEs are reserved, we can't
>> create any 4k (leaf) PTEs which would trigger reserved bit faults. Hence
>> the present SHOPT_FAST_FAULT_PATH machinery need
On 01.03.2021 03:18, Tian, Kevin wrote:
>> From: Roger Pau Monné
>> Sent: Thursday, February 11, 2021 8:27 PM
>>
>> On Thu, Feb 11, 2021 at 12:22:41PM +0100, Jan Beulich wrote:
>>> On 11.02.2021 12:16, Roger Pau Monné wrote:
On Thu, Feb 11, 2021 at 11:36:59AM +0100, Jan Beulich wrote:
> O
On 01.03.2021 03:34, Tian, Kevin wrote:
>> From: Jan Beulich
>> Sent: Monday, February 22, 2021 6:57 PM
>>
>> The address of this page is used by the CPU only to recognize when to
>> access the virtual APIC page instead. No accesses would ever go to this
>> page. It only needs to be present in the
While we've long done away with CONFIG_SMP, we still allow
CONFIG_NR_CPUS to be set to 1. Hence at least randconfig builds
may fail, and the first of the two issues addressed was actually
observed in the RISC-V bring-up work. I didn't check whether Arm
would also have issues like these.
1: sched:
> From: Jan Beulich
> Sent: Monday, March 1, 2021 4:16 PM
>
> On 01.03.2021 03:18, Tian, Kevin wrote:
> >> From: Roger Pau Monné
> >> Sent: Thursday, February 11, 2021 8:27 PM
> >>
> >> On Thu, Feb 11, 2021 at 12:22:41PM +0100, Jan Beulich wrote:
> >>> On 11.02.2021 12:16, Roger Pau Monné wrote:
In this case the compiler is recognizing that no valid array indexes
remain, and hence e.g. reports:
core.c: In function 'cpu_schedule_up':
core.c:2769:19: error: array subscript 1 is above array bounds
of 'struct vcpu *[1]' [-Werror=array-bounds]
2769 | if ( idle_vcpu[cpu] == NULL )
|
In this case the compiler is recognizing that no valid array indexes
remain (in x2apic_cluster()'s access to per_cpu(cpu_2_logical_apicid,
...)), but oddly enough isn't really consistent about the checking it
does (see the code comment).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/genapic/x2ap
On 01.03.2021 09:27, Jan Beulich wrote:
> While we've long done away with CONFIG_SMP, we still allow
> CONFIG_NR_CPUS to be set to 1. Hence at least randconfig builds
> may fail, and the first of the two issues addressed was actually
> observed in the RISC-V bring-up work. I didn't check whether Ar
On 26.02.2021 23:48, Stefano Stabellini wrote:
> On Fri, 26 Feb 2021, Andrew Cooper wrote:
>> Looks like a copy&paste error.
>>
>> Fixes: f6e1d8515d7 ("automation: add alpine linux x86 build jobs")
>> Signed-off-by: Andrew Cooper
>
> Thanks for the patch and of course it is correct
>
> Acked-by:
On Fri, Feb 26, 2021 at 02:24:43PM +0100, Jan Beulich wrote:
> On 26.02.2021 09:59, Roger Pau Monne wrote:
> > The current build of the firmware relies on having 32bit compatible
> > headers installed in order to build some of the 32bit firmware, but
> > that usually requires multilib support and i
On 26.02.2021 23:52, Stefano Stabellini wrote:
> Introduce two feature flags to tell the domain whether it is
> direct-mapped or not. It allows the guest kernel to make informed
> decisions on things such as swiotlb-xen enablement.
>
> The introduction of both flags (XENFEAT_direct_mapped and
> XE
On 01.03.2021 10:07, Roger Pau Monné wrote:
> On Fri, Feb 26, 2021 at 02:24:43PM +0100, Jan Beulich wrote:
>> On 26.02.2021 09:59, Roger Pau Monne wrote:
>>> The current build of the firmware relies on having 32bit compatible
>>> headers installed in order to build some of the 32bit firmware, but
>
Hi Jan,
On 26/02/2021 13:30, Jan Beulich wrote:
On 26.02.2021 11:56, Julien Grall wrote:
From: Julien Grall
The new x86 IOMMU page-tables allocator will release the pages when
relinquishing the domain resources. However, this is not sufficient
when the domain is dying because nothing prevents
Hi Stefano,
On 26/02/2021 22:52, Stefano Stabellini wrote:
Introduce two feature flags to tell the domain whether it is
direct-mapped or not. It allows the guest kernel to make informed
decisions on things such as swiotlb-xen enablement.
The introduction of both flags (XENFEAT_direct_mapped and
On Mon, Mar 01, 2021 at 09:58:48AM +0100, Jan Beulich wrote:
> On 26.02.2021 23:48, Stefano Stabellini wrote:
> > On Fri, 26 Feb 2021, Andrew Cooper wrote:
> >> Looks like a copy&paste error.
> >>
> >> Fixes: f6e1d8515d7 ("automation: add alpine linux x86 build jobs")
> >> Signed-off-by: Andrew Coo
flight 159790 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159790/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
On Mon, Mar 01, 2021 at 10:17:32AM +0100, Jan Beulich wrote:
> On 01.03.2021 10:07, Roger Pau Monné wrote:
> > On Fri, Feb 26, 2021 at 02:24:43PM +0100, Jan Beulich wrote:
> >> On 26.02.2021 09:59, Roger Pau Monne wrote:
> >>> The current build of the firmware relies on having 32bit compatible
> >>
clang++ relies on the C++ headers installed by g++, or else a clang
build will hit the following error:
:3:10: fatal error: 'cstring' file not found
#include "cstring"
^
1 error generated.
make[10]: *** [Makefile:120: headers++.chk] Error 1
Reported-by: Stefano Stabellini
Signed
clang++ relies on the C++ headers installed by g++, or else a clang
build will hit the following error:
:3:10: fatal error: 'cstring' file not found
#include "cstring"
^
1 error generated.
make[10]: *** [Makefile:120: headers++.chk] Error 1
Reported-by: Stefano Stabellini
Signed
On 01.03.2021 09:30, Tian, Kevin wrote:
>> From: Jan Beulich
>> Sent: Monday, March 1, 2021 4:16 PM
>>
>> On 01.03.2021 03:18, Tian, Kevin wrote:
From: Roger Pau Monné
Sent: Thursday, February 11, 2021 8:27 PM
On Thu, Feb 11, 2021 at 12:22:41PM +0100, Jan Beulich wrote:
>
On 01.03.2021 10:50, Roger Pau Monné wrote:
> On Mon, Mar 01, 2021 at 10:17:32AM +0100, Jan Beulich wrote:
>> On 01.03.2021 10:07, Roger Pau Monné wrote:
>>> On Fri, Feb 26, 2021 at 02:24:43PM +0100, Jan Beulich wrote:
On 26.02.2021 09:59, Roger Pau Monne wrote:
> The current build of the
flight 159787 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159787/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail REGR. vs. 152631
test-amd64-amd64
On Mon, Mar 01, 2021 at 11:05:17AM +0100, Jan Beulich wrote:
> On 01.03.2021 10:50, Roger Pau Monné wrote:
> > On Mon, Mar 01, 2021 at 10:17:32AM +0100, Jan Beulich wrote:
> >> On 01.03.2021 10:07, Roger Pau Monné wrote:
> >>> On Fri, Feb 26, 2021 at 02:24:43PM +0100, Jan Beulich wrote:
> On 2
Hi all,
The proposed agenda is in
https://cryptpad.fr/pad/#/2/pad/edit/fBjznQlGYGcHwqT0-Mu+l260/ and you can edit
to add items. Alternatively, you can reply to this mail directly.
Agenda items appreciated a few days before the call: please put your name
besides items if you edit the document
I am going to be cutting this RC shortly. So please don't commit
anything now, even fixes which already have a release-ack.
Ian.
Am 25.02.2021 um 18:32 hat Jim Fehlig geschrieben:
> Adding xen-devel and Ian to cc.
>
> On 2/24/21 6:11 AM, Daniel P. Berrangé wrote:
> > The following features have been deprecated for well over the 2
> > release cycle we promise
>
> This reminded me of a bug report we received late last year w
On Mon, Mar 01, 2021 at 09:31:07AM +0100, Jan Beulich wrote:
> In this case the compiler is recognizing that no valid array indexes
> remain (in x2apic_cluster()'s access to per_cpu(cpu_2_logical_apicid,
> ...)), but oddly enough isn't really consistent about the checking it
> does (see the code co
On Sun, Feb 28, 2021 at 2:49 AM Boris Ostrovsky
wrote:
>
>
> On 2/24/21 1:47 PM, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > The ACPI_DEBUG_PRINT() macro is used in a few places in
> > xen-acpi-cpuhotplug.c and xen-acpi-memhotplug.c for printing debug
> > messages, but that is qu
flight 159788 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159788/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail pass in
159779
Tests which did not succ
> On Feb 24, 2021, at 11:37 PM, Volodymyr Babchuk
> wrote:
>
>
>> Hypervisor/virt properties are different to both a kernel-only-RTOS, and
>> regular usespace. This was why I gave you some specific extra scenarios
>> to do latency testing with, so you could make a fair comparison of
>> "extr
Xen 4.15 RC1 is now available.
It is available from git:
git clone https://xenbits.xenproject.org/git-http/xen.git -b 4.15.0-rc1
For your convenience a tarball is available:
https://downloads.xenproject.org/release/xen/4.15.0-rc1/xen-4.15.0-rc1.tar.gz
https://downloads.xenproject.org/relea
On 01.03.2021 15:01, Roger Pau Monné wrote:
> On Mon, Mar 01, 2021 at 09:31:07AM +0100, Jan Beulich wrote:
>> In this case the compiler is recognizing that no valid array indexes
>> remain (in x2apic_cluster()'s access to per_cpu(cpu_2_logical_apicid,
>> ...)), but oddly enough isn't really consist
Jan Beulich writes ("[PATCH 1/2][4.15?] sched: fix build when NR_CPUS == 1"):
> In this case the compiler is recognizing that no valid array indexes
> remain, and hence e.g. reports:
Release-Acked-by: Ian Jackson
Jan Beulich writes ("[PATCH 2/2][4.15?] x86: fix build when NR_CPUS == 1"):
> In this case the compiler is recognizing that no valid array indexes
> remain (in x2apic_cluster()'s access to per_cpu(cpu_2_logical_apicid,
> ...)), but oddly enough isn't really consistent about the checking it
> does (
Andrew Cooper writes ("[PATCH 3/3] automation: Annotate that a 32bit libc is no
longer a dependency"):
> We can't drop the 32bit libc from the existing containers, because they are
> used on older Xen branches as well.
>
> However, we can avoid the dependency being propagated into newer conainers
Ian Jackson writes ("Commit moratorium for Xen 4.15.0-rc1"):
> I am going to be cutting this RC shortly. So please don't commit
> anything now, even fixes which already have a release-ack.
The moratorium is lifted. You may commit patches again. Note that
the freeze is still in force: every chan
Andrew Cooper writes ("[PATCH 2/3] tools/firmware: Build firmware as
-ffreestanding"):
> firmware should always have been -ffreestanding, as it doesn't execute in the
> host environment.
>
> inttypes.h isn't a freestanding header, but the 32bitbios_support.c only wants
> the stdint.h types so swi
Andrew Cooper writes ("[PATCH for-4.15] cirrus-ci: Drop obsolete dependency"):
> markdown as a dependency was dropped in 4.12
>
> Fixes: 5d94433a66 ("cirrus-ci: introduce some basic FreeBSD testing")
> Signed-off-by: Andrew Cooper
Release-Acked-by: Ian Jackson
Andrew Cooper writes ("[PATCH 1/3] tools/hvmloader: Drop machelf include as
well"):
> The logic behind switching to elfstructs applies to sun builds as well.
>
> Fixes: 81b2b328a2 ("hvmloader: use Xen private header for elf structs")
> Signed-off-by: Andrew Cooper
I would have preferred this pa
On 3/1/21 9:11 AM, Rafael J. Wysocki wrote:
> On Sun, Feb 28, 2021 at 2:49 AM Boris Ostrovsky
> wrote:
>>
>> On 2/24/21 1:47 PM, Rafael J. Wysocki wrote:
>>> From: Rafael J. Wysocki
>>>
>>> The ACPI_DEBUG_PRINT() macro is used in a few places in
>>> xen-acpi-cpuhotplug.c and xen-acpi-memhotplug
Introduce an option to allow selecting the legacy behavior for
accesses to MSRs not explicitly handled. Since commit
84e848fd7a162f669 and 322ec7c89f6640e accesses to MSRs not explicitly
handled by Xen result in the injection of a #GP to the guest. This is
a behavior change since previously a #GP w
On 01/03/2021 16:16, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH 1/3] tools/hvmloader: Drop machelf include as
> well"):
>> The logic behind switching to elfstructs applies to sun builds as well.
>>
>> Fixes: 81b2b328a2 ("hvmloader: use Xen private header for elf structs")
>> Signed-off-by:
On Fri, Feb 26, 2021 at 12:46:47PM +, Andrew Cooper wrote:
> markdown as a dependency was dropped in 4.12
>
> Fixes: 5d94433a66 ("cirrus-ci: introduce some basic FreeBSD testing")
> Signed-off-by: Andrew Cooper
Urg, I should update my list of dependencies.
Reviewed-by: Roger Pau Monné
Wil
Support in-tree ABI checking for stable libs.
This series highlights a regression from 4.14, which needs fixing before the
3rd patch can be committed.
abi-compliance-checker reports:
Removed Symbols 3
xentoolcore_internal.h
xentoolcore__deregister_active_handle ( Xentoolcore__Active
This will be optional. No functional change
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
---
config/Tools.mk.in | 1 +
tools/configure| 41 +
tools/configure.ac | 1 +
3 files changed, 43 insertions(+)
diff --git a/config/Tools.mk
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
CC: Juergen Gross
---
tools/libs/.gitignore | 2 ++
tools/libs/libs.mk| 15 +++
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/tools/libs/.gitignore b/tools/libs/.gitignore
index 4a13126144..655f46a6
Roger Pau Monne writes ("[PATCH RFC for-4.15] x86/msr: introduce an option for
legacy MSR behavior selection"):
> Introduce an option to allow selecting the legacy behavior for
> accesses to MSRs not explicitly handled. Since commit
> 84e848fd7a162f669 and 322ec7c89f6640e accesses to MSRs not expl
Andrew Cooper writes ("[PATCH 1/3] tools: Check for abi-compliance-checker in
./configure"):
> This will be optional. No functional change
Release-Acked-by: Ian Jackson
Andrew Cooper writes ("[PATCH 2/3] tools/libs: Stash the 4.14 API/ABIs for the
stable libraries"):
> These dumps were produced from the RELEASE-4.14.0 tag, with the abi-dumper
> tooling backported from staging.
>
> For each stable library, add a PKG_OLD_ABI variable pointing at the 4.14 ABI.
>
>
Roger Pau Monne writes ("[PATCH for-4.15] automation/alpine: add g++ to the
list of build depends"):
> clang++ relies on the C++ headers installed by g++, or else a clang
> build will hit the following error:
>
> :3:10: fatal error: 'cstring' file not found
> #include "cstring"
> ^~~
Roger Pau Monne writes ("[PATCH for-4.15 2/3] firmware: provide a stand alone
set of headers"):
> The current build of the firmware relies on having 32bit compatible
> headers installed in order to build some of the 32bit firmware, but
> that usually requires multilib support and installing a i386
Jan Beulich writes ("Re: [PATCH][4.15] x86/shadow: replace bogus return path in
shadow_get_page_from_l1e()"):
> On 26.02.2021 16:08, Jan Beulich wrote:
> > Prior to be640b1800bb ("x86: make get_page_from_l1e() return a proper
> > error code") a positive return value did indicate an error. Said com
Andrew Cooper writes ("Re: [PATCH][4.15] x86/shadow: replace bogus return path
in shadow_get_page_from_l1e()"):
> On 26/02/2021 15:08, Jan Beulich wrote:
> > Prior to be640b1800bb ("x86: make get_page_from_l1e() return a proper
> > error code") a positive return value did indicate an error. Said c
On 01/03/2021 17:00, Andrew Cooper wrote:
> Support in-tree ABI checking for stable libs.
>
> This series highlights a regression from 4.14, which needs fixing before the
> 3rd patch can be committed.
>
> abi-compliance-checker reports:
>
> Removed Symbols 3
> xentoolcore_internal.h
>
Jan Beulich writes ("Re: [PATCH][4.15] x86/shadow: suppress "fast fault path"
optimization without reserved bits"):
> On 26.02.2021 18:07, Tim Deegan wrote:
> > Yes, I think it could be reduced to use just one reserved address bit.
> > IIRC we just used such a large mask so the magic entries would
On 01/03/2021 17:30, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH][4.15] x86/shadow: suppress "fast fault path"
> optimization without reserved bits"):
>> On 26.02.2021 18:07, Tim Deegan wrote:
>>> Yes, I think it could be reduced to use just one reserved address bit.
>>> IIRC we just used
Hubert Jasudowicz writes ("[PATCH] tools: Improve signal handling in
xen-vmtrace"):
> Make sure xen-vmtrace exits cleanly in case SIGPIPE is sent. This can
> happen when piping the output to some other program.
>
> Additionaly, add volatile qualifier to interrupted flag to avoid
> it being optimi
Andrew Cooper writes ("Re: [PATCH] tools: Improve signal handling in
xen-vmtrace"):
> In which case, what other signals potentially need dealing with? Lets
> get them all fixed in one go.
>
> When that's done, we should make it installed by default, to match its
> expected usecase.
With my tool
Julien Grall writes ("[PATCH for-4.15] tools/xenstored: Avoid dereferencing a
NULL pointer if LiveUpdate is failing"):
> From: Julien Grall
>
> In case of failure in do_lu_start(), XenStored will first free lu_start
> and then try to dereference it.
>
> This will result to a NULL dereference as
flight 159789 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159789/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
Andrew Cooper writes ("Re: [PATCH][4.15] x86/shadow: suppress "fast fault path"
optimization without reserved bits"):
> On 01/03/2021 17:30, Ian Jackson wrote:
> > Jan Beulich writes ("Re: [PATCH][4.15] x86/shadow: suppress "fast fault
> > path" optimization without reserved bits"):
> >> On 26.02
On Mon, 2021-03-01 at 15:57 +, Ian Jackson wrote:
> Jan Beulich writes ("[PATCH 1/2][4.15?] sched: fix build when NR_CPUS
> == 1"):
> > In this case the compiler is recognizing that no valid array
> > indexes
> > remain, and hence e.g. reports:
>
> Release-Acked-by: Ian Jackson
>
Reviewed-by:
On Mon, Mar 01, 2021 at 05:16:34PM +, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH RFC for-4.15] x86/msr: introduce an option
> for legacy MSR behavior selection"):
> > Introduce an option to allow selecting the legacy behavior for
> > accesses to MSRs not explicitly handled. Since com
Roger Pau Monné writes ("Re: [PATCH RFC for-4.15] x86/msr: introduce an option
for legacy MSR behavior selection"):
> On Mon, Mar 01, 2021 at 05:16:34PM +, Ian Jackson wrote:
> > So AIUI this patch is to make it possible for Xen 4.15 to behave like
> > Xen 4.14, thus avoiding a regression for
On 01/03/2021 09:58, Roger Pau Monne wrote:
> clang++ relies on the C++ headers installed by g++, or else a clang
> build will hit the following error:
>
> :3:10: fatal error: 'cstring' file not found
> #include "cstring"
> ^
> 1 error generated.
> make[10]: *** [Makefile:120: head
On Mon, Mar 01, 2021 at 04:14:26PM +0100, Jan Beulich wrote:
> On 01.03.2021 15:01, Roger Pau Monné wrote:
> > On Mon, Mar 01, 2021 at 09:31:07AM +0100, Jan Beulich wrote:
> >> In this case the compiler is recognizing that no valid array indexes
> >> remain (in x2apic_cluster()'s access to per_cpu(
Hi,
I have tagged the e-mail with 4.15 as I think we likely want some of the
patches to be in the next release.
As a minimum, we get the following:
- patch #7: xenstore: handle do_mkdir and do_rm failure
- patch #8: xenstore: add missing NULL check
- patch #10: xs: add error handling
Th
On 01/03/2021 17:59, Andrew Cooper wrote:
> On 01/03/2021 09:58, Roger Pau Monne wrote:
>> clang++ relies on the C++ headers installed by g++, or else a clang
>> build will hit the following error:
>>
>> :3:10: fatal error: 'cstring' file not found
>> #include "cstring"
>> ^
>> 1 e
flight 159793 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159793/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 159792 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159792/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0996a7883c6dd939d6e769b1ce1fd2b2e250bcfb
baseline version:
ovmf 31eaefd4df78d58ad4087
On 01.03.21 17:16, Boris Ostrovsky wrote:
On 3/1/21 9:11 AM, Rafael J. Wysocki wrote:
On Sun, Feb 28, 2021 at 2:49 AM Boris Ostrovsky
wrote:
On 2/24/21 1:47 PM, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki
The ACPI_DEBUG_PRINT() macro is used in a few places in
xen-acpi-cpuhotplug.c a
On 26.02.21 19:26, Julien Grall wrote:
From: Julien Grall
In case of failure in do_lu_start(), XenStored will first free lu_start
and then try to dereference it.
This will result to a NULL dereference as the destruction callback will
set lu_start to NULL.
The crash can be avoided by freeing l
On 3/1/21 11:23 AM, Roger Pau Monne wrote:
> Introduce an option to allow selecting the legacy behavior for
> accesses to MSRs not explicitly handled. Since commit
> 84e848fd7a162f669 and 322ec7c89f6640e accesses to MSRs not explicitly
> handled by Xen result in the injection of a #GP to the gues
On 01/03/2021 18:01, Julien Grall wrote:
> Hi,
>
> I have tagged the e-mail with 4.15 as I think we likely want some of
> the patches to be in the next release.
>
> As a minimum, we get the following:
> - patch #7: xenstore: handle do_mkdir and do_rm failure
> - patch #8: xenstore: add missing
Hello:
This patch was applied to netdev/net.git (refs/heads/master):
On Thu, 25 Feb 2021 16:39:01 +0100 you wrote:
> shinfo already holds the result of skb_shinfo(skb) at this point - no
> need to re-invoke the construct even twice.
>
> Signed-off-by: Jan Beulich
Here is the summary with links
flight 159791 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159791/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail REGR. vs. 152631
test-amd64-amd64
Hello,
On Fri, Feb 26, 2021 at 10:39:27PM +, Andy Smith wrote:
> just lately I've been sporadically having issues where dom0 blocks
> or severely slows down on all access to the particular md device
> that hosts all domU block devices.
This just happened again on the same server as the previo
flight 159794 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159794/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
flight 159797 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159797/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 26.02.21 15:41, Norbert Manthey wrote:
In case of allocation error, we should not dereference the obtained
NULL pointer. Hence, fail early.
This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.
Signed-off-by: Norbert Manthey
Reviewed-b
On 26.02.21 15:41, Norbert Manthey wrote:
Use the correct format specifier for unsigned values. Additionally, a
cast was dropped, as the format specifier did not require it anymore.
This was reported by analysis with cppcheck.
Signed-off-by: Norbert Manthey
Reviewed-by: Thomas Friebel
Reviewe
On 26.02.21 15:41, Norbert Manthey wrote:
When passing format strings to the trace function, allow gcc to analyze
those and warn on issues.
Signed-off-by: Norbert Manthey
Reviewed-by: Thomas Friebel
Reviewed-by: Julien Grall
Reviewed-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9DD628BF132
On 26.02.21 15:41, Norbert Manthey wrote:
In case a command fails, also free the memory. As this is for the CLI
client, currently the leaked memory is freed right after receiving the
error, as the application terminates next.
Similarly, if the allocation fails, do not use the NULL pointer
afterw
On 26.02.21 15:41, Norbert Manthey wrote:
In rare cases, the path to the daemon socket cannot be created as it is
longer than PATH_MAX. Instead of failing with a NULL pointer dereference,
terminate the application with an error message.
This bug was discovered and resolved using Coverity Static
On 26.02.21 15:41, Norbert Manthey wrote:
In the out of memory case, we might return a NULL pointer when
canonicalizing node names. This NULL pointer is not checked when
creating a directory, or when removing a node. This change handles
the NULL pointer for these two cases.
This bug was discover
On 26.02.21 15:41, Norbert Manthey wrote:
From: Michael Kurth
In case of allocation error, we should not dereference the obtained
NULL pointer.
This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.
Signed-off-by: Michael Kurth
Signed-of
On 26.02.21 15:41, Norbert Manthey wrote:
When starting the daemon, we might see a NULL pointer instead of the
path to the socket.
Only relevant in case we start the process in a very deep directory
path, with a length close to 4096 so that appending "/socket" would
exceed the limit. Hence, such
On 26.02.21 15:41, Norbert Manthey wrote:
In case of a failure deep in the call tree, we might return NULL as the
value of the domain. In that case, error out instead of dereferencing
the NULL pointer.
This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by
On 26.02.21 16:36, Andrew Cooper wrote:
On 26/02/2021 14:41, Norbert Manthey wrote:
The read value could be larger than a signed 32bit integer. As -1 is
used as error value, we should not rely on using the full 32 bits.
Hence, when reading the port number, we should make sure we only return
vali
flight 159795 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159795/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 159788
test-armhf-armhf-libvirt 16 save
flight 159799 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159799/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
On 3/2/21 6:15 AM, Jürgen Groß wrote:
> On 26.02.21 16:36, Andrew Cooper wrote:
>> On 26/02/2021 14:41, Norbert Manthey wrote:
>>> The read value could be larger than a signed 32bit integer. As -1 is
>>> used as error value, we should not rely on using the full 32 bits.
>>> Hence, when reading the
92 matches
Mail list logo
