flight 161783 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161783/
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
flight 161800 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161800/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-armhf-armhf-xl
flight 161773 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161773/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332
flight 161796 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161796/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-armhf-armhf-xl
Hi Michal,
On 05/05/2021 08:43, Michal Orzel wrote:
The Armv8 specification describes the system register as a 64-bit value
on AArch64 and 32-bit value on AArch32 (same as ARMv7).
Unfortunately, Xen is accessing the system registers using
READ/WRITE_SYSREG32() which means the top 32-bit are
Hi Michal,
On 05/05/2021 08:43, Michal Orzel wrote:
AArch64 registers are 64bit whereas AArch32 registers
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when
Hi Michal,
On 05/05/2021 08:43, Michal Orzel wrote:
AArch64 registers are 64bit whereas AArch32 registers
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when
Hi Michal,
On 05/05/2021 08:43, Michal Orzel wrote:
AArch64 registers are 64bit whereas AArch32 registers
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when
On 30/04/2021 17:34, Anthony PERARD wrote:
From: Anthony PERARD
... when a xen-block backend instance is created via xenstore.
Following 8d17adf34f50 ("block: remove support for using "file" driver
with block/char devices"), using the "file" blockdev driver for
everything doesn't work
On 30/04/2021 17:37, Anthony PERARD wrote:
From: Anthony PERARD
Because Coverity complains about it and this is one leak that Valgrind
reports.
Signed-off-by: Anthony PERARD
Acked-by: Paul Durrant
---
hw/i386/xen/xen-hvm.c | 9 ++---
include/hw/xen/xen_common.h | 6 ++
On 29/04/2021 14:26, Jan Beulich wrote:
On 29.04.2021 13:27, Julien Grall wrote:
On 21/04/2021 11:22, Jan Beulich wrote:
While for the original library's purposes these functions of course want
to be externally exposed, we don't need this, and we also don't want
this both to prevent
flight 161772 xen-4.15-testing real [real]
flight 161794 xen-4.15-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/161772/
http://logs.test-lab.xenproject.org/osstest/logs/161794/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
flight 161793 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161793/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-armhf-armhf-xl
On 05/05/2021 09:33, Jan Beulich wrote:
> On 04.05.2021 16:17, Andrew Cooper wrote:
>> On 04/05/2021 13:56, Jan Beulich wrote:
>>> On 03.05.2021 17:39, Andrew Cooper wrote:
+unsigned int xstate_compressed_size(uint64_t xstates)
+{
+unsigned int i, size = XSTATE_AREA_MIN_SIZE;
Hi Jan,
> On 3 May 2021, at 3:46 pm, Jan Beulich wrote:
>
> On 29.04.2021 16:46, Rahul Singh wrote:
>> MSI code that implements MSI functionality to support MSI within XEN is
>> not usable on ARM. Move the code under CONFIG_HAS_PCI_MSI_INTERCEPT flag
>> to gate the code for ARM.
>>
>>
On 05/05/2021 16:00, Jan Beulich wrote:
> On 05.05.2021 16:50, Andrew Cooper wrote:
>> On 05/05/2021 15:48, Jan Beulich wrote:
>>> On 05.05.2021 16:29, Andrew Cooper wrote:
Technically, MCXSR_MASK is also a hard blocker to migration, but we
don't even have that data in a consumable form,
On 05.05.2021 16:53, Andrew Cooper wrote:
> On 05/05/2021 09:19, Jan Beulich wrote:
>> On 04.05.2021 15:58, Andrew Cooper wrote:
>>> On 04/05/2021 13:43, Jan Beulich wrote:
I'm also not happy at all to see you use a literal 3 here. We have
a struct for this, after all.
>
On 05.05.2021 16:50, Andrew Cooper wrote:
> On 05/05/2021 15:48, Jan Beulich wrote:
>> On 05.05.2021 16:29, Andrew Cooper wrote:
>>> Technically, MCXSR_MASK is also a hard blocker to migration, but we
>>> don't even have that data in a consumable form, and we just might be
>>> extremely lucky and
On 05/05/2021 09:19, Jan Beulich wrote:
> On 04.05.2021 15:58, Andrew Cooper wrote:
>> On 04/05/2021 13:43, Jan Beulich wrote:
>>> I'm also not happy at all to see you use a literal 3 here. We have
>>> a struct for this, after all.
>>>
p->xstate.xss_low = xstates &
On 05/05/2021 15:48, Jan Beulich wrote:
> On 05.05.2021 16:29, Andrew Cooper wrote:
>> Technically, MCXSR_MASK is also a hard blocker to migration, but we
>> don't even have that data in a consumable form, and we just might be
>> extremely lucky and discover that it is restricted to non-64-bit
On 05.05.2021 16:29, Andrew Cooper wrote:
> Technically, MCXSR_MASK is also a hard blocker to migration, but we
> don't even have that data in a consumable form, and we just might be
> extremely lucky and discover that it is restricted to non-64-bit CPUs.
"it" being what here? The value's
On 05/05/2021 14:02, Roger Pau Monné wrote:
> On Wed, May 05, 2021 at 01:37:48PM +0100, Andrew Cooper wrote:
>> On 05/05/2021 11:04, Roger Pau Monné wrote:
>>> On Tue, May 04, 2021 at 10:31:20PM +0100, Andrew Cooper wrote:
diff --git a/xen/lib/x86/policy.c b/xen/lib/x86/policy.c
index
On Wed, May 05, 2021 at 02:23:37PM +0200, Roger Pau Monné wrote:
> On Wed, May 05, 2021 at 11:45:16AM +, Wei Liu wrote:
> > It is reported that failed randconfig runs are missing the config file
> > which makes debugging impossible. Fix this by moving the line that
> > copies the config file
On 05/05/2021 12:15, Roger Pau Monne wrote:
> Do this before adding any more stuff to xg_cpuid_x86.c.
>
> The placement in xenctrl.h is wrong, as they are implemented by the
> xenguest library. Note that xg_cpuid_x86.c needs to include
> xg_private.h, and in turn also fix xg_private.h to include
>
On Thu, Apr 22, 2021 at 04:44:36PM +0200, Jan Beulich wrote:
> This is in preparation for the area size exceeding a page's worth of
> space, as will happen with AMX as well as Architectural LBR.
>
> Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
Even if the naming of the new helpers
On Wed, May 05, 2021 at 01:37:48PM +0100, Andrew Cooper wrote:
> On 05/05/2021 11:04, Roger Pau Monné wrote:
> > On Tue, May 04, 2021 at 10:31:20PM +0100, Andrew Cooper wrote:
> >> diff --git a/tools/tests/cpu-policy/test-cpu-policy.c
> >> b/tools/tests/cpu-policy/test-cpu-policy.c
> >> index
On 05/05/2021 10:16, Roger Pau Monné wrote:
> On Tue, May 04, 2021 at 07:53:22PM +0100, Andrew Cooper wrote:
>> It is bad form in C, perhaps best demonstrated by trying to read
>> xc_cpu_policy_destroy(), and causes const qualification to have
>> less-than-obvious behaviour (the hidden pointer
On 05/05/2021 11:04, Roger Pau Monné wrote:
> On Tue, May 04, 2021 at 10:31:20PM +0100, Andrew Cooper wrote:
>> Just as with x86_cpu_policies_are_compatible(), make a start on this function
>> with some token handling.
>>
>> Add levelling support for MSR_ARCH_CAPS, because RSBA has interesting
>>
On 05.05.2021 14:15, Andrew Cooper wrote:
> On 05/05/2021 07:39, Jan Beulich wrote:
>> On 04.05.2021 23:31, Andrew Cooper wrote:
>>> --- a/tools/tests/cpu-policy/test-cpu-policy.c
>>> +++ b/tools/tests/cpu-policy/test-cpu-policy.c
>>> @@ -775,6 +775,154 @@ static void
On Wed, May 05, 2021 at 11:45:16AM +, Wei Liu wrote:
> It is reported that failed randconfig runs are missing the config file
> which makes debugging impossible. Fix this by moving the line that
> copies the config file before the build is executed.
>
> Signed-off-by: Wei Liu
Acked-by:
On 05.05.2021 13:50, Julien Grall wrote:
> On 05/05/2021 11:57, Jan Beulich wrote:
>> Since I created this patch only because my request to correct the
>> statement led to me being asked to provide the suggested new text,
>> may I suggest that you pick up this patch or create one from scratch
>>
On 05/05/2021 07:39, Jan Beulich wrote:
> On 04.05.2021 23:31, Andrew Cooper wrote:
>> --- a/tools/tests/cpu-policy/test-cpu-policy.c
>> +++ b/tools/tests/cpu-policy/test-cpu-policy.c
>> @@ -775,6 +775,154 @@ static void test_is_compatible_failure(void)
>> }
>> }
>>
>> +static void
Hi Andrew,
On 05/05/2021 11:49, Andrew Cooper wrote:
On 04/05/2021 09:42, Jan Beulich wrote:
This array can be large when many grant frames are permitted; avoid
allocating it when it's not going to be used anyway, by doing this only
in gnttab_populate_status_frames(). While the delaying of the
Hi Jan,
On 05/05/2021 11:57, Jan Beulich wrote:
On 05.05.2021 10:51, Julien Grall wrote:
On 05/05/2021 09:24, Jan Beulich wrote:
On 05.05.2021 10:12, Julien Grall wrote:
Hi Jan,
On 30/04/2021 09:36, Jan Beulich wrote:
On 30.04.2021 10:19, Julien Grall wrote:
On 29/04/2021 14:10, Jan
On Wed, May 5, 2021 at 4:00 AM Jan Beulich wrote:
>
> On 05.05.2021 09:43, Michal Orzel wrote:
> > --- a/xen/include/public/arch-arm.h
> > +++ b/xen/include/public/arch-arm.h
> > @@ -267,10 +267,10 @@ struct vcpu_guest_core_regs
> >
> > /* Return address and mode */
> > __DECL_REG(pc64,
On Tue, May 04, 2021 at 05:14:36PM +0100, Anthony PERARD wrote:
> Also constify cmdtable_len and make use of ARRAY_SIZE, which is
> available in "xen-tools/libs.h".
>
> The entries in cmd_table don't need to be modified once xl is running.
>
> Signed-off-by: Anthony PERARD
> Reviewed-by: Julien
It is reported that failed randconfig runs are missing the config file
which makes debugging impossible. Fix this by moving the line that
copies the config file before the build is executed.
Signed-off-by: Wei Liu
---
automation/scripts/build | 5 -
1 file changed, 4 insertions(+), 1
flight 161770 xen-4.13-testing real [real]
flight 161789 xen-4.13-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/161770/
http://logs.test-lab.xenproject.org/osstest/logs/161789/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Do this before adding any more stuff to xg_cpuid_x86.c.
The placement in xenctrl.h is wrong, as they are implemented by the
xenguest library. Note that xg_cpuid_x86.c needs to include
xg_private.h, and in turn also fix xg_private.h to include
xc_bitops.h.
As a result also modify xen-cpuid to
On 05.05.2021 12:49, Andrew Cooper wrote:
> On 04/05/2021 09:42, Jan Beulich wrote:
>> This array can be large when many grant frames are permitted; avoid
>> allocating it when it's not going to be used anyway, by doing this only
>> in gnttab_populate_status_frames(). While the delaying of the
On 05.05.2021 10:51, Julien Grall wrote:
> Hi Jan,
>
> On 05/05/2021 09:24, Jan Beulich wrote:
>> On 05.05.2021 10:12, Julien Grall wrote:
>>> Hi Jan,
>>>
>>> On 30/04/2021 09:36, Jan Beulich wrote:
On 30.04.2021 10:19, Julien Grall wrote:
> On 29/04/2021 14:10, Jan Beulich wrote:
>>
On 04/05/2021 09:42, Jan Beulich wrote:
> This array can be large when many grant frames are permitted; avoid
> allocating it when it's not going to be used anyway, by doing this only
> in gnttab_populate_status_frames(). While the delaying of the respective
> memory allocation adds possible
flight 161771 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161771/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 161484
test-armhf-armhf-libvirt-raw 15
flight 161769 xen-4.11-testing real [real]
flight 161787 xen-4.11-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/161769/
http://logs.test-lab.xenproject.org/osstest/logs/161787/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On Tue, May 04, 2021 at 10:31:20PM +0100, Andrew Cooper wrote:
> Just as with x86_cpu_policies_are_compatible(), make a start on this function
> with some token handling.
>
> Add levelling support for MSR_ARCH_CAPS, because RSBA has interesting
> properties, and introduce
flight 161786 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161786/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 8cccd6438e86112ab383e41b433b5a7e73be9621
baseline version:
xen
On Tue, May 04, 2021 at 07:53:22PM +0100, Andrew Cooper wrote:
> It is bad form in C, perhaps best demonstrated by trying to read
> xc_cpu_policy_destroy(), and causes const qualification to have
> less-than-obvious behaviour (the hidden pointer becomes const, not the thing
> it points at).
Would
Hi Jan,
On 05/05/2021 09:24, Jan Beulich wrote:
On 05.05.2021 10:12, Julien Grall wrote:
Hi Jan,
On 30/04/2021 09:36, Jan Beulich wrote:
On 30.04.2021 10:19, Julien Grall wrote:
On 29/04/2021 14:10, Jan Beulich wrote:
With there being a way to disable v2 support, telling new guests to use
On 04.05.2021 16:17, Andrew Cooper wrote:
> On 04/05/2021 13:56, Jan Beulich wrote:
>> On 03.05.2021 17:39, Andrew Cooper wrote:
>>> +unsigned int xstate_compressed_size(uint64_t xstates)
>>> +{
>>> +unsigned int i, size = XSTATE_AREA_MIN_SIZE;
>>> +
>>> +xstates &= ~XSTATE_FP_SSE;
>>> +
Hi Jan,
On 04/05/2021 09:42, Jan Beulich wrote:
This array can be large when many grant frames are permitted; avoid
allocating it when it's not going to be used anyway, by doing this only
in gnttab_populate_status_frames(). While the delaying of the respective
memory allocation adds possible
On 05.05.2021 10:12, Julien Grall wrote:
> Hi Jan,
>
> On 30/04/2021 09:36, Jan Beulich wrote:
>> On 30.04.2021 10:19, Julien Grall wrote:
>>> On 29/04/2021 14:10, Jan Beulich wrote:
With there being a way to disable v2 support, telling new guests to use
v2 exclusively is not a good
> On 4 May 2021, at 23:30, Stefano Stabellini wrote:
>
> On Tue, 4 May 2021, Luca Fancellu wrote:
>> Create a skeleton for the documentation about hypercalls
>
> Why is there a difference between the arm32, arm64 and x86_64 skeletons?
> Shouldn't just we have one? Or if we have to have
On 04.05.2021 15:58, Andrew Cooper wrote:
> On 04/05/2021 13:43, Jan Beulich wrote:
>> On 03.05.2021 17:39, Andrew Cooper wrote:
>>> Make use of the new xstate_uncompressed_size() helper rather than
>>> maintaining
>>> the running calculation while accumulating feature components.
>>>
>>> The
Hi Jan,
On 30/04/2021 09:36, Jan Beulich wrote:
On 30.04.2021 10:19, Julien Grall wrote:
On 29/04/2021 14:10, Jan Beulich wrote:
With there being a way to disable v2 support, telling new guests to use
v2 exclusively is not a good suggestion.
Signed-off-by: Jan Beulich
---
On Wed, May 05, 2021 at 09:07:30AM +0200, Jan Beulich wrote:
> Move a few #ifdef-s, to account for diagnostics like
>
> p2m.c:549:1: error: non-void function does not return a value in all control
> paths [-Werror,-Wreturn-type]
There's also __builtin_unreachable, but that would get even
On 05.05.2021 09:43, Michal Orzel wrote:
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -267,10 +267,10 @@ struct vcpu_guest_core_regs
>
> /* Return address and mode */
> __DECL_REG(pc64, pc32); /* ELR_EL2 */
> -uint32_t cpsr;
Hi Jan,
> On 3 May 2021, at 3:38 pm, Jan Beulich wrote:
>
> On 29.04.2021 16:46, Rahul Singh wrote:
>> --- /dev/null
>> +++ b/xen/drivers/passthrough/msi-intercept.c
>> @@ -0,0 +1,53 @@
>> +/*
>> + * Copyright (C) 2008, Netronome Systems, Inc.
>> + *
>> + * This program is free software; you
AArch64 registers are 64bit whereas AArch32 registers
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when reading sysregs
which can correspond to uint64_t or
AArch64 registers are 64bit whereas AArch32 registers
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when reading sysregs
which can correspond to uint64_t or
The Armv8 specification describes the system register as a 64-bit value
on AArch64 and 32-bit value on AArch32 (same as ARMv7).
Unfortunately, Xen is accessing the system registers using
READ/WRITE_SYSREG32() which means the top 32-bit are clobbered.
This is only a latent bug so far because Xen
AArch64 registers are 64bit whereas AArch32 registers
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when reading sysregs
which can correspond to uint64_t or
... as it is never used even in the patch introducing it.
Signed-off-by: Michal Orzel
Acked-by: Julien Grall
---
xen/include/asm-arm/gic.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index ad0f7452d0..5069ab4aac
AArch64 registers are 64bit whereas AArch32 registers
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when reading sysregs
which can correspond to uint64_t or
AArch64 registers are 64bit whereas AArch32 registers
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when reading sysregs
which can correspond to uint64_t or
AArch64 registers are 64bit whereas AArch32 registers
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when reading sysregs
which can correspond to uint64_t or
AArch64 registers are 64bit whereas AArch32 registers
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when reading sysregs
which can correspond to uint64_t or
AArch64 registers are 64bit whereas AArch32 registers
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when reading sysregs
which can correspond to uint64_t or
The purpose of this patch series is to remove usage of 32bit helper
macros READ/WRITE_SYSREG32 on arm64 as the idea of them is
not following the latest ARMv8 specification and mrs/msr instructions
are expecting 64bit values.
According to ARM DDI 0487G.a all the AArch64 system registers
are 64bit
On 04.05.2021 17:34, Roger Pau Monné wrote:
> On Mon, May 03, 2021 at 01:09:41PM +0200, Jan Beulich wrote:
>> On 30.04.2021 17:52, Roger Pau Monne wrote:
>>> @@ -1086,3 +1075,42 @@ int xc_cpu_policy_calc_compatible(xc_interface *xch,
>>>
>>> return rc;
>>> }
>>> +
>>> +int
On 04.05.2021 19:11, Andrew Cooper wrote:
> On 04/05/2021 12:58, Roger Pau Monné wrote:
>> On Tue, May 04, 2021 at 01:40:11PM +0200, Jan Beulich wrote:
>>> On 04.05.2021 12:56, Roger Pau Monné wrote:
On Mon, May 03, 2021 at 12:41:29PM +0200, Jan Beulich wrote:
> On 30.04.2021 17:52, Roger
Move a few #ifdef-s, to account for diagnostics like
p2m.c:549:1: error: non-void function does not return a value in all control
paths [-Werror,-Wreturn-type]
which appear despite paging_mode_translate() resolving to constant
"false" when !HVM. All of the affected functions are intended to
On 04.05.2021 23:31, Andrew Cooper wrote:
> --- a/tools/include/xen-tools/libs.h
> +++ b/tools/include/xen-tools/libs.h
> @@ -63,4 +63,9 @@
> #define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) &
> ~((1UL<<(_w))-1))
> #endif
>
> +#ifndef _AC
> +#define __AC(X, Y) (X ## Y)
> +#define
On 04.05.2021 20:53, Andrew Cooper wrote:
> Unsure what to do about x86_cpu_policies_are_compatible(). It would be nice
> to have xc_cpu_policy_is_compatible() sensibly const'd, but maybe that means
> we need a struct const_cpu_policy and that smells like it is spiralling out of
> control.
Not
73 matches
Mail list logo
