flight 179511 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/179511/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pair25 guest-start/debian fail REGR. vs. 178042
test-amd64-amd64-fr
flight 179509 xen-unstable real [real]
flight 179512 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/179509/
http://logs.test-lab.xenproject.org/osstest/logs/179512/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
Hello Jan,
Jan Beulich writes:
> On 21.02.2023 00:13, Volodymyr Babchuk wrote:
>> Stefano Stabellini writes:
>>> On Wed, 31 Aug 2022, Volodymyr Babchuk wrote:
As pci devices are refcounted now and all list that store them are
protected by separate locks, we can safely drop global pc
On Wed, Mar 08, 2023 at 04:50:51PM +0100, Jan Beulich wrote:
> On 08.03.2023 16:23, Elliott Mitchell wrote:
> > Mostly SSIA. As originally identified by "Neowutran", appears Xen's
> > x2apic wrapper implementation fails with current generation AMD hardware
> > (Ryzen 7xxx/Zen 4). This can be work
flight 179506 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/179506/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pair25 guest-start/debian fail REGR. vs. 178042
test-amd64-amd64-xl
flight 179510 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/179510/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 69da506c927f8092ea8f783a092a694a3582e3ef
baseline version:
ovmf 75fb0cfc8237690624338
On Wed, 2023-03-08 at 16:33 +0100, Jan Beulich wrote:
> On 07.03.2023 16:50, Oleksii Kurochko wrote:
> > @@ -1166,12 +1167,9 @@ void cpuid_hypervisor_leaves(const struct
> > vcpu *v, uint32_t leaf,
> >
> > void do_invalid_op(struct cpu_user_regs *regs)
> > {
> > - const struct bug_frame *bug
flight 179505 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/179505/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass
test-amd64-i386-libvirt-xsm 15 migrate-s
On Wed, 2023-03-08 at 16:27 +0100, Jan Beulich wrote:
> On 07.03.2023 16:50, Oleksii Kurochko wrote:
> > --- a/xen/arch/arm/include/asm/bug.h
> > +++ b/xen/arch/arm/include/asm/bug.h
> > @@ -1,6 +1,8 @@
> > #ifndef __ARM_BUG_H__
> > #define __ARM_BUG_H__
> >
> > +#include
> > +
> > #if define
On Wed, 2023-03-08 at 16:06 +0100, Jan Beulich wrote:
> On 07.03.2023 16:50, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/common/bug.c
> > @@ -0,0 +1,104 @@
> > +#include
> > +#include
>
> Isn't it asm/bug.h now which is to include this header, if needed at
> all?
You are right it wil
On Wed, Mar 8, 2023 at 11:26 AM Jason Andryuk wrote:
>
> On Thu, Dec 15, 2022 at 8:54 AM Mattijs Korpershoek
> wrote:
> >
> > On Fri, Dec 09, 2022 at 09:26, Jason Andryuk wrote:
> >
> > > xen kbdfront registers itself as being able to deliver *any* key since
> > > it doesn't know what keys the b
On Thu, Dec 15, 2022 at 8:54 AM Mattijs Korpershoek
wrote:
>
> On Fri, Dec 09, 2022 at 09:26, Jason Andryuk wrote:
>
> > xen kbdfront registers itself as being able to deliver *any* key since
> > it doesn't know what keys the backend may produce.
> >
> > Unfortunately, the generated modalias gets
On Wed, 2023-03-08 at 16:17 +0100, Jan Beulich wrote:
> On 08.03.2023 15:54, Oleksii wrote:
> > Actually after my latest experiments it looks that we don't need to
> > calculate that things at all because for RISC-V it is used
> > everywhere
> > PC-relative access.
> > Thereby it doesn't matter wh
On 08.03.2023 16:23, Elliott Mitchell wrote:
> Mostly SSIA. As originally identified by "Neowutran", appears Xen's
> x2apic wrapper implementation fails with current generation AMD hardware
> (Ryzen 7xxx/Zen 4). This can be worked around by passing "x2apic=false"
> on Xen's command-line, though I
flight 179508 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/179508/
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 08/03/2023 3:23 pm, Elliott Mitchell wrote:
> Mostly SSIA. As originally identified by "Neowutran", appears Xen's
> x2apic wrapper implementation fails with current generation AMD hardware
> (Ryzen 7xxx/Zen 4). This can be worked around by passing "x2apic=false"
> on Xen's command-line, though
On 07.03.2023 16:50, Oleksii Kurochko wrote:
> @@ -1166,12 +1167,9 @@ void cpuid_hypervisor_leaves(const struct vcpu *v,
> uint32_t leaf,
>
> void do_invalid_op(struct cpu_user_regs *regs)
> {
> -const struct bug_frame *bug = NULL;
> u8 bug_insn[2];
> -const char *prefix = "", *fi
On 07.03.2023 16:50, Oleksii Kurochko wrote:
> --- a/xen/arch/arm/include/asm/bug.h
> +++ b/xen/arch/arm/include/asm/bug.h
> @@ -1,6 +1,8 @@
> #ifndef __ARM_BUG_H__
> #define __ARM_BUG_H__
>
> +#include
> +
> #if defined(CONFIG_ARM_32)
> # include
> #elif defined(CONFIG_ARM_64)
> @@ -9,10
Mostly SSIA. As originally identified by "Neowutran", appears Xen's
x2apic wrapper implementation fails with current generation AMD hardware
(Ryzen 7xxx/Zen 4). This can be worked around by passing "x2apic=false"
on Xen's command-line, though I'm wondering about the performance impact.
There has
On 08.03.2023 15:54, Oleksii wrote:
> Actually after my latest experiments it looks that we don't need to
> calculate that things at all because for RISC-V it is used everywhere
> PC-relative access.
> Thereby it doesn't matter what is an address where Xen was loaded and
> linker address.
> Right
On 07.03.2023 16:50, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/common/bug.c
> @@ -0,0 +1,104 @@
> +#include
> +#include
Isn't it asm/bug.h now which is to include this header, if needed at all?
> --- /dev/null
> +++ b/xen/include/xen/bug.h
> @@ -0,0 +1,158 @@
> +#ifndef __XEN_BUG_H__
On Mon, 2023-02-27 at 17:45 +, Julien Grall wrote:
> Hi,
>
> On 27/02/2023 17:17, Oleksii wrote:
> > On Sat, 2023-02-25 at 18:05 +, Julien Grall wrote:
> > > Hi,
> > >
> > > On 24/02/2023 15:06, Oleksii Kurochko wrote:
> > > > Calculate load and linker linker image addresses and
> > > > s
On 08.03.2023 12:54, Matias Ezequiel Vara Larsen wrote:
> On Tue, Mar 07, 2023 at 11:12:00AM +0100, Jan Beulich wrote:
>> On 06.03.2023 15:23, Matias Ezequiel Vara Larsen wrote:
>>> - Xen shall use the "stats_active" field to indicate what it is producing.
>>> In
>>> this field, reserved bits sh
flight 179503 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/179503/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail pass
in 179451
Tests which did not suc
On Tue, Mar 07, 2023 at 11:12:00AM +0100, Jan Beulich wrote:
> On 06.03.2023 15:23, Matias Ezequiel Vara Larsen wrote:
> > Regarding your email, I have the following comments:
> >
> > - I still do not know how to choose the value of cacheline_size. I
> > understand
> > this value shall be between
On 08.03.2023 11:49, Michal Orzel wrote:
> Despite being a matter of taste, in general, there are two main approaches
> when dealing with code tagging: tree-wide, where all the sources are taken
> into account or config-wide, when considering Kconfig options and actually
> built files. At the momen
On 08.03.2023 11:37, George Dunlap wrote:
> On Fri, Mar 3, 2023 at 7:29 AM Jan Beulich wrote:
>
>> While provable that length[0] is always initialized (because symCount
>> cannot be zero), upcoming gcc13 fails to recognize this and warns about
>> the unconditional use of the value immediately fol
Despite being a matter of taste, in general, there are two main approaches
when dealing with code tagging: tree-wide, where all the sources are taken
into account or config-wide, when considering Kconfig options and actually
built files. At the moment, all_sources variable is defined using SUBDIRS,
flight 179501 qemu-mainline real [real]
flight 179507 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/179501/
http://logs.test-lab.xenproject.org/osstest/logs/179507/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-am
On Fri, Mar 3, 2023 at 7:29 AM Jan Beulich wrote:
> While provable that length[0] is always initialized (because symCount
> cannot be zero), upcoming gcc13 fails to recognize this and warns about
> the unconditional use of the value immediately following the loop.
>
> See also https://gcc.gnu.org
On Mon, Mar 06, 2023 at 05:29:04PM +0100, Juergen Gross wrote:
> tools/tests/vhpet tests don't build since ages (at least since 4.10)
> and they can't be activated from outside of tools/tests/vhpet.
>
> Remove them as they seem to be irrelevant.
>
> Signed-off-by: Juergen Gross
> ---
> Andrew se
31 matches
Mail list logo
