Hi Bjorn,
Looking forward to getting your more inputs and suggestions.
It seems /sys/bus/acpi/devices/PNP0A03:00/ is not a good place to create gsi
sysfs.
On 2024/2/15 16:37, Roger Pau Monné wrote:
> On Mon, Feb 12, 2024 at 01:18:58PM -0600, Bjorn Helgaas wrote:
>> On Mon, Feb 12, 2024 at
On 29.02.2024 17:49, Nicola Vetrini wrote:
> On 2024-02-29 17:40, Jan Beulich wrote:
>> On 29.02.2024 16:27, Nicola Vetrini wrote:
>>> --- a/xen/include/public/xen.h
>>> +++ b/xen/include/public/xen.h
>>> @@ -988,7 +988,7 @@ typedef struct {
>>>((b) >> 8) & 0xFF, ((b) >> 0) & 0xFF,
Hi Stefano,
> On 13 Feb 2024, at 23:33, Stefano Stabellini
> wrote:
>
> Signed-off-by: Stefano Stabellini
Coherent with what was discussed during the Misra meeting so:
Acked-by: Bertrand Marquis
Cheers
Bertrand
> ---
> docs/misra/rules.rst | 9 +
> 1 file changed, 9 insertions(+)
flight 184825 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184825/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 8 xen-boot fail REGR.
vs. 184816
flight 184820 xen-unstable real [real]
flight 184827 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184820/
http://logs.test-lab.xenproject.org/osstest/logs/184827/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Hi Julien,
On 2/28/2024 8:27 PM, Julien Grall wrote:
Hi Henry,
...here basically means we want to do the finding of the unused
region in toolstack. Since currently what we care about is only a
couple of pages instead of the whole memory map, could it be possible
that we do the opposite: in
flight 184826 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184826/
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 Wed, Feb 28, 2024 at 11:01 AM Anthony PERARD
wrote:
>
> On Tue, Jan 09, 2024 at 12:05:40PM -0500, Jason Andryuk wrote:
> > @@ -3430,7 +3431,7 @@ void libxl__spawn_qdisk_backend(libxl__egc *egc,
> > libxl__dm_spawn_state *dmss)
> > * because we will call this from unprivileged driver
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
/builds/xen-project/hardware/xen/xen/drivers/video/font_8x14.c: 'utf-8' codec
can't decode byte 0x9f in
From: Alexei Starovoitov
vmap/vmalloc APIs are used to map a set of pages into contiguous kernel
virtual space.
get_vm_area() with appropriate flag is used to request an area of kernel
address range. It'se used for vmalloc, vmap, ioremap, xen use cases.
- vmalloc use case dominates the usage.
From: Alexei Starovoitov
There are various users of get_vm_area() + ioremap_page_range() APIs.
Enforce that get_vm_area() was requested as VM_IOREMAP type and range
passed to ioremap_page_range() matches created vm_area to avoid
accidentally ioremap-ing into wrong address range.
Reviewed-by:
From: Alexei Starovoitov
xen grant table and xenbus ring are not ioremap the way arch specific code
is using it, so let's add VM_XEN flag to separate these use cases from
VM_IOREMAP users. xen will not and should not be calling
ioremap_page_range() on that range. /proc/vmallocinfo will print
From: Alexei Starovoitov
v2 -> v3
- added Christoph's reviewed-by to patch 1
- cap commit log lines to 75 chars
- factored out common checks in patch 3 into helper
- made vm_area_unmap_pages() return void
There are various users of kernel virtual address space:
vmalloc, vmap, ioremap, xen.
-
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:
> > > > > Signed-off-by: Stefano Stabellini
> > > > > ---
> >
On Tue, 27 Feb 2024, Vikram Garhwal wrote:
> From: Juergen Gross
>
> Add the callbacks for mapping/unmapping guest memory via grants to the
> special grant memory region.
>
> Signed-off-by: Juergen Gross
> Signed-off-by: Vikram Garhwal
Reviewed-by: Stefano Stabellini
> ---
>
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 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 that all
> current and future users will be
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 that all
> current and future users will be
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 that all
> current and future users will be
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 that all
> current and future users will be
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 that all
> current and future users will be
On Thu, 29 Feb 2024, Nicola Vetrini wrote:
> On 2024-02-29 17:40, Jan Beulich wrote:
> > On 29.02.2024 16:27, Nicola Vetrini wrote:
> > > --- a/xen/include/public/xen.h
> > > +++ b/xen/include/public/xen.h
> > > @@ -988,7 +988,7 @@ typedef struct {
> > >((b) >> 8) & 0xFF, ((b) >> 0) &
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 into PV guests, meaning that PV guests
generally see x2APIC except on
On Thu, 29 Feb 2024, Michal Orzel wrote:
>
> On 29/02/2024 13:40, Julien Grall wrote:
> >
> >
> > On 29/02/2024 12:37, Michal Orzel wrote:
> >> Hi Julien,
> >
> > Hi Michal,
> >
> >>
> >> On 29/02/2024 13:35, Julien Grall wrote:
> >>> On 29/02/2024 12:13, Michal Orzel wrote:
> Since
flight 184816 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184816/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-check fail blocked in 184802
test-amd64-amd64-xl-qemut-win7-amd64
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
flight 184823 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184823/
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 29/02/2024 12:47 pm, Jan Beulich wrote:
>> @@ -830,11 +846,10 @@ void recalculate_cpuid_policy(struct domain *d)
>> }
>>
>> /*
>> - * Allow the toolstack to set HTT, X2APIC and CMP_LEGACY. These bits
>> + * Allow the toolstack to set HTT and CMP_LEGACY. These bits
>>
On Thu, 29 Feb 2024, Michal Orzel wrote:
> On 29/02/2024 11:10, Julien Grall wrote:
> >
> >
> > Hi,
> >
> > On 29/02/2024 10:07, Michal Orzel wrote:
> >>
> >>
> >> On 28/02/2024 23:27, Stefano Stabellini wrote:
> >>>
> >>>
> >>> On Wed, 28 Feb 2024, Michal Orzel wrote:
> Hi Julien,
>
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 Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
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, Jan Beulich wrote:
> > the release is
On Thu, 29 Feb 2024, Julien Grall wrote:
> On 29/02/2024 14:07, Jan Beulich wrote:
> > On 29.02.2024 14:44, Julien Grall wrote:
> > > Hi Jan,
> > >
> > > On 29/02/2024 12:51, Jan Beulich wrote:
> > > > On 29.02.2024 13:32, Julien Grall wrote:
> > > > > On 29/02/2024 12:17, Jan Beulich wrote:
> >
flight 184813 xen-4.18-testing real [real]
flight 184821 xen-4.18-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184813/
http://logs.test-lab.xenproject.org/osstest/logs/184821/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 29.02.2024 18:04, Jürgen Groß wrote:
> On 29.02.24 17:54, Jan Beulich wrote:
>> On 29.02.2024 17:45, Juergen Gross wrote:
>>> On 29.02.24 17:31, Jan Beulich wrote:
On 29.02.2024 17:29, Jürgen Groß wrote:
> On 29.02.24 16:46, Jan Beulich wrote:
>> On 12.12.2023 10:47, Juergen Gross
On 29.02.2024 17:45, Nicola Vetrini wrote:
> On 2024-02-29 17:37, Jan Beulich wrote:
>> On 29.02.2024 16:27, Nicola Vetrini wrote:
>>> --- a/xen/arch/x86/include/asm/irq.h
>>> +++ b/xen/arch/x86/include/asm/irq.h
>>> @@ -179,9 +179,9 @@ void cleanup_domain_irq_mapping(struct domain *d);
>>>
On 29.02.24 17:54, Jan Beulich wrote:
On 29.02.2024 17:45, Juergen Gross wrote:
On 29.02.24 17:31, Jan Beulich wrote:
On 29.02.2024 17:29, Jürgen Groß wrote:
On 29.02.24 16:46, Jan Beulich wrote:
On 12.12.2023 10:47, Juergen Gross wrote:
Allow 16 bits per cpu number, which is the limit
On Wed, 2024-02-28 at 23:11 +, Andrew Cooper wrote:
> Furthermore, Linux has regularly been bumping minimum toolchain
> versions
> due to code generation issues, and we'd be foolish not pay attention.
Do they document that?
It looks like their doc is pretty old, because in
On 29.02.2024 17:45, Juergen Gross wrote:
> On 29.02.24 17:31, Jan Beulich wrote:
>> On 29.02.2024 17:29, Jürgen Groß wrote:
>>> On 29.02.24 16:46, Jan Beulich wrote:
On 12.12.2023 10:47, Juergen Gross wrote:
> Allow 16 bits per cpu number, which is the limit imposed by
>
On Thu, 2024-02-29 at 08:58 +0100, Jan Beulich wrote:
> On 28.02.2024 23:58, Julien Grall wrote:
> > On 27/02/2024 07:55, Jan Beulich wrote:
> > > On 26.02.2024 18:39, Oleksii Kurochko wrote:
> > > > This patch doesn't represent a strict lower bound for GCC and
> > > > GNU Binutils; rather, these
On 2024-02-29 17:47, Andrew Cooper wrote:
On 29/02/2024 4:21 pm, Nicola Vetrini wrote:
On 2024-02-29 17:10, Andrew Cooper wrote:
On 29/02/2024 3:27 pm, Nicola Vetrini wrote:
diff --git a/xen/include/xen/kconfig.h b/xen/include/xen/kconfig.h
index c25dc0f6c2a9..b7e70289737b 100644
---
On 2024-02-29 17:42, Jan Beulich wrote:
On 29.02.2024 16:27, Nicola Vetrini wrote:
--- a/xen/common/perfc.c
+++ b/xen/common/perfc.c
@@ -10,10 +10,10 @@
#include
#include
-#define PERFCOUNTER( var, name ) { name, TYPE_SINGLE, 0
},
-#define PERFCOUNTER_ARRAY( var, name, size )
On 2024-02-29 17:40, Jan Beulich wrote:
On 29.02.2024 16:27, Nicola Vetrini wrote:
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -988,7 +988,7 @@ typedef struct {
((b) >> 8) & 0xFF, ((b) >> 0) & 0xFF,
\
((c) >> 8) & 0xFF, ((c) >>
On 29/02/2024 4:21 pm, Nicola Vetrini wrote:
> On 2024-02-29 17:10, Andrew Cooper wrote:
>> On 29/02/2024 3:27 pm, Nicola Vetrini wrote:
>>> diff --git a/xen/include/xen/kconfig.h b/xen/include/xen/kconfig.h
>>> index c25dc0f6c2a9..b7e70289737b 100644
>>> --- a/xen/include/xen/kconfig.h
>>> +++
On 29.02.2024 17:40, Nicola Vetrini wrote:
> On 2024-02-29 17:25, Jan Beulich wrote:
>> On 29.02.2024 16:27, Nicola Vetrini wrote:
>>> --- a/xen/include/xen/kconfig.h
>>> +++ b/xen/include/xen/kconfig.h
>>> @@ -25,7 +25,7 @@
>>> #define __ARG_PLACEHOLDER_1 0,
>>> #define config_enabled(cfg)
On 29.02.24 17:31, Jan Beulich wrote:
On 29.02.2024 17:29, Jürgen Groß wrote:
On 29.02.24 16:46, Jan Beulich wrote:
On 12.12.2023 10:47, Juergen Gross wrote:
Allow 16 bits per cpu number, which is the limit imposed by
spinlock_tickets_t.
This will allow up to 65535 cpus, while increasing
On 2024-02-29 17:37, Jan Beulich wrote:
On 29.02.2024 16:27, Nicola Vetrini wrote:
--- a/xen/arch/x86/include/asm/irq.h
+++ b/xen/arch/x86/include/asm/irq.h
@@ -179,9 +179,9 @@ void cleanup_domain_irq_mapping(struct domain *d);
void *__ret = radix_tree_lookup(&(d)->arch.hvm.emuirq_pirq,
On 29.02.2024 16:27, Nicola Vetrini wrote:
> --- a/xen/common/perfc.c
> +++ b/xen/common/perfc.c
> @@ -10,10 +10,10 @@
> #include
> #include
>
> -#define PERFCOUNTER( var, name ) { name, TYPE_SINGLE, 0 },
> -#define PERFCOUNTER_ARRAY( var, name, size ) { name, TYPE_ARRAY, size
On 29.02.2024 16:27, Nicola Vetrini wrote:
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -988,7 +988,7 @@ typedef struct {
>((b) >> 8) & 0xFF, ((b) >> 0) & 0xFF, \
>((c) >> 8) & 0xFF, ((c) >> 0) & 0xFF,
On 2024-02-29 17:25, Jan Beulich wrote:
On 29.02.2024 16:27, Nicola Vetrini wrote:
--- a/xen/include/xen/kconfig.h
+++ b/xen/include/xen/kconfig.h
@@ -25,7 +25,7 @@
#define __ARG_PLACEHOLDER_1 0,
#define config_enabled(cfg) _config_enabled(cfg)
#define _config_enabled(value)
On 29.02.2024 16:27, Nicola Vetrini wrote:
> --- a/xen/arch/x86/include/asm/irq.h
> +++ b/xen/arch/x86/include/asm/irq.h
> @@ -179,9 +179,9 @@ void cleanup_domain_irq_mapping(struct domain *d);
> void *__ret = radix_tree_lookup(&(d)->arch.hvm.emuirq_pirq, emuirq);\
> __ret ?
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) \
> .matches = is_affected_midr_range, \
On 29.02.2024 17:29, Jürgen Groß wrote:
> On 29.02.24 16:46, Jan Beulich wrote:
>> On 12.12.2023 10:47, Juergen Gross wrote:
>>> Allow 16 bits per cpu number, which is the limit imposed by
>>> spinlock_tickets_t.
>>>
>>> This will allow up to 65535 cpus, while increasing only the size of
>>>
On 29.02.24 16:46, Jan Beulich wrote:
On 12.12.2023 10:47, Juergen Gross wrote:
Allow 16 bits per cpu number, which is the limit imposed by
spinlock_tickets_t.
This will allow up to 65535 cpus, while increasing only the size of
recursive spinlocks in debug builds from 8 to 12 bytes.
I think
On 26.02.2024 18:38, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/nospec.h
> @@ -0,0 +1,25 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/* Copyright (C) 2024 Vates */
> +
> +#ifndef _ASM_GENERIC_NOSPEC_H
> +#define _ASM_GENERIC_NOSPEC_H
Btw, at the very last
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:
>- new patch
> ---
> xen/include/asm-generic/bitops/fls.h | 18
On 29.02.2024 16:27, Nicola Vetrini wrote:
> --- a/xen/include/xen/kconfig.h
> +++ b/xen/include/xen/kconfig.h
> @@ -25,7 +25,7 @@
> #define __ARG_PLACEHOLDER_1 0,
> #define config_enabled(cfg) _config_enabled(cfg)
> #define _config_enabled(value) __config_enabled(__ARG_PLACEHOLDER_##value)
>
On 2024-02-29 17:10, Andrew Cooper wrote:
On 29/02/2024 3:27 pm, Nicola Vetrini wrote:
diff --git a/xen/include/xen/kconfig.h b/xen/include/xen/kconfig.h
index c25dc0f6c2a9..b7e70289737b 100644
--- a/xen/include/xen/kconfig.h
+++ b/xen/include/xen/kconfig.h
@@ -25,7 +25,7 @@
#define
Hi Julien,
On Thu, 2024-02-29 at 13:54 +, Julien Grall wrote:
> Hi Oleksii,
>
> On 26/02/2024 17:38, Oleksii Kurochko wrote:
> > These functions can be useful for architectures that don't
> > have corresponding arch-specific instructions.
> >
> > Signed-off-by: Oleksii Kurochko
> > ---
> >
On 29/02/2024 3:27 pm, Nicola Vetrini wrote:
> diff --git a/xen/include/xen/kconfig.h b/xen/include/xen/kconfig.h
> index c25dc0f6c2a9..b7e70289737b 100644
> --- a/xen/include/xen/kconfig.h
> +++ b/xen/include/xen/kconfig.h
> @@ -25,7 +25,7 @@
> #define __ARG_PLACEHOLDER_1 0,
> #define
On Thu, 2024-02-29 at 15:01 +0100, Jan Beulich wrote:
> On 29.02.2024 14:49, Julien Grall wrote:
> > On 26/02/2024 17:38, Oleksii Kurochko wrote:
> > > --- /dev/null
> > > +++ b/xen/arch/riscv/include/asm/nospec.h
> > > @@ -0,0 +1,25 @@
> > > +/* SPDX-License-Identifier: GPL-2.0 */
> >
> > New
On Tue, Feb 27, 2024 at 05:31:28PM -0800, Alexei Starovoitov wrote:
> What would it look like with a cookie?
> A static inline wrapper around get_vm_area() that returns area->addr ?
> And the start address of vmap range will be such a cookie?
Hmm, just making the kernel virtual address the cookie
On 26.02.2024 18:38, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/include/asm-generic/bitops/fls.h
> @@ -0,0 +1,18 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ASM_GENERIC_BITOPS_FLS_H_
> +#define _ASM_GENERIC_BITOPS_FLS_H_
> +
> +/**
> + * fls - find last (most-significant) bit
From: Kunwu Chan
[ Upstream commit 3693bb4465e6e32a204a5b86d3ec7e6b9f7e67c2 ]
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.
Signed-off-by: Kunwu Chan
Reported-by: kernel test
From: Kunwu Chan
[ Upstream commit 3693bb4465e6e32a204a5b86d3ec7e6b9f7e67c2 ]
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.
Signed-off-by: Kunwu Chan
Reported-by: kernel test
From: Kunwu Chan
[ Upstream commit 3693bb4465e6e32a204a5b86d3ec7e6b9f7e67c2 ]
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.
Signed-off-by: Kunwu Chan
Reported-by: kernel test
From: Kunwu Chan
[ Upstream commit 3693bb4465e6e32a204a5b86d3ec7e6b9f7e67c2 ]
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.
Signed-off-by: Kunwu Chan
Reported-by: kernel test
From: Kunwu Chan
[ Upstream commit 3693bb4465e6e32a204a5b86d3ec7e6b9f7e67c2 ]
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.
Signed-off-by: Kunwu Chan
Reported-by: kernel test
From: Kunwu Chan
[ Upstream commit 3693bb4465e6e32a204a5b86d3ec7e6b9f7e67c2 ]
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.
Signed-off-by: Kunwu Chan
Reported-by: kernel test
From: Kunwu Chan
[ Upstream commit 3693bb4465e6e32a204a5b86d3ec7e6b9f7e67c2 ]
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.
Signed-off-by: Kunwu Chan
Reported-by: kernel test
On 12.12.2023 10:47, Juergen Gross wrote:
> Allow 16 bits per cpu number, which is the limit imposed by
> spinlock_tickets_t.
>
> This will allow up to 65535 cpus, while increasing only the size of
> recursive spinlocks in debug builds from 8 to 12 bytes.
I think we want to be more conservative
On 29.02.24 16:32, Jan Beulich wrote:
On 12.12.2023 10:47, Juergen Gross wrote:
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -541,6 +541,55 @@ void rspin_unlock_irqrestore(rspinlock_t *lock, unsigned
long flags)
local_irq_restore(flags);
}
+int
On 12.12.2023 10:47, Juergen Gross wrote:
> In reality all spin_*() functions are macros which are defined to just
> call a related real function.
>
> Remove this macro layer, as it is adding complexity without any gain.
>
> Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
with the same
On 12.12.2023 10:47, Juergen Gross wrote:
> --- a/xen/common/spinlock.c
> +++ b/xen/common/spinlock.c
> @@ -541,6 +541,55 @@ void rspin_unlock_irqrestore(rspinlock_t *lock, unsigned
> long flags)
> local_irq_restore(flags);
> }
>
> +int nrspin_trylock(rspinlock_t *lock)
> +{
> +
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 that all
current and future users will be safe with respect to expansions that
can possibly
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 that all
current and future users will be safe with respect to expansions that
can possibly
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 that all
current and future users will be safe with respect to expansions that
can possibly
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore
the macro XEN_DEFINE_UUID_ should wrap its parameters in parentheses.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/include/public/xen.h | 2 +-
1
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 that all
current and future users will be safe with respect to expansions that
can possibly
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 that all
current and future users will be safe with respect to expansions that
can possibly
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 that all
current and future users will be safe with respect to expansions that
can possibly
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 that all
current and future users will be safe with respect to expansions that
can possibly
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 that all
current and future users will be safe with respect to expansions that
can possibly
Hi all,
this series aims to refactor some macros that cause violations of MISRA C Rule
20.7 ("Expressions resulting from the expansion of macro parameters shall be
enclosed in parentheses"). All the macros touched by these patches are in some
way involved in violations, and the strategy adopted
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 that all
current and future users will be safe with respect to expansions that
can possibly
On 29.02.2024 15:21, Roger Pau Monné wrote:
> On Thu, Feb 29, 2024 at 02:12:26PM +0100, Jan Beulich wrote:
>> Bah, that's not even Clang, only LLVM.
>
> I'm confused by this, doesn't your llvm package include clang?
No, there are quite a few RPMs in general in SLES to cover everything,
yet on
On 29/02/2024 1:29 pm, Jan Beulich wrote:
> On 29.02.2024 14:23, Andrew Cooper wrote:
>> On 29/02/2024 12:47 pm, Jan Beulich wrote:
>>> On 29.02.2024 11:43, Andrew Cooper wrote:
Right now, the host x2APIC setting filters into the PV max and default
policies, yet PV guests cannot set
On Thu, Feb 29, 2024 at 02:12:26PM +0100, Jan Beulich wrote:
> On 29.02.2024 14:01, Jan Beulich wrote:
> > On 29.02.2024 13:40, Roger Pau Monné wrote:
> >> On Thu, Feb 29, 2024 at 01:11:55PM +0100, Jan Beulich wrote:
> >>> On 29.02.2024 10:55, Roger Pau Monne wrote:
> --- a/README
> +++
On 29.02.24 15:14, Jan Beulich wrote:
On 12.12.2023 10:47, Juergen Gross wrote:
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -458,6 +458,23 @@ void _spin_barrier(spinlock_t *lock)
spin_barrier_common(>tickets, >debug, LOCK_PROFILE_PAR);
}
+int rspin_is_locked(const
On 29/02/2024 14:07, Jan Beulich wrote:
On 29.02.2024 14:44, Julien Grall wrote:
Hi Jan,
On 29/02/2024 12:51, Jan Beulich wrote:
On 29.02.2024 13:32, Julien Grall wrote:
On 29/02/2024 12:17, Jan Beulich wrote:
On 29.02.2024 13:05, Andrew Cooper wrote:
On 29/02/2024 10:23 am, Julien
On 12.12.2023 10:47, Juergen Gross wrote:
> --- a/xen/common/spinlock.c
> +++ b/xen/common/spinlock.c
> @@ -458,6 +458,23 @@ void _spin_barrier(spinlock_t *lock)
> spin_barrier_common(>tickets, >debug, LOCK_PROFILE_PAR);
> }
>
> +int rspin_is_locked(const rspinlock_t *lock)
> +{
> +/*
Hi Jan,
On 29/02/2024 14:03, Jan Beulich wrote:
On 29.02.2024 14:54, Julien Grall wrote:
On 26/02/2024 17:38, 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
On 29.02.2024 14:44, Julien Grall wrote:
> Hi Jan,
>
> On 29/02/2024 12:51, Jan Beulich wrote:
>> On 29.02.2024 13:32, Julien Grall wrote:
>>> On 29/02/2024 12:17, Jan Beulich wrote:
On 29.02.2024 13:05, Andrew Cooper wrote:
> On 29/02/2024 10:23 am, Julien Grall wrote:
> IOW it
On 29.02.2024 14:54, Julien Grall wrote:
> On 26/02/2024 17:38, 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:
>> - new patch
>> ---
>>
On 2/29/24 08:23, Jan Beulich wrote:
> On 29.02.2024 14:15, Roger Pau Monne wrote:
>> Currently vpci_deassign_device() is called without holding the per-domain
>> pci_lock in pci_remove_device(), which leads to:
>>
>> Assertion 'rw_is_write_locked(>domain->pci_lock)' failed at
>>
On 29.02.2024 14:49, Julien Grall wrote:
> On 26/02/2024 17:38, Oleksii Kurochko wrote:
>> --- /dev/null
>> +++ b/xen/arch/riscv/include/asm/nospec.h
>> @@ -0,0 +1,25 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>
> New file should use the SPDX tag GPL-2.0-only. I guess this could be
> fixed on
On 12.12.2023 10:47, Juergen Gross wrote:
> @@ -377,25 +388,25 @@ void _spin_unlock_irqrestore(spinlock_t *lock, unsigned
> long flags)
> local_irq_restore(flags);
> }
>
> +static int always_inline spin_is_locked_common(const spinlock_tickets_t *t)
> +{
> +return t->head != t->tail;
>
On 29.02.24 14:49, Jan Beulich wrote:
On 12.12.2023 10:47, Juergen Gross wrote:
In order to prepare a type-safe recursive spinlock structure, add
explicitly non-recursive locking functions to be used for non-recursive
locking of spinlocks, which are used recursively, too.
Signed-off-by:
Hi Oleksii,
On 26/02/2024 17:38, 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:
- new patch
---
xen/include/asm-generic/bitops/fls.h | 18
On 12.12.2023 10:47, Juergen Gross wrote:
> In order to prepare a type-safe recursive spinlock structure, add
> explicitly non-recursive locking functions to be used for non-recursive
> locking of spinlocks, which are used recursively, too.
>
> Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
Hi Oleksii,
On 26/02/2024 17:38, Oleksii Kurochko wrote:
From the unpriviliged doc:
No standard hints are presently defined.
We anticipate standard hints to eventually include memory-system spatial
and temporal locality hints, branch prediction hints, thread-scheduling
hints,
1 - 100 of 153 matches
Mail list logo
