flight 184638 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184638/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 184633
test-amd64-amd64-xl-qemuu-win7-amd64
flight 184635 xen-unstable real [real]
flight 184640 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184635/
http://logs.test-lab.xenproject.org/osstest/logs/184640/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armh
Update docs/misra/rules.rst to reflect the MISRA C rules accepted in the
last couple of months.
Signed-off-by: Stefano Stabellini
---
In the notes section I added some info about the deviations, but in any
case the appropriate info will also be added to deviations.rst,
safe.json, etc.
I also ad
flight 184639 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184639/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8801c75b4d77c2e6e06b3ddc8560e0db590f6342
baseline version:
ovmf dcf2e39dce00a5978f1c1
On Wed, 7 Feb 2024, Simone Ballarin wrote:
> On 07/02/24 11:24, Jan Beulich wrote:
> > On 07.02.2024 11:03, Simone Ballarin wrote:
> > > On 06/02/24 13:04, Jan Beulich wrote:
> > > > On 02.02.2024 16:16, Simone Ballarin wrote:
> > > > > Rule 13.1: Initializer lists shall not contain persistent side
On Fri, 9 Feb 2024, Jan Beulich wrote:
> On 09.02.2024 10:25, Simone Ballarin wrote:
> > On 07/02/24 13:40, Jan Beulich wrote:
> >> On 07.02.2024 13:21, Simone Ballarin wrote:
> >>> On 07/02/24 11:24, Jan Beulich wrote:
> On 07.02.2024 11:03, Simone Ballarin wrote:
> > On 06/02/24 13:04, J
On Fri, 9 Feb 2024, Nicola Vetrini wrote:
> Hi all,
>
> In the context of violations of MISRA C:2012 Rule 17.7: "The value returned by
> a function having non-void return type shall be used", I was looking at the
> function "clean_and_invalidate_dcache_va_range". It has the following
> signature o
On Fri, 8 Feb 2024, Simone Ballarin wrote:
> properties.ecl does not exist and it is not
> even generated by propertyparser.py. Loading
> this file causes empty ECLAIR analysis.
>
> Fixes: f4519ee8 ("eclair: move function and macro properties outside ECLAIR")
> Signed-off-by: Simone Ballarin
Rev
On Thu, Feb 01, 2024 at 09:39:49AM +0100, Roger Pau Monné wrote:
> On Wed, Jan 31, 2024 at 01:00:14PM -0600, Bjorn Helgaas wrote:
> > On Wed, Jan 31, 2024 at 09:58:19AM +0100, Roger Pau Monné wrote:
> > > On Tue, Jan 30, 2024 at 02:44:03PM -0600, Bjorn Helgaas wrote:
> > > > On Tue, Jan 30, 2024 at
flight 184637 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184637/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf dcf2e39dce00a5978f1c1a53a0fce04d0fdc9a3c
baseline version:
ovmf e32b58ab5a12d37c82327
flight 184633 linux-linus real [real]
flight 184636 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184633/
http://logs.test-lab.xenproject.org/osstest/logs/184636/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-
On 1/12/24 01:13, Jiqian Chen wrote:
> When a device has been reset on dom0 side, the vpci on Xen
> side won't get notification, so the cached state in vpci is
> all out of date compare with the real device state.
> To solve that problem, add a new hypercall to clear all vpci
> device state. When t
The following changes were done as a result of switching to
asm-generic/device.h:
* DEVICE_GIC was renamed to DEVICE_INTERRUPT_CONTROLLER according
to definition of enum device_class in asm-generic/device.h.
* acpi-related things in Arm code were guarded by #ifdef CONFIG_ACPI
as struct acpi
ifdefing inclusion of in
allows to avoid generation of empty header
for the case when !CONFIG_MEM_ACCESS.
For Arm it was explicitly added inclusion of for p2m.c
and traps.c because they require some functions from which
aren't available in case of !CONFIG_MEM_ACCESS.
Suggested-by: Jan Beulic
Some headers are common between several architectures, so the current patch
series
provide them.
Another one reason to have them as generic is a simplification of adding support
necessary to make a complete Xen build as it was/is being done in the patch
series [1]
and [2].
Also, instead of prov
This patch introduces the file riscv-fixed-randconfig.yaml,
which includes all configurations that should be disabled for
randconfig builds.
Suggested-by: Stefano Stabellini
Signed-off-by: Oleksii Kurochko
---
The patch were introduced after discussion in a topic:
https://lore.kernel.org/xen-d
The header is shared between several archs so it is
moved to asm-generic.
Switch partly Arm and PPC to asm-generic/monitor.h and only
arch_monitor_get_capabilities() left in arch-specific/monitor.h.
Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
Acked-by: Tamas K Lengyel
---
Changes in
Signed-off-by: Oleksii Kurochko
---
Changes in V7:
- newly introduced patch which is based on the previous version of the patch:
[PATCH v6 9/9] xen/asm-generic: introduce generic device.h
---
xen/arch/ppc/include/asm/Makefile | 1 +
xen/arch/ppc/include/asm/device.h | 53 -
Arm, PPC and RISC-V introduce the same things in asm/device.h, so
generic device.h was introduced.
Arm's device.h was taken as a base with the following changes:
- #ifdef ACPI related things.
- Rename #ifdef guards.
- Add SPDX tag.
- #ifdef CONFIG_HAS_DEVICE_TREE related things.
- #ifdef-ing i
Kconfig tool expects each configuration to be on a new line.
The current version of the build script puts all of ${EXTRA_FIXED_RANDCONFIG}
in a single line and configs are seperated by spaces.
As a result, only the first configuration in ${EXTRA_FIXED_RANDCONFIG} will
be used.
Signed-off-by: Ole
find-next-bit.c is common for Arm64, PPC and RISCV64,
so it is moved to xen/lib.
PPC has been transitioned to generic functions from find-next-bit.c
since it now shares the same implementation as the PPC-specific code.
The MISRA exclude list has been updated to verify
lib/find-next-bit.c instead
On Thu, 2024-02-08 at 16:58 +, Julien Grall wrote:
> Hi Oleksii,
Hi Julien,
>
> On 05/02/2024 19:23, Oleksii Kurochko wrote:
> > Hello everyone,
> >
> > I would like to share with you a list for status tracking based on
> > Xen ML:
> >
> > Arm:
> > * [PATCH v5 00/13] Arm cache coloring [
On Tue, 2024-02-06 at 10:24 +0100, Jan Beulich wrote:
> On 05.02.2024 20:23, Oleksii Kurochko wrote:
> > Hello everyone,
> >
> > I would like to share with you a list for status tracking based on
> > Xen ML:
> >
> > Arm:
> > * [PATCH v5 00/13] Arm cache coloring [
> > https://lore.kernel.org/xe
Hi all,
In the context of violations of MISRA C:2012 Rule 17.7: "The value
returned by a function having non-void return type shall be used", I was
looking at the function "clean_and_invalidate_dcache_va_range". It has
the following signature on both arm and x86:
static inline int clean_and_
> On Fri, Feb 9, 2024 at 3:58 PM Andrew Cooper
> wrote:
>
> On 08/02/2024 9:20 pm, Petr Beneš wrote:
> > From: Petr Beneš
> >
> > This patch addresses an issue where the fast singlestep setting would
> > persist
> > despite xc_domain_debug_control being called with
> > XEN_DOMCTL_DEBUG_OP_SING
On 08/02/2024 9:20 pm, Petr Beneš wrote:
> From: Petr Beneš
>
> This patch addresses an issue where the fast singlestep setting would persist
> despite xc_domain_debug_control being called with
> XEN_DOMCTL_DEBUG_OP_SINGLE_STEP_OFF.
> Specifically, if fast singlestep was enabled in a VMI session
On 09.02.2024 09:25, Roger Pau Monné wrote:
> On Mon, Feb 05, 2024 at 02:57:12PM +0100, Jan Beulich wrote:
>> ..., thus allowing it and qinval_device_iotlb_sync() to become static.
>> There's nothing x86-specific about the function anyway. While moving,
>> adjust types to better match ./CODING_STYL
flight 184632 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184632/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184624
test-armhf-armhf-libvirt-qcow2 15 saveres
On Thu, Feb 8, 2024 at 4:20 PM Petr Beneš wrote:
>
> From: Petr Beneš
>
> This patch addresses an issue where the fast singlestep setting would persist
> despite xc_domain_debug_control being called with
> XEN_DOMCTL_DEBUG_OP_SINGLE_STEP_OFF.
> Specifically, if fast singlestep was enabled in a V
On 2024-02-09 13:17, Julien Grall wrote:
Hi Jan,
On 09/02/2024 11:46, Jan Beulich wrote:
On 09.02.2024 10:40, Julien Grall wrote:
Replying on the v2 as well.
And answering here despite the respective question was raised on the
v1 thread: I'm certainly okay with the more detailed commit messa
Hi Julien,
Apologies for the delay, I was pulled away for a bit.
On 2/5/24 11:13, Julien Grall wrote:
> Hi,
>
> On 04/02/2024 09:40, Peng Fan wrote:
>>
>>
>>> -Original Message-
>>> From: Julien Grall
>>> Sent: 2024年2月2日 17:20
>>> To: John Ernberg ; Stefano Stabellini
>>> ; Bertrand Mar
On Fri, Feb 09, 2024 at 12:51:41PM +0100, Jan Beulich wrote:
> On 09.02.2024 11:45, Roger Pau Monné wrote:
> > On Thu, Feb 08, 2024 at 02:40:53PM +0100, Jan Beulich wrote:
> >> On 06.02.2024 15:25, Roger Pau Monne wrote:
> >>> @@ -2086,6 +2091,9 @@ void vmcs_dump_vcpu(struct vcpu *v)
> >>> if
properties.ecl does not exist and it is not
even generated by propertyparser.py. Loading
this file causes empty ECLAIR analysis.
Fixes: f4519ee8 ("eclair: move function and macro properties outside ECLAIR")
Signed-off-by: Simone Ballarin
---
automation/eclair_analysis/ECLAIR/analysis.ecl | 1 -
Hi Jan,
On 09/02/2024 11:46, Jan Beulich wrote:
On 09.02.2024 10:40, Julien Grall wrote:
Replying on the v2 as well.
And answering here despite the respective question was raised on the
v1 thread: I'm certainly okay with the more detailed commit message.
Ah yes. Sorry, I replied to v1 first
flight 184630 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184630/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184626
test-amd64-amd64-xl-qemut-win7-amd64
On 09.02.2024 10:25, Simone Ballarin wrote:
> On 07/02/24 13:40, Jan Beulich wrote:
>> On 07.02.2024 13:21, Simone Ballarin wrote:
>>> On 07/02/24 11:24, Jan Beulich wrote:
On 07.02.2024 11:03, Simone Ballarin wrote:
> On 06/02/24 13:04, Jan Beulich wrote:
>> On 02.02.2024 16:16, Simon
On 09.02.2024 11:45, Roger Pau Monné wrote:
> On Thu, Feb 08, 2024 at 02:40:53PM +0100, Jan Beulich wrote:
>> On 06.02.2024 15:25, Roger Pau Monne wrote:
>>> @@ -2086,6 +2091,9 @@ void vmcs_dump_vcpu(struct vcpu *v)
>>> if ( v->arch.hvm.vmx.secondary_exec_control &
>>> SECONDARY_EXEC
On 09.02.2024 10:40, Julien Grall wrote:
> Replying on the v2 as well.
And answering here despite the respective question was raised on the
v1 thread: I'm certainly okay with the more detailed commit message.
A few nits, though:
> On 08/02/2024 15:56, Jan Beulich wrote:
>> On 08.02.2024 16:50, Ni
The feature is defined in the tertiary exec control, and is available starting
from Sapphire Rapids and Alder Lake CPUs.
When enabled, two extra VMCS fields are used: SPEC_CTRL mask and shadow. Bits
set in mask are not allowed to be toggled by the guest (either set or clear)
and the value in the
flight 184634 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184634/
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 Thu, Feb 08, 2024 at 02:40:53PM +0100, Jan Beulich wrote:
> On 06.02.2024 15:25, Roger Pau Monne wrote:
> > @@ -2086,6 +2091,9 @@ void vmcs_dump_vcpu(struct vcpu *v)
> > if ( v->arch.hvm.vmx.secondary_exec_control &
> > SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY )
> > printk("I
On 08/02/24 12:14, Jan Beulich wrote:
On 08.02.2024 11:45, Federico Serafini wrote:
On 07/02/24 17:19, Jan Beulich wrote:
On 07.02.2024 16:58, Federico Serafini wrote:
On 07/02/24 16:24, Jan Beulich wrote:
On 07.02.2024 16:08, Federico Serafini wrote:
On 07/02/24 15:16, Jan Beulich wrote:
O
Hi,
Replying on the v2 as well.
On 08/02/2024 15:56, Jan Beulich wrote:
On 08.02.2024 16:50, Nicola Vetrini wrote:
These files contain several deliberate violations of MISRA C rules and
they are not linked in the final Xen binary, therefore they can be exempted
from MISRA compliance.
I'd lik
On Thu, 2024-02-08 at 21:30 +, Julien Grall wrote:
> Hi Oleksii,
Hi Julien,
>
> On 02/02/2024 18:03, Oleksii Kurochko wrote:
> > Move the macros mentioned in the commit subject to their
> > appropriate
> > locations.
> > Additionally, eliminate the dependency of xen/lib.h from xen/bug.h
> > a
On Thu, 2024-02-08 at 17:42 +0100, Jan Beulich wrote:
> On 02.02.2024 19:03, Oleksii Kurochko wrote:
> > Move the macros mentioned in the commit subject to their
> > appropriate
> > locations.
> > Additionally, eliminate the dependency of xen/lib.h from xen/bug.h
> > and
> > include "xen/bug.h" in
Hi,
On 09/02/2024 09:34, Nicola Vetrini wrote:
On 2024-02-09 10:28, Julien Grall wrote:
On 09/02/2024 07:52, Nicola Vetrini wrote:
Hi Julien,
Hi Nicola,
On 2024-02-08 22:33, Julien Grall wrote:
Hi Nicola,
On 08/02/2024 07:55, Nicola Vetrini wrote:
These two files contain several deliber
On 2024-02-09 10:28, Julien Grall wrote:
On 09/02/2024 07:52, Nicola Vetrini wrote:
Hi Julien,
Hi Nicola,
On 2024-02-08 22:33, Julien Grall wrote:
Hi Nicola,
On 08/02/2024 07:55, Nicola Vetrini wrote:
These two files contain several deliberate violations of MISRA C
rules and
they are not
On 09/02/2024 07:52, Nicola Vetrini wrote:
Hi Julien,
Hi Nicola,
On 2024-02-08 22:33, Julien Grall wrote:
Hi Nicola,
On 08/02/2024 07:55, Nicola Vetrini wrote:
These two files contain several deliberate violations of MISRA C
rules and
they are not linked in the final Xen binary, theref
On 07/02/24 13:40, Jan Beulich wrote:
On 07.02.2024 13:21, Simone Ballarin wrote:
On 07/02/24 11:24, Jan Beulich wrote:
On 07.02.2024 11:03, Simone Ballarin wrote:
On 06/02/24 13:04, Jan Beulich wrote:
On 02.02.2024 16:16, Simone Ballarin wrote:
Rule 13.1: Initializer lists shall not contain
On Wed, Feb 15, 2023 at 03:54:11PM +0100, Jan Beulich wrote:
> While the PAE-extended-CR3 VM assist is a 32-bit only concept, it still
> applies to guests also when run on a 64-bit hypervisor: The "extended
> CR3" format has to be used there as well, to fit the address in the only
> 32-bit wide reg
On Thu, Feb 08, 2024 at 04:29:34PM +0100, Jan Beulich wrote:
> On 08.02.2024 10:17, Roger Pau Monné wrote:
> > On Mon, Feb 05, 2024 at 02:55:17PM +0100, Jan Beulich wrote:
> >> This is a prereq to us, in particular, respecting the "ATC required"
> >> flag.
> >>
> >> Signed-off-by: Jan Beulich
> >>
On Mon, Feb 05, 2024 at 02:57:30PM +0100, Jan Beulich wrote:
> ..., thus allowing them to become static. There's nothing x86-specific
> about these functions anyway.
>
> Since only the "iommu_inclusive_mapping" parameter declaration would be
> left in the file, move that as well. There's nothing V
On Mon, Feb 05, 2024 at 02:57:12PM +0100, Jan Beulich wrote:
> ..., thus allowing it and qinval_device_iotlb_sync() to become static.
> There's nothing x86-specific about the function anyway. While moving,
> adjust types to better match ./CODING_STYLE (albeit use of fixed-width
> types for paramete
On Mon, Feb 05, 2024 at 02:56:55PM +0100, Jan Beulich wrote:
> ..., thus allowing it to become static, and thus reducing scope overlap
> between it and pci_ats_device(). There's nothing x86-specific about this
> function anyway.
>
> Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné zroger
On Fri, Feb 09, 2024 at 08:06:07AM +0100, Jan Beulich wrote:
> On 08.02.2024 18:31, Roger Pau Monné wrote:
> > On Mon, Feb 05, 2024 at 02:56:36PM +0100, Jan Beulich wrote:
> >> All callers only care about boolean outcome. For this there's no point
> >> in allocating a duplicate of the respective DR
55 matches
Mail list logo