On 03.04.2024 15:27, Daniel P. Smith wrote:
> On 4/3/24 08:05, Jan Beulich wrote:
>> On 03.04.2024 13:10, Daniel P. Smith wrote:
>>> On 4/3/24 02:16, Jan Beulich wrote:
On 02.04.2024 19:06, Andrew Cooper wrote:
>It is also quite
> obvious from XSM_TARGET that it has broken device
flight 185238 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185238/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 6 kernel-build fail in 185232 REGR. vs. 185228
Tests which are
flight 185242 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185242/
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 Fri, 29 Mar 2024, Nicola Vetrini wrote:
> These deviations deal with the following cases:
> - macro arguments used directly as initializer list arguments;
> - uses of the __config_enabled macro, that can't be brought
> into compliance without breaking its functionality;
> - exclude files that
On Thu, 28 Mar 2024, Simone Ballarin wrote:
> The Xen community wants to avoid using variadic functions except for
> specific circumstances where it feels appropriate by strict code review.
>
> Functions hypercall_create_continuation and hypercall_xlat_continuation
> are internal helper functions
On Thu, 28 Mar 2024, Simone Ballarin wrote:
> The Xen community wants to avoid using variadic functions except for
> specific circumstances where it feels appropriate by strict code review.
>
> Add deviation for printf()-like functions.
>
> Signed-off-by: Simone Ballarin
Reviewed-by: Stefano
On Thu, 28 Mar 2024, John Ernberg wrote:
> I have experience with the IMX8QXP, and the supported parts of the IMX8QM
> are identical.
>
> Help review patches touching these areas.
You need to add a signed-off-by. With that:
Acked-by: Stefano Stabellini
> ---
>
> v3:
> - New patch (Bertrand
On Wed, 27 Mar 2024, Julien Grall wrote:
> Hi,
>
> On 27/03/2024 11:39, Carlo Nonato wrote:
> > On Fri, Mar 22, 2024 at 8:26 AM Jan Beulich wrote:
> > >
> > > On 21.03.2024 18:31, Carlo Nonato wrote:
> > > > On Thu, Mar 21, 2024 at 4:57 PM Jan Beulich wrote:
> > > > >
> > > > > On 21.03.2024
On Wed, 3 Apr 2024, Nicola Vetrini wrote:
> On 2024-04-03 08:33, Jan Beulich wrote:
> > On 02.04.2024 09:22, Federico Serafini wrote:
> > > Use pseudo-keyword fallthrough to meet the requirements to deviate
> > > MISRA C:2012 Rule 16.3 ("An unconditional `break' statement shall
> > > terminate
On Fri, 29 Mar 2024, Nicola Vetrini wrote:
> These deviations deal with the following cases:
> - macro arguments used directly as initializer list arguments;
> - uses of the __config_enabled macro, that can't be brought
> into compliance without breaking its functionality;
> - exclude files that
On Fri, 29 Mar 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, 4 Apr 2024, Jan Beulich wrote:
> Further, according to the discussion on the matter: alternative_call() is
> quite similar in this regard, just that it uses typeof(). Imo it should be
> deviated here as well right away, no matter whether Eclair can actually be
> configured to also check
On Thu, 4 Apr 2024, Bertrand Marquis wrote:
> Hi Stefano,
>
> > On 4 Apr 2024, at 03:12, Stefano Stabellini wrote:
> >
> > Xen makes assumptions about the size of integer types on the various
> > architectures. Document these assumptions.
> >
> > Signed-off-by: Stefano Stabellini
> > ---
> >
On Thu, 4 Apr 2024, Jan Beulich wrote:
> On 04.04.2024 03:12, Stefano Stabellini wrote:
> > --- a/docs/misra/C-language-toolchain.rst
> > +++ b/docs/misra/C-language-toolchain.rst
> > @@ -480,4 +480,73 @@ The table columns are as follows:
> > - See Section "4.13 Preprocessing Directives" of
Hi Jan,
On 3/25/24 10:19 AM, Jan Beulich wrote:
> On 14.03.2024 23:15, Shawn Anastasio wrote:
>> Introduce a generic acpi.h header that provides the required definitions
>> to allow files including xen/acpi.h to be compiled. The definitions were
>> largely derived from the !CONFIG_ACPI parts of
On Thu, 4 Apr 2024, Michal Orzel wrote:
> These variables are useless. They are being assigned a value which is
> never used since UART is expected to be pre-configured.
>
> No functional change.
>
> Signed-off-by: Michal Orzel
Reviewed-by: Stefano Stabellini
On Thu, 4 Apr 2024, Jan Beulich wrote:
> On 04.04.2024 09:51, Michal Orzel wrote:
> > On Arm we don't use console_{suspend,resume} and the corresponding
> > stubs in serial drivers are being redundantly copied whenever a new
> > driver is added. Drop them as well as useless .endboot = NULL
The Xen PVH entrypoint is 32bit non-PIC code running at a default load
address of 0x100 (16MB) (CONFIG_PHYSICAL_START). Xen loads the
kernel at that physical address inside the PVH container.
When running a PVH Dom0, the system reserved addresses are mapped 1-1
into the PVH container. There
While parsing the PHDRs, store the maximum p_align value. This may be
consulted for moving a PVH image's load address.
Signed-off-by: Jason Andryuk
---
v6:
New
v7:
Remove printing p_align. It may be confusing and is only useful when
a PVH kernel needs to be moved.
---
Xen tries to load a PVH dom0 kernel at the fixed guest physical address
from the elf headers. For Linux, this defaults to 0x100 (16MB), but
it can be configured.
Unfortunately there exist firmwares that have reserved regions at this
address, so Xen fails to load the dom0 kernel since it's
Xen tries to load a PVH dom0 kernel at the fixed guest physical address
from the elf headers. For Linux, this defaults to 0x100 (16MB), but
it can be configured.
Unfortunately there exist firmwares that have reserved regions at this
address, so Xen fails to load the dom0 kernel since it's
flight 185236 xen-unstable real [real]
flight 185240 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185236/
http://logs.test-lab.xenproject.org/osstest/logs/185240/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
flight 185239 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185239/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 6fb3cc05dc8742ddbe7ea1038dd0111aed55e799
baseline version:
ovmf
On Thu, 2024-04-04 at 18:14 +0200, Jan Beulich wrote:
> On 04.04.2024 18:04, Oleksii wrote:
> > On Thu, 2024-04-04 at 17:01 +0200, Jan Beulich wrote:
> > > On 03.04.2024 12:20, Oleksii Kurochko wrote:
> > > Everything else okay-ish to me now, but I can't very well given
> > > an
> > > ack for
> >
On Thu, 2024-04-04 at 18:12 +0200, Jan Beulich wrote:
> On 04.04.2024 17:45, Oleksii wrote:
> > On Thu, 2024-04-04 at 15:22 +0200, Jan Beulich wrote:
> > > On 03.04.2024 12:19, Oleksii Kurochko wrote:
> > > > --- a/xen/include/xen/bitops.h
> > > > +++ b/xen/include/xen/bitops.h
> > > > @@ -65,10
On Thu, 2024-04-04 at 17:43 +0200, Jan Beulich wrote:
> On 04.04.2024 17:18, Oleksii wrote:
> > On Thu, 2024-04-04 at 12:07 +0200, Jan Beulich wrote:
> > > On 03.04.2024 12:19, Oleksii Kurochko wrote:
> > > > --- a/xen/arch/riscv/arch.mk
> > > > +++ b/xen/arch/riscv/arch.mk
> > > > @@ -3,16 +3,27
On 04.04.2024 18:04, Oleksii wrote:
> On Thu, 2024-04-04 at 17:01 +0200, Jan Beulich wrote:
>> On 03.04.2024 12:20, Oleksii Kurochko wrote:
>> Everything else okay-ish to me now, but I can't very well given an
>> ack for
>> a patch depending on things that haven't been committed yet and may
>>
On 04.04.2024 17:45, Oleksii wrote:
> On Thu, 2024-04-04 at 15:22 +0200, Jan Beulich wrote:
>> On 03.04.2024 12:19, Oleksii Kurochko wrote:
>>> --- a/xen/include/xen/bitops.h
>>> +++ b/xen/include/xen/bitops.h
>>> @@ -65,10 +65,164 @@ static inline int generic_flsl(unsigned long
>>> x)
>>> *
On Thu, 2024-04-04 at 17:01 +0200, Jan Beulich wrote:
> On 03.04.2024 12:20, Oleksii Kurochko wrote:
> > +#define emulate_cmpxchg_1_2(ptr, old, new, lr_sfx, sc_sfx) \
> > +({ \
> > + uint32_t *aligned_ptr; \
> > + unsigned long alignment_mask = sizeof(*aligned_ptr) -
> > sizeof(*(ptr)); \
>
On Thu, 2024-04-04 at 16:47 +0200, Jan Beulich wrote:
> On 03.04.2024 12:20, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/arch/riscv/include/asm/bitops.h
> > @@ -0,0 +1,146 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/* Copyright (C) 2012 Regents of the University of California
On Thu, 2024-04-04 at 15:22 +0200, Jan Beulich wrote:
> On 03.04.2024 12:19, Oleksii Kurochko wrote:
> > The patch introduces the following generic functions:
> > * test_bit
> > * generic__test_and_set_bit
> > * generic__test_and_clear_bit
> > * generic__test_and_change_bit
> >
> > Also, the
On 04.04.2024 17:18, Oleksii wrote:
> On Thu, 2024-04-04 at 12:07 +0200, Jan Beulich wrote:
>> On 03.04.2024 12:19, Oleksii Kurochko wrote:
>>> --- a/xen/arch/riscv/arch.mk
>>> +++ b/xen/arch/riscv/arch.mk
>>> @@ -3,16 +3,27 @@
>>>
>>> $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
flight 185235 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185235/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184708
test-amd64-amd64-libvirt-xsm 15
On Thu, 2024-04-04 at 12:07 +0200, Jan Beulich wrote:
> On 03.04.2024 12:19, Oleksii Kurochko wrote:
> > --- a/xen/arch/riscv/arch.mk
> > +++ b/xen/arch/riscv/arch.mk
> > @@ -3,16 +3,27 @@
> >
> > $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
> >
> > -CFLAGS-$(CONFIG_RISCV_64) +=
On Wed, 2024-04-03 at 13:53 +0200, Jan Beulich wrote:
> On 03.04.2024 12:54, Oleksii wrote:
> > On Wed, 2024-04-03 at 12:28 +0200, Jan Beulich wrote:
> > > On 03.04.2024 12:19, Oleksii Kurochko wrote:
> > > > This patch disables unnecessary configs for two cases:
> > > > 1. By utilizing
On 03.04.2024 12:20, Oleksii Kurochko wrote:
> +#define emulate_cmpxchg_1_2(ptr, old, new, lr_sfx, sc_sfx) \
> +({ \
> +uint32_t *aligned_ptr; \
> +unsigned long alignment_mask = sizeof(*aligned_ptr) - sizeof(*(ptr)); \
> +uint8_t new_val_bit = \
> +((unsigned long)(ptr) &
On 03.04.2024 12:20, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/bitops.h
> @@ -0,0 +1,146 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/* Copyright (C) 2012 Regents of the University of California */
> +
> +#ifndef _ASM_RISCV_BITOPS_H
> +#define
On 04.04.2024 16:21, Federico Serafini wrote:
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -333,6 +333,14 @@ of the short-circuit evaluation strategy of such logical
> operators."
>
On 03.04.2024 12:19, Oleksii Kurochko wrote:
> --- a/xen/include/xen/linux-compat.h
> +++ b/xen/include/xen/linux-compat.h
> @@ -19,4 +19,6 @@ typedef int64_t __s64;
>
> typedef paddr_t phys_addr_t;
>
> +#define __ffs(x) (ffsl(x) - 1)
To be truly Linux-compatible, the result type would
Update ECLAIR configuration to deviate uses of chk_fld and
alternative_vcall[0-9] macros.
Suggested-by: Stefano Stabellini
Signed-off-by: Federico Serafini
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 8
docs/misra/deviations.rst| 12
2
On 03.04.2024 12:19, Oleksii Kurochko wrote:
> This patch introduces the anchor riscv-fixed-randconfig,
> which includes all configurations that should be disabled for
> randconfig builds.
Oh, one thing I noticed while committing (and I think I said so before):
Can you please avoid phrases like
A malicious or buggy guest may generated buffered ioreqs faster than
QEMU can process them in handle_buffered_iopage(). The result is a
livelock - QEMU continuously processes ioreqs on the main thread without
iterating through the main loop which prevents handling other events,
processing timers,
On 03.04.2024 12:19, Oleksii Kurochko wrote:
> --- a/xen/include/xen/bitops.h
> +++ b/xen/include/xen/bitops.h
> @@ -201,7 +201,7 @@ static always_inline __pure int test_bit(int nr, const
> volatile void *addr)
>
> static always_inline __pure int fls(unsigned int x)
> {
> -if
On 2024-04-02 10:34, Jan Beulich wrote:
On 27.03.2024 22:51, Jason Andryuk wrote:
v6:
Select alignment from, in order, Note, PHDRs, then default
The comment in the public header also needs to reflect this change.
Yes. I'll update.
I'm going to tweak the code from elf->palign > PAGE_SIZE
On 2024-04-02 02:44, Jan Beulich wrote:
On 29.03.2024 15:41, Jason Andryuk wrote:
On 2024-03-28 12:47, Jan Beulich wrote:
On 27.03.2024 22:51, Jason Andryuk wrote:
--- a/xen/common/libelf/libelf-loader.c
+++ b/xen/common/libelf/libelf-loader.c
@@ -468,6 +468,7 @@ void elf_parse_binary(struct
flight 185231 linux-6.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185231/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 185167
test-amd64-amd64-xl-qemuu-win7-amd64
On 2024-04-04 06:09, Jan Beulich wrote:
On 27.03.2024 22:50, Jason Andryuk wrote:
@@ -36,6 +35,11 @@ static xc_evtchn_port_or_error_t console_evtchn;
static xentoollog_level minmsglevel = XTL_PROGRESS;
static void *logger;
+static inline uint64_t mb_to_bytes(int mem)
+{
+ return
On 04.04.2024 15:22, Andrew Cooper wrote:
> On 04/04/2024 1:45 pm, Jan Beulich wrote:
>> On 04.04.2024 12:41, Andrew Cooper wrote:
>>> @@ -9,6 +10,7 @@
>>> * -1 => Default, altered to 0/1 (if unspecified) by:
>>> * - TAA heuristics/settings for speculative safety
>>> *
flight 185237 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185237/
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 04.04.2024 14:59, Nicola Vetrini wrote:
> On 2024-03-28 11:25, Jan Beulich wrote:
>> On 11.07.2023 18:40, Roberto Bagnara wrote:
>>> Mandatory Rule 19.1 (An object shall not be assigned or copied to an
>>> overlapping object) is directly targeted at two undefined behaviors,
>>> one of which is
On 03.04.2024 12:19, Oleksii Kurochko wrote:
> The patch introduces the following generic functions:
> * test_bit
> * generic__test_and_set_bit
> * generic__test_and_clear_bit
> * generic__test_and_change_bit
>
> Also, the patch introduces the following generics which are
> used by the functions
On 04/04/2024 1:45 pm, Jan Beulich wrote:
> On 04.04.2024 12:41, Andrew Cooper wrote:
>> @@ -9,6 +10,7 @@
>> * -1 => Default, altered to 0/1 (if unspecified) by:
>> * - TAA heuristics/settings for speculative safety
>> * - "TSX vs PCR3" select for TSX memory
On 2024-03-28 11:25, Jan Beulich wrote:
On 11.07.2023 18:40, Roberto Bagnara wrote:
Mandatory Rule 19.1 (An object shall not be assigned or copied to an
overlapping object) is directly targeted at two undefined behaviors,
one of which is the subject of 6.5.16.1p3, namely:
If the value being
All,
we're pleased to announce the release of two bug fixing Xen versions.
Xen 4.18.1 has been available for a little while from its git repository
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.18
(tag RELEASE-4.18.1) or from the XenProject download page
On 04.04.2024 12:41, Andrew Cooper wrote:
> @@ -9,6 +10,7 @@
> * -1 => Default, altered to 0/1 (if unspecified) by:
> * - TAA heuristics/settings for speculative safety
> * - "TSX vs PCR3" select for TSX memory ordering safety
> + * -2 => Implicit tsx=0
"watchdog_timeout=0" is documented to disable the watchdog, which wasn't
really the case; the watchdog was rather ran with an, in practice,
infinite timeout. Fold that command line option with "watchdog",
resetting to defaults whenever encountering a new instance.
While touching
Separate Intel nonfatal MCE initialization code from generic MCE code, the same
way it is done for AMD code. This is to be able to later make intel/amd MCE
code optional in the build.
Also clean up unused includes.
No functional change intended.
Signed-off-by: Sergiy Kibrik
---
On 04/04/2024 13:22, Juergen Gross wrote:
> On 27.03.24 16:22, 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.
>>
>>
On 27.03.24 16:22, 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
Could
Hi Luca,
On 04/04/2024 11:33, Luca Fancellu wrote:
>
>
>> On 22 Mar 2024, at 10:30, Michal Orzel wrote:
>>
>> Hi Luca,
>>
>> On 12/03/2024 14:03, Luca Fancellu wrote:
>>>
>>>
>>> Currently the memory footprint of the static shared memory feature
>>> is impacting all the struct meminfo
flight 185232 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185232/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 6 kernel-build fail REGR. vs. 185228
Tests which did
On Thu, Apr 04, 2024 at 11:41:22AM +0100, Andrew Cooper wrote:
> It turns out there is something wonky on some but not all CPUs with
> MSR_TSX_FORCE_ABORT. The presence of RTM_ALWAYS_ABORT causes Xen to think
> it's safe to offer HLE/RTM to guests, but in this case, XBEGIN instructions
>
It turns out there is something wonky on some but not all CPUs with
MSR_TSX_FORCE_ABORT. The presence of RTM_ALWAYS_ABORT causes Xen to think
it's safe to offer HLE/RTM to guests, but in this case, XBEGIN instructions
genuinely #UD.
Spot this case and try to back out as cleanly as we can.
On 20.03.2024 09:59, Jan Beulich wrote:
> On 19.03.2024 21:35, Andrew Cooper wrote:
>> On 25/01/2024 2:12 pm, Jan Beulich wrote:
>>> "watchdog_timeout=0" is documented to disable the watchdog. Make sure
>>> this also is true when there's a subsequent "watchdog" command line
>>> option (and no
On 27.03.2024 22:50, Jason Andryuk wrote:
> @@ -36,6 +35,11 @@ static xc_evtchn_port_or_error_t console_evtchn;
> static xentoollog_level minmsglevel = XTL_PROGRESS;
> static void *logger;
>
> +static inline uint64_t mb_to_bytes(int mem)
> +{
> + return (uint64_t)mem << 20;
> +}
While
On 03.04.2024 12:19, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/arch.mk
> +++ b/xen/arch/riscv/arch.mk
> @@ -3,16 +3,27 @@
>
> $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
>
> -CFLAGS-$(CONFIG_RISCV_64) += -mabi=lp64
> +riscv-abi-$(CONFIG_RISCV_32) := -mabi=ilp32
>
On Thu, Apr 4, 2024 at 8:49 AM Federico Serafini
wrote:
>
> Add break statement to address a violation of MISRA C:2012 Rule 16.3
> ("An unconditional `break' statement shall terminate every
> switch-clause").
> Replace deprecated comment /* FALLTHRU */ with pseudo-keyword
> fallthrough to meet
On 03.04.2024 10:16, Henry Wang wrote:
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -219,7 +219,8 @@ static void populate_physmap(struct memop_args *a)
> }
> else
> {
> -if ( is_domain_direct_mapped(d) )
> +if (
> On 22 Mar 2024, at 10:30, Michal Orzel wrote:
>
> Hi Luca,
>
> On 12/03/2024 14:03, Luca Fancellu wrote:
>>
>>
>> Currently the memory footprint of the static shared memory feature
>> is impacting all the struct meminfo instances with memory space
>> that is not going to be used.
>>
>>
Hi Luca,
On 04/04/2024 11:27, Luca Fancellu wrote:
>
>
>> On 19 Mar 2024, at 14:58, Michal Orzel wrote:
>>
>> Hi Luca,
>>
>> On 12/03/2024 14:03, Luca Fancellu wrote:
>>>
>>>
>>> The user of shm_mem member of the 'struct kernel_info' is only
>>> the code managing the static shared memory
On 03.04.2024 10:16, Henry Wang wrote:
> --- a/tools/libs/ctrl/xc_domain.c
> +++ b/tools/libs/ctrl/xc_domain.c
> @@ -697,6 +697,39 @@ int xc_domain_setmaxmem(xc_interface *xch,
> return do_domctl(xch, );
> }
>
> +int xc_get_domain_mem_map(xc_interface *xch, uint32_t domid,
> +
> On 19 Mar 2024, at 14:58, Michal Orzel wrote:
>
> Hi Luca,
>
> On 12/03/2024 14:03, Luca Fancellu wrote:
>>
>>
>> The user of shm_mem member of the 'struct kernel_info' is only
>> the code managing the static shared memory feature, which can be
>> compiled out using CONFIG_STATIC_SHM, so
On 04.04.2024 03:12, Stefano Stabellini wrote:
> --- a/docs/misra/C-language-toolchain.rst
> +++ b/docs/misra/C-language-toolchain.rst
> @@ -480,4 +480,73 @@ The table columns are as follows:
> - See Section "4.13 Preprocessing Directives" of GCC_MANUAL and Section
> "11.1
Hi Stefano,
> On 4 Apr 2024, at 03:12, Stefano Stabellini wrote:
>
> Xen makes assumptions about the size of integer types on the various
> architectures. Document these assumptions.
>
> Signed-off-by: Stefano Stabellini
> ---
> Changes in v3:
> - add links to System V, AAPCS32 and AAPCS64
>
Hi Jan,
On 04/04/2024 10:06, Jan Beulich wrote:
>
>
> On 04.04.2024 09:51, Michal Orzel wrote:
>> On Arm we don't use console_{suspend,resume} and the corresponding
>> stubs in serial drivers are being redundantly copied whenever a new
>> driver is added. Drop them as well as useless .endboot =
On 03.04.2024 15:31, Daniel P. Smith wrote:
> On 4/3/24 07:54, Jan Beulich wrote:
>> On 03.04.2024 13:50, Daniel P. Smith wrote:
>>> On 4/3/24 02:52, Jan Beulich wrote:
On 03.04.2024 08:16, Jan Beulich wrote:
> On 02.04.2024 19:06, Andrew Cooper wrote:
>> Whether to return information
On 04.04.2024 09:51, Michal Orzel wrote:
> On Arm we don't use console_{suspend,resume} and the corresponding
> stubs in serial drivers are being redundantly copied whenever a new
> driver is added. Drop them as well as useless .endboot = NULL assignment.
>
> Signed-off-by: Michal Orzel
Since
On 04.04.2024 09:49, Federico Serafini wrote:
> MISRA C:2012 Rule 16.3 states: "An unconditional `break' statement
> shall terminate every switch-clause".
>
> In order to meet the requirements to deviate the rule:
> 1) refactor the for loop to make the switch-clause ending with a
>return
On 04.04.2024 09:49, Federico Serafini wrote:
> Add break statement to address a violation of MISRA C:2012 Rule 16.3
> ("An unconditional `break' statement shall terminate every
> switch-clause").
> Replace deprecated comment /* FALLTHRU */ with pseudo-keyword
> fallthrough to meet the
On 03.04.2024 15:27, Daniel P. Smith wrote:
> On 4/3/24 08:05, Jan Beulich wrote:
>> On 03.04.2024 13:10, Daniel P. Smith wrote:
>>> On 4/3/24 02:16, Jan Beulich wrote:
On 02.04.2024 19:06, Andrew Cooper wrote:
> The commit makes a claim without any kind of justification.
Well,
These variables are useless. They are being assigned a value which is
never used since UART is expected to be pre-configured.
No functional change.
Signed-off-by: Michal Orzel
---
xen/drivers/char/imx-lpuart.c | 6 --
1 file changed, 6 deletions(-)
diff --git
Simple serial drivers cleanup. No functional change intended.
Michal Orzel (2):
drivers: char: Drop useless suspend/resume stubs in Arm drivers
char: lpuart: Drop useless variables from UART structure
xen/drivers/char/cadence-uart.c| 13 -
xen/drivers/char/exynos4210-uart.c
On Arm we don't use console_{suspend,resume} and the corresponding
stubs in serial drivers are being redundantly copied whenever a new
driver is added. Drop them as well as useless .endboot = NULL assignment.
Signed-off-by: Michal Orzel
---
xen/drivers/char/cadence-uart.c| 13 -
Add break statement to address a violation of MISRA C:2012 Rule 16.3
("An unconditional `break' statement shall terminate every
switch-clause").
Replace deprecated comment /* FALLTHRU */ with pseudo-keyword
fallthrough to meet the requirements to deviate the rule.
No functional change.
MISRA C:2012 Rule 16.3 states: "An unconditional `break' statement
shall terminate every switch-clause".
In order to meet the requirements to deviate the rule:
1) refactor the for loop to make the switch-clause ending with a
return statement (note that adding a break at the end of the
Address violations of MISRA C:2012 Rule 16.3 by adding fallthrough, break and
return at the end of the switch-clauses.
Federico Serafini (2):
xen/sched: address violations of MISRA C:2012 Rule 16.3
vsprintf: address violations of MISRA C:2012 Rule 16.3
xen/common/sched/core.c| 1 +
Hi Oleksandr,
On 02/04/2024 14:05, Oleksandr Tyshchenko wrote:
>
>
> From: Oleksandr Tyshchenko
>
> The i.MX UART Documentation:
> https://www.nxp.com/webapp/Download?colCode=IMX8MMRM
> Chapter 16.2 Universal Asynchronous Receiver/Transmitter (UART)
>
> Tested on i.MX 8M Mini only, but I
Hi,
On 02/04/2024 12:25, Michal Orzel wrote:
>
>
> Hello,
>
> On 29/03/2024 01:08, Volodymyr Babchuk wrote:
>>
>>
>> Generic Interface (GENI) is a newer interface for low speed interfaces
>> like UART, I2C or SPI. This patch adds the simple driver for the UART
>> instance of GENI. Code is
On 03.04.2024 18:41, Marek Marczykowski-Górecki wrote:
> On Wed, Apr 03, 2024 at 05:04:20PM +0200, Jan Beulich wrote:
>> On 03.04.2024 16:50, Marek Marczykowski-Górecki wrote:
>>> Hi,
>>>
>>> I've noticed that tools/tests/tsx/test-tsx fails on a system with Intel
>>> Core i7-8750H. Specific error
89 matches
Mail list logo
