On 27.05.2024 16:53, Nicola Vetrini wrote:
> Rule 8.4 states: "A compatible declaration shall be visible when
> an object or function with external linkage is defined".
>
> The function do_general_protection is either used is asm code
> or only within this unit, so there is no risk of this getting
On 27.05.2024 16:53, Nicola Vetrini wrote:
> Rule 8.4 states: "A compatible declaration shall be visible when
> an object or function with external linkage is defined."
>
> These variables are only referenced from asm modules, so they
> need to be extern and there is negligible risk of them being
On 24.05.2024 13:08, Oleksii Kurochko wrote:
> The following generic functions were introduced:
> * test_bit
> * generic__test_and_set_bit
> * generic__test_and_clear_bit
> * generic__test_and_change_bit
>
> These functions and macros can be useful for architectures
> that don't have corresponding
flight 186164 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186164/
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 Mon, 27 May 2024, Jan Beulich wrote:
> On 27.05.2024 16:53, Nicola Vetrini wrote:
> > The parentheses in this regular expression should be doubly
> > escaped because they are undergo escaping twice.
>
> Do you maybe mean "undergo expansion twice"?
Ahah yes. I fixed it on commit:
Acked-by: Ste
flight 186161 linux-linus real [real]
flight 186162 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186161/
http://logs.test-lab.xenproject.org/osstest/logs/186162/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-
Hi Roger,
On 23/05/2024 08:55, Roger Pau Monné wrote:
On Wed, May 22, 2024 at 06:59:20PM -0400, Stewart Hildebrand wrote:
From: Volodymyr Babchuk
Guest can try to read config space using different access sizes: 8,
16, 32, 64 bits. We need to take this into account when we are
returning an err
On Wed, 15 May 2024, Stefano Stabellini wrote:
> On Wed, 15 May 2024, Jan Beulich wrote:
> > On 15.05.2024 01:15, Stefano Stabellini wrote:
> > > Add D4.12 with the same explanation as the rules of the R21 series.
> > > D4.12 refers to the standard library memory allocation functions and
> > > simi
On Mon, 27 May 2024, Jürgen Groß wrote:
> On 25.05.24 01:19, Stefano Stabellini wrote:
> > On Fri, 24 May 2024, Jürgen Groß wrote:
> > > On 24.05.24 15:58, Julien Grall wrote:
> > > > Hi Henry,
> > > >
> > > > + Juergen as the Xenstore maintainers. I'd like his opinion on the
> > > > approach.
> >
Hi Edgar,
On 24/5/24 12:51, Edgar E. Iglesias wrote:
From: "Edgar E. Iglesias"
Add xen_mr_is_memory() to abstract away tests for the
xen_memory MR.
No functional changes.
Signed-off-by: Edgar E. Iglesias
Reviewed-by: Stefano Stabellini
Acked-by: David Hildenbrand
---
hw/xen/xen-hvm-comm
On 24/5/24 12:51, Edgar E. Iglesias wrote:
From: "Edgar E. Iglesias"
Pass the ram_addr offset to xen_map_cache.
This is in preparation for adding grant mappings that need
to compute the address within the RAMBlock.
No functional changes.
Signed-off-by: Edgar E. Iglesias
Reviewed-by: David Hi
On Mon, 2024-05-27 at 17:55 +0200, Jan Beulich wrote:
> On 27.05.2024 17:52, Oleksii K. wrote:
> > On Mon, 2024-05-27 at 17:12 +0200, Jan Beulich wrote:
> > > On 27.05.2024 15:58, Oleksii K. wrote:
> > > > I would like to remind you that the code freeze date for Xen
> > > > 4.19
> > > > is
> > > >
On Sun, 2024-04-07 at 16:49 -0400, Jason Andryuk wrote:
> From: Jason Andryuk
>
> Add entry for backendtype=tap support in libxl. blktap needs some
> changes to work with libxl, which haven't been merged. They are
> available from this PR:
> https://github.com/xapi-project/blktap/pull/394
>
>
On 27.05.2024 17:52, Oleksii K. wrote:
> On Mon, 2024-05-27 at 17:12 +0200, Jan Beulich wrote:
>> On 27.05.2024 15:58, Oleksii K. wrote:
>>> I would like to remind you that the code freeze date for Xen 4.19
>>> is
>>> May 31, 2024.
>>
>> I may be confused: With feature freeze having been last Frida
On Mon, 2024-05-27 at 17:12 +0200, Jan Beulich wrote:
> On 27.05.2024 15:58, Oleksii K. wrote:
> > I would like to remind you that the code freeze date for Xen 4.19
> > is
> > May 31, 2024.
>
> I may be confused: With feature freeze having been last Friday aiui,
> isn't
> this a little too short a
Oleksii,
On 22.05.2024 10:37, Sergiy Kibrik wrote:
> Three remaining patches to separate support of Intel & AMD CPUs in Xen build.
> Most of related patches from previous series had already been merged.
> Specific changes since v3 are provided per-patch.
>
> v3 series here:
> https://lore.kernel.
On 22.05.2024 10:42, Sergiy Kibrik wrote:
> The default switch case block is wanted here, to handle situation
> e.g. of unexpected c->x86_vendor value -- then no mcheck init is done, but
> misleading message still gets logged anyway.
>
> Signed-off-by: Sergiy Kibrik
Acked-by: Jan Beulich
flight 186159 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186159/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl-rtds 8 xen-boot fail like 186144
test-armhf-armhf-libvirt 16 saver
On 22.05.2024 10:40, Sergiy Kibrik wrote:
> --- a/xen/arch/x86/msr.c
> +++ b/xen/arch/x86/msr.c
> @@ -24,6 +24,8 @@
>
> #include
>
> +#include "cpu/mcheck/mce.h"
Considering that I asked about this before, I'm a little irritated
that this is is entirely unadorned. Such an unusual #include wa
On 27.05.2024 16:53, Nicola Vetrini wrote:
> The parentheses in this regular expression should be doubly
> escaped because they are undergo escaping twice.
Do you maybe mean "undergo expansion twice"?
Jan
> Signed-off-by: Nicola Vetrini
> ---
> automation/eclair_analysis/ECLAIR/deviations.ecl
On 27.05.2024 16:53, Nicola Vetrini wrote:
> These files are used when debugging Xen, and are not meant to comply
> with MISRA rules at the moment.
>
> No functional change.
>
> Signed-off-by: Nicola Vetrini
Acked-by: Jan Beulich
On 27.05.2024 15:58, Oleksii K. wrote:
> I would like to remind you that the code freeze date for Xen 4.19 is
> May 31, 2024.
I may be confused: With feature freeze having been last Friday aiui, isn't
this a little too short a period? I was actually expecting a longer-than-
normal one to account f
These files are used when debugging Xen, and are not meant to comply
with MISRA rules at the moment.
No functional change.
Signed-off-by: Nicola Vetrini
---
docs/misra/exclude-list.json | 8
1 file changed, 8 insertions(+)
diff --git a/docs/misra/exclude-list.json b/docs/misra/exclude
The parentheses in this regular expression should be doubly
escaped because they are undergo escaping twice.
Signed-off-by: Nicola Vetrini
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/automation/eclair_analysis/ECLAI
Hi all,
this series contains various miscellaneous changes to the ECLAIR and deviations
for MISRA rules
Nicola Vetrini (4):
docs/misra: exclude gdbsx from MISRA compliance
automation/eclair_analysis: avoid an ECLAIR warning about escaping
x86: address violations of MISRA C Rule 8.4
x86/tr
Rule 8.4 states: "A compatible declaration shall be visible when
an object or function with external linkage is defined".
The function do_general_protection is either used is asm code
or only within this unit, so there is no risk of this getting
out of sync with its definition, but the function mu
Rule 8.4 states: "A compatible declaration shall be visible when
an object or function with external linkage is defined."
These variables are only referenced from asm modules, so they
need to be extern and there is negligible risk of them being
used improperly without noticing.
As a result, they
On 25.05.24 01:19, Stefano Stabellini wrote:
On Fri, 24 May 2024, Jürgen Groß wrote:
On 24.05.24 15:58, Julien Grall wrote:
Hi Henry,
+ Juergen as the Xenstore maintainers. I'd like his opinion on the approach.
The documentation of the new logic is in:
https://lore.kernel.org/xen-devel/202405
On Sat, 2024-05-25 at 00:06 +0100, Julien Grall wrote:
> Hi Stefano,
>
> You have sent a new version. But you didn't reply to Juergen's
> comment.
>
> While he is not the maintainer of the Arm code, he is the Xenstore
> maintainer. Even if I agree with this approach I don't feel this is
> right
Hi all,
I would like to remind you that the code freeze date for Xen 4.19 is
May 31, 2024.
I'm okay with bug fixes being committed without my release ack (just CC
me), except in cases where a one of maintainers gives a strong NACK.
Have a nice week!
Best regards,
Oleksii
I think we can consider to have this patch series in Xen 4.19 release:
Release-acked-by: Oleksii Kurochko
~ Oleksii
On Fri, 2024-05-24 at 21:03 +0100, Andrew Cooper wrote:
> bitops.h is a mess. It has grown organtically over many years, and
> forces
> unreasonable repsonsibilities out into the
On 24.05.2024 22:03, Andrew Cooper wrote:
> The #include can move to the top of the file now now that
> generic_f?s() have been untangled.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
On 24.05.2024 22:03, Andrew Cooper wrote:
> Implement ffs64() and fls64() as plain static inlines, dropping the ifdefary
> and intermediate generic_f?s64() forms.
>
> Add tests for all interesting bit positions at 32bit boundaries.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Rev
On 24.05.2024 22:03, Andrew Cooper wrote:
> From: Oleksii Kurochko
>
> This is most easily done together because of how arm32 is currently
> structured, but it does just mirror the existing ffs()/ffsl() work.
>
> Introduce compile and boot time testing.
>
> Signed-off-by: Oleksii Kurochko
> Si
On 27.05.2024 15:27, Jan Beulich wrote:
> On 24.05.2024 22:03, Andrew Cooper wrote:
>> --- a/xen/arch/x86/include/asm/bitops.h
>> +++ b/xen/arch/x86/include/asm/bitops.h
>> @@ -432,12 +432,28 @@ static inline int ffsl(unsigned long x)
>>
>> static always_inline unsigned int arch_ffs(unsigned int
On 24.05.2024 22:03, Andrew Cooper wrote:
> --- a/xen/arch/x86/include/asm/bitops.h
> +++ b/xen/arch/x86/include/asm/bitops.h
> @@ -432,12 +432,28 @@ static inline int ffsl(unsigned long x)
>
> static always_inline unsigned int arch_ffs(unsigned int x)
> {
> -int r;
> +unsigned int r;
>
From: Yunseong Kim
memory allocation failure handling in the loadpolicy module.
Signed-off-by: Yunseong Kim
---
tools/flask/utils/loadpolicy.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/tools/flask/utils/loadpolicy.c b/tools/flask/utils/loadpolicy.c
index 76710a256c..7f6bab4dcd 1
xen_pcifront_enable_irq() uses pci_read_config_byte() that returns
PCIBIOS_* codes. The error handling, however, assumes the codes are
normal errnos because it checks for < 0.
xen_pcifront_enable_irq() also returns the PCIBIOS_* code back to the
caller but the function is used as the (*pcibios_ena
On 24.05.2024 22:03, Andrew Cooper wrote:
> No more users.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
On 24.05.2024 22:03, Andrew Cooper wrote:
> --- a/xen/arch/x86/hvm/hpet.c
> +++ b/xen/arch/x86/hvm/hpet.c
> @@ -335,7 +335,7 @@ static void timer_sanitize_int_route(HPETState *h,
> unsigned int tn)
> * enabled pick the first irq.
> */
> timer_config(h, tn) |=
> -MASK_INSR(
On 24.05.2024 22:03, Andrew Cooper wrote:
> Just like ffs() in the previous changes. Express the upper bound of the
> testing in terms of BITS_PER_LONG as it varies between architectures.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
> @@ -458,6 +441,24 @@ static always_inline uns
On 24.05.2024 22:03, Andrew Cooper wrote:
> The asm in arch_ffs() is safe but inefficient.
>
> CMOV would be an improvement over a conditional branch, but for 64bit CPUs
> both Intel and AMD have provided enough details about the behaviour for a zero
> input. It is safe to pre-load the destinatio
On 24.05.2024 22:03, Andrew Cooper wrote:
> Perform constant-folding unconditionally, rather than having it implemented
> inconsistency between architectures.
>
> Confirm the expected behaviour with compile time and boot time tests.
>
> For non-constant inputs, use arch_ffs() if provided but fall
flight 186160 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186160/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 08281572aab5b1f7e05bf26de4148af19eddc8b7
baseline version:
ovmf 88a4de450f17c6a319c3e
Hi,
I'd like to dispute CVE-2021-47377: the issue fixed by upstream commit
8480ed9c2bbd56fc86524998e5f2e3e22f5038f6 can in no way be triggered by
an unprivileged user or by a remote attack of the system, as it requires
initiation of memory ballooning of the running system. This can be done
only b
On 27.05.2024 12:27, Sergiy Kibrik wrote:
> 23.05.24 17:50, Jan Beulich:
>> On 23.05.2024 15:07, Sergiy Kibrik wrote:
>>> 16.05.24 14:12, Jan Beulich:
On 15.05.2024 11:12, Sergiy Kibrik wrote:
> --- a/xen/arch/x86/include/asm/cpufeature.h
> +++ b/xen/arch/x86/include/asm/cpufeature.h
>
flight 186157 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186157/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 186145
Tests which did no
23.05.24 17:50, Jan Beulich:
On 23.05.2024 15:07, Sergiy Kibrik wrote:
16.05.24 14:12, Jan Beulich:
On 15.05.2024 11:12, Sergiy Kibrik wrote:
--- a/xen/arch/x86/include/asm/cpufeature.h
+++ b/xen/arch/x86/include/asm/cpufeature.h
@@ -81,7 +81,8 @@ static inline bool boot_cpu_has(unsigned int f
On Fri, May 24, 2024 at 04:16:01PM +0100, Alejandro Vallejo wrote:
> On 23/05/2024 17:13, Roger Pau Monné wrote:
> > On Wed, May 08, 2024 at 01:39:24PM +0100, Alejandro Vallejo wrote:
> >> @@ -86,10 +113,11 @@ static void boot_cpu(unsigned int cpu)
> >> BUG();
> >>
> >> /*
> >> -
On Fri, May 24, 2024 at 04:15:34PM +0100, Alejandro Vallejo wrote:
> On 24/05/2024 08:21, Roger Pau Monné wrote:
> > On Wed, May 08, 2024 at 01:39:24PM +0100, Alejandro Vallejo wrote:
> >> Make it so the APs expose their own APIC IDs in a LUT. We can use that LUT
> >> to
> >> populate the MADT, de
On 24.05.2024 22:03, Andrew Cooper wrote:
> generic_f?s() being static inline is the cause of lots of the complexity
> between the common and arch-specific bitops.h
>
> They appear to be static inline for constant-folding reasons (ARM uses them
> for this), but there are better ways to achieve the
On 24.05.2024 22:03, Andrew Cooper wrote:
> * Rename __attribute_pure__ to just __pure before it gains users.
> * Introduce __constructor which is going to be used in lib/, and is
>unconditionally cf_check.
> * Identify the areas of xen/bitops.h which are a mess.
> * Introduce xen/boot-chec
On Fri, May 24, 2024 at 06:16:01PM +0100, Alejandro Vallejo wrote:
> On 24/05/2024 09:58, Roger Pau Monné wrote:
> > On Wed, May 08, 2024 at 01:39:27PM +0100, Alejandro Vallejo wrote:
> >
> >> +rc = x86_topo_from_parts(&p->policy, threads_per_core,
> >> cores_per_pkg);
> >
> > I assume t
On Fri, May 24, 2024 at 06:03:22PM +0100, Alejandro Vallejo wrote:
> On 24/05/2024 09:39, Roger Pau Monné wrote:
> > On Wed, May 08, 2024 at 01:39:26PM +0100, Alejandro Vallejo wrote:
> >
> > Also you could initialize x2apic_id at definition:
> >
> > const struct test *t = &tests[j];
> > struct c
On Fri, May 24, 2024 at 02:21:09PM +0100, Julien Grall wrote:
> Hi,
>
> Sorry I didn't notice there was a v16 and posted comments on the v15. The
> only one is about the size of the list we iterate.
>
> On 23/05/2024 08:48, Roger Pau Monné wrote:
> > On Wed, May 22, 2024 at 06:59:23PM -0400, Stew
55 matches
Mail list logo
