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
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
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
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
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
> >
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
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
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
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,
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,
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
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
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 )
> >
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 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:
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
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,
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é
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
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
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 &
>>>
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
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
> 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
> >
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
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 -
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
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
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
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
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
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):
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 [
> >
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
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
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
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
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
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
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:
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
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
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:
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
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
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):
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
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
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
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
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
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
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,
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
55 matches
Mail list logo
