flight 184839 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184839/
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 184836 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184836/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 275d0a39c42ad73a6e4929822f56f5d8c16ede96
baseline version:
ovmf
On Fri, 1 Mar 2024, Jan Beulich wrote:
> On 29.02.2024 23:57, Stefano Stabellini wrote:
> > On Thu, 29 Feb 2024, Nicola Vetrini wrote:
> >> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> >> of macro parameters shall be enclosed in parentheses". Therefore, some
> >> macro
On Fri, 1 Mar 2024, Federico Serafini wrote:
> Update ECLAIR configuration to take into account the deviations
> agreed during MISRA meetings.
>
> Signed-off-by: Federico Serafini
Acked-by: Stefano Stabellini
> ---
> automation/eclair_analysis/ECLAIR/deviations.ecl | 4
>
flight 184837 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184837/
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 2024-02-07 16:02, Jan Beulich wrote:
> On 04.01.2024 14:16, Jan Beulich wrote:
> > On 22.12.2023 16:49, Neowutran wrote:
> >> Full logs without my patch to set allow-memory-relocate
> >> (https://github.com/neowutran/qubes-vmm-xen/blob/allowmemoryrelocate/ALLOWMEMORYRELOCATE.patch)
> >>
Hi,
Am 18.02.2024 um 18:49 schrieb Julien Grall:
Hi,
On 17/02/2024 21:46, Paul Leiber wrote:
Am 22.01.2024 um 11:46 schrieb George Dunlap:
On Fri, Jan 19, 2024 at 8:32 PM Elliott Mitchell
wrote:
On Sun, Jan 14, 2024 at 10:54:24PM +0100, Paul Leiber wrote:
Am 22.10.2023 um 07:42 schrieb
On Fri, Mar 01, 2024 at 03:01:36PM +, Andrew Cooper wrote:
> On 01/03/2024 1:28 pm, Roger Pau Monné wrote:
> > On Thu, Feb 29, 2024 at 06:13:54PM +, Andrew Cooper wrote:
> >> MD_CLEAR and FB_CLEAR need OR-ing across a migrate pool. Allow this, by
> >> having them unconditinally set in
flight 184829 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184829/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel broken
test-amd64-amd64-pygrub
Hello everyone,
I would like to share with you a list for status tracking based on Xen
ML and community members comments:
Arm:
* [PATCH v6 00/15] Arm cache coloring [
https://lore.kernel.org/xen-devel/20240129171811.21382-1-carlo.non...@minervasys.tech/
]:
new patch series version [v6] was
Vikram Garhwal writes:
> From: Juergen Gross
>
> Today xen_ram_addr_from_mapcache() will either abort() or return 0 in
> case it can't find a matching entry for a pointer value. Both cases
> are bad, so change that to return an invalid address instead.
>
> Signed-off-by: Juergen Gross
>
Hi Anthony,
On Wed, Feb 28, 2024 at 7:05 PM Anthony PERARD wrote:
>
> On Mon, Jan 29, 2024 at 06:18:02PM +0100, Carlo Nonato wrote:
> > diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
> > index 2ef8b4e054..4b541fffd2 100644
> > --- a/tools/include/xenctrl.h
> > +++
On 2024-02-29 17:34, Jan Beulich wrote:
On 29.02.2024 16:27, Nicola Vetrini wrote:
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -462,8 +462,8 @@ static bool has_ssbd_mitigation(const struct
arm_cpu_capabilities *entry)
#define MIDR_RANGE(model, min, max) \
On 01/03/2024 12:11 pm, Roger Pau Monné wrote:
> On Thu, Feb 29, 2024 at 10:14:48PM +, Andrew Cooper wrote:
>> PV guests can't write to MSR_APIC_BASE (in order to set EXTD), nor can they
>> access any of the x2APIC MSR range. Therefore they mustn't see the x2APIC
>> CPUID bit saying that they
On 01/03/2024 12:30 pm, Roger Pau Monné wrote:
> On Fri, Mar 01, 2024 at 11:28:29AM +, Andrew Cooper wrote:
>> The block in recalculate_cpuid_policy() predates the proper split between
>> default and max policies, and was a "slightly max for a toolstack which knows
>> about it" capability. It
On 01/03/2024 12:42 pm, Roger Pau Monne wrote:
> The current usage of a cmpxchg loop to increase the value of page count is not
> optimal on amd64, as there's already an instruction to do an atomic add to a
> 64bit integer.
>
> Switch the code in get_page_light() to use an atomic increment, as
Update ECLAIR configuration to take into account the deviations
agreed during MISRA meetings.
Signed-off-by: Federico Serafini
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 4
docs/misra/deviations.rst| 6 ++
2 files changed, 10 insertions(+)
diff
On 01/03/2024 1:28 pm, Roger Pau Monné wrote:
> On Thu, Feb 29, 2024 at 06:13:54PM +, Andrew Cooper wrote:
>> MD_CLEAR and FB_CLEAR need OR-ing across a migrate pool. Allow this, by
>> having them unconditinally set in max, with the host values reflected in
>> default. Annotate the bits as
On 29.02.24 16:32, Jan Beulich wrote:
On 12.12.2023 10:47, Juergen Gross wrote:
+#define nrspin_lock_irqsave(l, f) \
+({ \
+BUILD_BUG_ON(sizeof(f) != sizeof(unsigned long)); \
+((f)
Vikram Garhwal writes:
> From: Juergen Gross
>
> Add a memory region which can be used to automatically map granted
> memory. It is starting at 0x8000ULL in order to be able to
> distinguish it from normal RAM.
Is the Xen memory map for HVM guests documented anywhere? I couldn't
flight 184828 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184828/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184820
On Thu, Feb 29, 2024 at 06:13:54PM +, Andrew Cooper wrote:
> MD_CLEAR and FB_CLEAR need OR-ing across a migrate pool. Allow this, by
> having them unconditinally set in max, with the host values reflected in
> default. Annotate the bits as having special properies.
>
> Signed-off-by: Andrew
flight 184830 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184830/
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
The current usage of a cmpxchg loop to increase the value of page count is not
optimal on amd64, as there's already an instruction to do an atomic add to a
64bit integer.
Switch the code in get_page_light() to use an atomic increment, as that avoids
a loop construct. This slightly changes the
On Fri, Mar 01, 2024 at 11:28:29AM +, Andrew Cooper wrote:
> The block in recalculate_cpuid_policy() predates the proper split between
> default and max policies, and was a "slightly max for a toolstack which knows
> about it" capability. It didn't get transformed properly in Xen 4.14.
>
>
Right now, test-resource always creates HVM Shadow guests. But if Xen has
SHADOW compiled out, running the test yields:
$./test-resource
XENMEM_acquire_resource tests
Test x86 PV
Created d1
Test grant table
Test x86 PVH
Skip: 95 - Operation not supported
and doesn't really
On Thu, Feb 29, 2024 at 10:14:48PM +, Andrew Cooper wrote:
> PV guests can't write to MSR_APIC_BASE (in order to set EXTD), nor can they
> access any of the x2APIC MSR range. Therefore they mustn't see the x2APIC
> CPUID bit saying that they can.
>
> Right now, the host x2APIC flag filters
On 01/03/2024 11:49 am, Roger Pau Monné wrote:
> On Thu, Feb 29, 2024 at 08:53:54PM +, Andrew Cooper wrote:
>> Right now, test-resource always creates HVM Shadow guests. But if Xen has
>> SHADOW compiled out, running the test yields:
>>
>> $./test-resource
>> XENMEM_acquire_resource tests
On 01/03/2024 11:43 am, Nicola Vetrini wrote:
> Reporting the discussion that took place on Matrix on the matter, so
> that it can carry on here with all interested parties:
>
>> Hi everyone. I was looking at MISRA violations for Rule 20.7
>> ("Expressions resulting from the expansion of macro
On Thu, Feb 29, 2024 at 08:53:54PM +, Andrew Cooper wrote:
> Right now, test-resource always creates HVM Shadow guests. But if Xen has
> SHADOW compiled out, running the test yields:
>
> $./test-resource
> XENMEM_acquire_resource tests
> Test x86 PV
> Created d1
> Test grant
Reporting the discussion that took place on Matrix on the matter, so
that it can carry on here with all interested parties:
Hi everyone. I was looking at MISRA violations for Rule 20.7
("Expressions resulting from the expansion of macro parameters shall be
enclosed in parentheses") generated
The block in recalculate_cpuid_policy() predates the proper split between
default and max policies, and was a "slightly max for a toolstack which knows
about it" capability. It didn't get transformed properly in Xen 4.14.
Because Xen will accept a VM with HTT/CMP_LEGACY seen, they should be
Hi Stefano,
On 29/02/2024 17:47, Stefano Stabellini wrote:
On Thu, 29 Feb 2024, Jan Beulich wrote:
On 28.02.2024 23:45, Stefano Stabellini wrote:
On Wed, 28 Feb 2024, Julien Grall wrote:
On 28/02/2024 12:58, Jan Beulich wrote:
On 28.02.2024 12:50, Julien Grall wrote:
On 27/02/2024 13:19,
Hi Jan,
On 26/02/2024 10:34, Jan Beulich wrote:
At the time they were introduced, there were no asm/nospec.h yet, so
they were placed in system.h. Move them to nospec.h and drop
xen/nospec.h's including of asm/system.h; there's one unrelated #include
that needs adding in exchange, on x86.
On 01/03/2024 8:52 am, Luca Fancellu wrote:
>> On 1 Mar 2024, at 08:49, Michal Orzel wrote:
>>
>> Commit 4cac80e22600 broke the CI cppcheck jobs by adding an entry for
>> a rule 20.12 with "Severity" and "Summary" fields placed in reverse order.
>> This leads to an error as reported by
On Thu, 2024-02-29 at 16:25 +, Andrew Cooper wrote:
> On 26/02/2024 5:38 pm, Oleksii Kurochko wrote:
> > These functions can be useful for architectures that don't
> > have corresponding arch-specific instructions.
> >
> > Signed-off-by: Oleksii Kurochko
> > ---
> > Changes in V5:
> > -
> On 1 Mar 2024, at 08:49, Michal Orzel wrote:
>
> Commit 4cac80e22600 broke the CI cppcheck jobs by adding an entry for
> a rule 20.12 with "Severity" and "Summary" fields placed in reverse order.
> This leads to an error as reported by convert_misra_doc.py:
> No summary for rule 20.12
>
>
Commit 4cac80e22600 broke the CI cppcheck jobs by adding an entry for
a rule 20.12 with "Severity" and "Summary" fields placed in reverse order.
This leads to an error as reported by convert_misra_doc.py:
No summary for rule 20.12
Fixes: 4cac80e22600 ("docs/misra/rules.rst: add rule 16.6 and
On 01/03/24 00:00, Stefano Stabellini wrote:
On Thu, 29 Feb 2024, Jan Beulich wrote:
On 29.02.2024 09:01, Federico Serafini wrote:
On 28/02/24 10:06, Jan Beulich wrote:
On 28.02.2024 09:53, Federico Serafini wrote:
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++
On 01/03/2024 02:56, Stefano Stabellini wrote:
>
>
> Hi all,
>
> This patch broke gitlab-ci. The jobs failing are the cppcheck jobs.
>
> xen/scripts/xen-analysis.py --run-cppcheck --cppcheck-misra -- -j80
> No summary for rule 20.12
This is the error message. For rule 20.12, the summary and
On 01.03.2024 02:12, GitLab wrote:
>
>
> Pipeline #1196428827 has failed!
>
> Project: xen ( https://gitlab.com/xen-project/xen )
> Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging )
>
> Commit: 4cac80e2 (
>
On 2024-02-29 23:55, Stefano Stabellini wrote:
On Thu, 29 Feb 2024, Nicola Vetrini wrote:
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure
On 01.03.2024 00:28, Stefano Stabellini wrote:
> On Wed, 14 Feb 2024, Federico Serafini wrote:
>> On 14/02/24 14:15, Jan Beulich wrote:
>>> On 14.02.2024 12:27, Federico Serafini wrote:
On 14/02/24 09:28, Jan Beulich wrote:
> On 13.02.2024 23:33, Stefano Stabellini wrote:
>>
On 2024-03-01 02:56, Stefano Stabellini wrote:
Hi all,
This patch broke gitlab-ci. The jobs failing are the cppcheck jobs.
xen/scripts/xen-analysis.py --run-cppcheck --cppcheck-misra -- -j80
No summary for rule 20.12
WARNING: Can't open
On 29.02.2024 23:57, Stefano Stabellini wrote:
> On Thu, 29 Feb 2024, Nicola Vetrini wrote:
>> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
>> of macro parameters shall be enclosed in parentheses". Therefore, some
>> macro definitions should gain additional parentheses to
45 matches
Mail list logo
