On 31.10.2023 17:22, Matias Ezequiel Vara Larsen wrote:
> This commit prevents PGT_none type pages to be validated/devalidated.
This isn't quite true. It is rather the case that (de)validation of this
type is trivial, and hence can be short-circuited just like is done for
certain other types.
> T
flight 185763 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185763/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 185750
Tests which did not
The ! clearly got lost by mistake.
Fixes: e9e0eb30d4d6 ("x86/MTRR: avoid several indirect calls")
Reported-by: Marek Marczykowski-Górecki
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/mtrr/main.c
+++ b/xen/arch/x86/cpu/mtrr/main.c
@@ -316,7 +316,7 @@ int mtrr_add_page(unsigned long base, un
On 23.04.2024 03:17, Marek Marczykowski-Górecki wrote:
> On Wed, Jan 17, 2024 at 10:32:53AM +0100, Jan Beulich wrote:
>> --- a/xen/arch/x86/cpu/mtrr/main.c
>> +++ b/xen/arch/x86/cpu/mtrr/main.c
>> @@ -328,7 +316,7 @@ int mtrr_add_page(unsigned long base, un
>> }
>>
>> /* If the type is
On 22.04.2024 18:38, Ross Lagerwall wrote:
> On Thu, Apr 18, 2024 at 2:24 PM Jan Beulich wrote:
>> On 08.04.2024 18:26, Ross Lagerwall wrote:
>>> --- a/xen/arch/x86/hvm/rtc.c
>>> +++ b/xen/arch/x86/hvm/rtc.c
>>> @@ -202,6 +202,7 @@ static void check_update_timer(RTCState *s)
>>> }
>>>
On Tue, Apr 23, 2024 at 09:51:46AM +0200, Jan Beulich wrote:
> The ! clearly got lost by mistake.
>
> Fixes: e9e0eb30d4d6 ("x86/MTRR: avoid several indirect calls")
> Reported-by: Marek Marczykowski-Górecki
> Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
Thanks, Roger.
The current static shared memory code is using bootinfo banks when it
needs to find the number of borrower, so every time assign_shared_memory
is called, the bank is searched in the bootinfo.shmem structure.
There is nothing wrong with it, however the bank can be used also to
retrieve the start ad
This serie is a partial rework of this other serie:
https://patchwork.kernel.org/project/xen-devel/cover/20231206090623.1932275-1-penny.zh...@arm.com/
The original serie is addressing an issue of the static shared memory feature
that impacts the memory footprint of other component when the feature
This commit implements the logic to have the static shared memory banks
from the Xen heap instead of having the host physical address passed from
the user.
When the host physical address is not supplied, the physical memory is
taken from the Xen heap using allocate_domheap_memory, the allocation
n
Handle the parsing of the 'xen,shared-mem' property when the host physical
address is not provided, this commit is introducing the logic to parse it,
but the functionality is still not implemented and will be part of future
commits.
Rework the logic inside process_shm_node to check the shm_id befo
From: Penny Zheng
This commit describe the new scenario where host address is not provided
in "xen,shared-mem" property and a new example is added to the page to
explain in details.
Take the occasion to fix some typos in the page.
Signed-off-by: Penny Zheng
Signed-off-by: Luca Fancellu
---
v1
Wrap the code and logic that is calling assign_shared_memory
and map_regions_p2mt into a new function 'handle_shared_mem_bank',
it will become useful later when the code will allow the user to
don't pass the host physical address.
Signed-off-by: Luca Fancellu
---
xen/arch/arm/static-shmem.c | 71
From: Penny Zheng
We are doing foreign memory mapping for static shared memory, and
there is a great possibility that it could be super mapped.
But today, p2m_put_l3_page could not handle superpages.
This commits implements a new function p2m_put_superpage to handle superpages,
specifically for
The function allocate_bank_memory allocates pages from the heap and
map them to the guest using guest_physmap_add_page.
As a preparation work to support static shared memory bank when the
host physical address is not provided, Xen needs to allocate memory
from the heap, so rework allocate_bank_mem
Here's an attempt to further separate support of Intel & AMD CPUs in Xen build.
The code to drive both platforms used to be built unconditionally, until recent
introduction of CONFIG_{AMD,INTEL} Kconfig options.
This series extends coverage of these options on vpmu and mcheck subsystems,
that is n
Build AMD vPMU when CONFIG_AMD is on, and Intel vPMU when CONFIG_INTEL
is on respectively, allowing for a plaftorm-specific build. Also separate
arch_vpmu_ops initializers using these options and static inline stubs.
No functional change intended.
Signed-off-by: Sergiy Kibrik
CC: Andrew Cooper
Since MCG_LMCE_P bit is specific to Intel CPUs the code to check it can
possibly be excluded from build if !CONFIG_INTEL. With these guards
calls to vmce_has_lmce() are eliminated and mce_intel.c can end up
not being built.
Also replace boilerplate code that checks for MCG_LMCE_P flag with
vmce_ha
Add build-time checks for newly introduced INTEL/AMD config options when
calling vmce_{intel/amd}_{rdmsr/wrmsr}() routines.
This way a platform-specific code can be omitted in vmce code, if this
platform is disabled in config.
Signed-off-by: Sergiy Kibrik
---
xen/arch/x86/cpu/mcheck/vmce.c | 12
Guard access to Intel-specific lmce_support & cmci_support variables in
common MCE/VMCE code. These are set in Intel-specific parts of mcheck code
and can potentially be skipped if building for non-intel platform by
disabling CONFIG_INTEL option.
Signed-off-by: Sergiy Kibrik
---
xen/arch/x86/cpu
Guard calls to CPU-specific mcheck init routines in common MCE code
using new INTEL/AMD config options.
The purpose is not to build platform-specific mcheck code and calls to it,
if this platform is disabled in config.
Signed-off-by: Sergiy Kibrik
---
xen/arch/x86/cpu/mcheck/mce.c | 6 --
1
Add check for CONFIG_INTEL build option to conditional call of this routine,
so that if Intel support is disabled the call would be eliminated.
No functional change intended.
Signed-off-by: Sergiy Kibrik
---
xen/arch/x86/cpu/mcheck/mce.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Separate Intel/AMD-specific MCE code using CONFIG_{INTEL,AMD} config options.
Now we can avoid build of mcheck code if support for specific platform is
intentionally disabled by configuration.
Signed-off-by: Sergiy Kibrik
---
xen/arch/x86/cpu/mcheck/Makefile| 6 ++
xen/arch/x86/cpu/mchec
On 22.04.2024 20:14, Andrew Cooper wrote:
> In order to relocate all IP-relative fields in an alternative replacement
> block, we need to decode the instructions enough to obtain their length and
> any relative fields.
>
> Full x86_decode() is far too heavyweight, so introduce a minimal form which
Hi Julien,
On Mon, Apr 22, 2024 at 12:57 PM Julien Grall wrote:
>
> Hi Jens,
>
> On 22/04/2024 08:37, Jens Wiklander wrote:
> > Updates so request_irq() can be used with a dynamically assigned SGI irq
> > as input. This prepares for a later patch where an FF-A schedule
> > receiver interrupt hand
Update ECLAIR configuration to take into account the deviations
agreed during MISRA meetings for Rule 16.4.
Signed-off-by: Federico Serafini
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 8
docs/misra/deviations.rst| 13 +
2 files changed, 2
On 23.04.2024 12:02, Federico Serafini wrote:
> --- a/docs/misra/deviations.rst
> +++ b/docs/misra/deviations.rst
> @@ -302,6 +302,19 @@ Deviations related to MISRA C:2012 Rules:
> leave such files as is.
> - Tagged as `deliberate` for ECLAIR.
>
> + * - R16.4
> + - Switch stat
On 23/04/2024 10:17 am, Jan Beulich wrote:
> On 22.04.2024 20:14, Andrew Cooper wrote:
>> --- /dev/null
>> +++ b/xen/arch/x86/x86_emulate/decode-lite.c
>> @@ -0,0 +1,245 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +
>> +#include "private.h"
>> +
>> +#define Imm8 (1 << 0)
>> +#define Imm
On 23.04.2024 12:27, Andrew Cooper wrote:
> On 23/04/2024 10:17 am, Jan Beulich wrote:
>> On 22.04.2024 20:14, Andrew Cooper wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/x86/x86_emulate/decode-lite.c
>>> @@ -0,0 +1,245 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>> +
>>> +#include "private.
On 23/04/2024 10:35, Jens Wiklander wrote:
Hi Julien,
Hi Jens,
On Mon, Apr 22, 2024 at 12:57 PM Julien Grall wrote:
Hi Jens,
On 22/04/2024 08:37, Jens Wiklander wrote:
Updates so request_irq() can be used with a dynamically assigned SGI irq
as input. This prepares for a later patch wh
The PVH entry is available for 32-bit KVM guests, and 32-bit KVM guests
do not depend on CONFIG_X86_PAE. However, mk_early_pgtbl_32() builds
different pagetables depending on whether CONFIG_X86_PAE is set.
Therefore, enabling PAE mode for 32-bit KVM guests without
CONFIG_X86_PAE being set would res
On 19.04.2024 12:02, Roger Pau Monne wrote:
> Start by declaring the beginning and end of the init section.
>
> No functional change intended.
>
> Requested-by: Andrew Cooper
> Signed-off-by: Roger Pau Monné
> ---
> xen/arch/arm/mmu/setup.c | 3 +--
> xen/arch/x86/setup.c | 3 +--
>
Hi Julien,
> On 23 Apr 2024, at 13:05, Julien Grall wrote:
>
>
>
> On 23/04/2024 10:35, Jens Wiklander wrote:
>> Hi Julien,
>
> Hi Jens,
>
>> On Mon, Apr 22, 2024 at 12:57 PM Julien Grall wrote:
>>>
>>> Hi Jens,
>>>
>>> On 22/04/2024 08:37, Jens Wiklander wrote:
Updates so request_ir
flight 185765 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185765/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken in 185433
build-arm64-xsm
Hello,
This RFC patch introduce a design proposal for changes in the IOMMU subsystem
to allow existence of "IOMMU contexts" (aka hardware IOMMU domains) within
a single Xen domain.
In addition to this, redesign and simplify the existing Xen IOMMU subsystem
with these new uses in mind, using IOMMU
Hello,
I am introducing a proposal for a PV-IOMMU hypercall interface.
Some operating systems want to use IOMMU to implement various features (e.g
VFIO) or DMA protection. This proposal aims to provide to guests (notably Dom0)
a way to access a paravirtualized one.
This proposal is based on what
Hello,
Following series contain some minor bugfixes and improvements for
livepatch logic, both inside the hypervisor and on the command line
tool.
Thanks, Roger.
Roger Pau Monne (4):
xen-livepatch: fix parameter name parsing
livepatch: introduce --force option
livepatch: refuse to resolve
Ensure the entries of a payload exception table only apply to text regions in
the payload itself. Since the payload exception table needs to be loaded and
active even before a patch is applied (because hooks might already rely on it),
make sure the exception table (if any) only contains fixups for
Introduce a xen-livepatch tool --force option, that's propagated into the
hyerpvisor for livepatch operations. The intention is for the option to be
used to bypass some checks that would otherwise prevent the patch from being
loaded.
Re purpose the pad field in xen_sysctl_livepatch_op to be a fla
It's incorrect to restrict strncmp to the length of the command line input
parameter, as then a user passing a rune like:
% xen-livepatch up foo.livepatch
Would match against the "upload" command, because the string comparison has
been truncated to the length of the input argument. Instead the t
Livepatch payloads containing symbols that belong to init sections can only
lead to page faults later on, as by the time the livepatch is loaded init
sections have already been freed.
Refuse to resolve such symbols and return an error instead.
Note such resolutions are only relevant for symbols t
On Tue, Apr 23, 2024 at 02:25:16PM +0200, Jan Beulich wrote:
> On 19.04.2024 12:02, Roger Pau Monne wrote:
> Then I wonder why it was this rather than ...
>
> > --- a/xen/arch/x86/setup.c
> > +++ b/xen/arch/x86/setup.c
> > @@ -5,6 +5,7 @@
> > #include
> > #include
> > #include
> > +#include
Hi Julien,
> On 23 Apr 2024, at 14:37, Bertrand Marquis wrote:
>
> Hi Julien,
>
>> On 23 Apr 2024, at 13:05, Julien Grall wrote:
>>
>>
>>
>> On 23/04/2024 10:35, Jens Wiklander wrote:
>>> Hi Julien,
>>
>> Hi Jens,
>>
>>> On Mon, Apr 22, 2024 at 12:57 PM Julien Grall wrote:
Hi
On 23.04.2024 15:12, Roger Pau Monne wrote:
> It's incorrect to restrict strncmp to the length of the command line input
> parameter, as then a user passing a rune like:
>
> % xen-livepatch up foo.livepatch
>
> Would match against the "upload" command, because the string comparison has
> been tru
On 23.04.2024 15:12, Roger Pau Monne wrote:
> --- a/xen/common/livepatch.c
> +++ b/xen/common/livepatch.c
> @@ -2125,7 +2125,8 @@ int livepatch_op(struct xen_sysctl_livepatch_op
> *livepatch)
> {
> int rc;
>
> -if ( livepatch->pad )
> +if ( livepatch->flags & ~LIVEPATCH_FLAGS_MASK
On 23.04.2024 15:12, Roger Pau Monne wrote:
> Livepatch payloads containing symbols that belong to init sections can only
> lead to page faults later on, as by the time the livepatch is loaded init
> sections have already been freed.
>
> Refuse to resolve such symbols and return an error instead.
On 23.04.2024 15:12, Roger Pau Monne wrote:
> Ensure the entries of a payload exception table only apply to text regions in
> the payload itself. Since the payload exception table needs to be loaded and
> active even before a patch is applied (because hooks might already rely on
> it),
> make sur
On Tue, Apr 23, 2024 at 03:33:36PM +0200, Jan Beulich wrote:
> On 23.04.2024 15:12, Roger Pau Monne wrote:
> > It's incorrect to restrict strncmp to the length of the command line input
> > parameter, as then a user passing a rune like:
> >
> > % xen-livepatch up foo.livepatch
> >
> > Would match
On Tue, Apr 23, 2024 at 03:44:42PM +0200, Jan Beulich wrote:
> On 23.04.2024 15:12, Roger Pau Monne wrote:
> > Livepatch payloads containing symbols that belong to init sections can only
> > lead to page faults later on, as by the time the livepatch is loaded init
> > sections have already been fre
Hi Bertrand,
On 23/04/2024 14:23, Bertrand Marquis wrote:
Hi Julien,
On 23 Apr 2024, at 14:37, Bertrand Marquis wrote:
Hi Julien,
On 23 Apr 2024, at 13:05, Julien Grall wrote:
On 23/04/2024 10:35, Jens Wiklander wrote:
Hi Julien,
Hi Jens,
On Mon, Apr 22, 2024 at 12:57 PM Julien Gr
On 23.04.2024 16:26, Roger Pau Monné wrote:
> On Tue, Apr 23, 2024 at 03:44:42PM +0200, Jan Beulich wrote:
>> On 23.04.2024 15:12, Roger Pau Monne wrote:
>>> Livepatch payloads containing symbols that belong to init sections can only
>>> lead to page faults later on, as by the time the livepatch is
1: P2M: write_p2m_entry() is HVM-only anyway
2: P2M: un-indent write_p2m_entry()
3: paging: vCPU host mode is always set
4: shadow: correct shadow_vcpu_init()'s comment
Jan
On Tue, Apr 23, 2024 at 03:51:31PM +0200, Jan Beulich wrote:
> On 23.04.2024 15:12, Roger Pau Monne wrote:
> > Ensure the entries of a payload exception table only apply to text regions
> > in
> > the payload itself. Since the payload exception table needs to be loaded
> > and
> > active even be
The latest as of e2b2ff677958 ("x86/P2M: split out init/teardown
functions") the function is obviously unreachable for PV guests. Hence
the paging_mode_enabled(d) check is pointless.
Further host mode of a vCPU is always set, by virtue of
paging_vcpu_init() being part of vCPU creation. Hence the
p
Drop the inner scope that was left from earlier if/else removal. Take
the opportunity and make the paging_unlock() invocation common to
success and error paths, though.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -110,49 +110,43 @@ static int write
... thanks to paging_vcpu_init() being part of vCPU creation. Further
if paging is enabled on a domain, it's also guaranteed to be either HAP
or shadow. Drop respective unnecessary (parts of) conditionals.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@
As of the commit referenced below the update_paging_modes() hook is per-
domain and hence also set (already) during domain construction.
Fixes: d0816a9085b5 ("x86/paging: move update_paging_modes() hook")
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shad
On 23.04.2024 16:31, Roger Pau Monné wrote:
> On Tue, Apr 23, 2024 at 03:51:31PM +0200, Jan Beulich wrote:
>> On 23.04.2024 15:12, Roger Pau Monne wrote:
>>> Ensure the entries of a payload exception table only apply to text regions
>>> in
>>> the payload itself. Since the payload exception table
On Mon, Apr 22, 2024 at 3:18 PM Jan Beulich wrote:
>
> On 16.04.2024 11:15, Fouad Hilly wrote:
> > Refactor microcode_update() hypercall by adding flags field.
> > Introduce XENPF_microcode_update2 hypercall to handle flags field.
> > struct xenpf_microcode_update updated to have uint32_t flags at
On 22.04.2024 20:14, Andrew Cooper wrote:
> In debug builds, walk all alternative replacements with x86_decode_lite().
>
> This checks that we can decode all instructions, and also lets us check that
> disp8's don't leave the replacement block.
>
> Signed-off-by: Andrew Cooper
With pointed-to t
Pavel Begunkov wrote:
> At the moment an skb can only have one ubuf_info associated with it,
> which might be a performance problem for zerocopy sends in cases like
> TCP via io_uring. Add a callback for assigning ubuf_info to skb, this
> way we will implement smarter assignment later like linking
Pavel Begunkov wrote:
> We'll need to associate additional callbacks with ubuf_info, introduce
> a structure holding ubuf_info callbacks. Apart from a more smarter
> io_uring notification management introduced in next patches, it can be
> used to generalise msg_zerocopy_put_abort() and also store
>
Hi,
On Tue, Apr 23, 2024 at 4:28 PM Julien Grall wrote:
>
> Hi Bertrand,
>
> On 23/04/2024 14:23, Bertrand Marquis wrote:
> > Hi Julien,
> >
> >> On 23 Apr 2024, at 14:37, Bertrand Marquis
> >> wrote:
> >>
> >> Hi Julien,
> >>
> >>> On 23 Apr 2024, at 13:05, Julien Grall wrote:
> >>>
> >>>
> >
On Mon, Apr 8, 2024 at 10:16 AM Jan Beulich wrote:
>
> On 05.04.2024 14:11, Fouad Hilly wrote:
> > @@ -708,11 +712,13 @@ static long cf_check microcode_update_helper(void
> > *data)
> > return ret;
> > }
> >
> > -int microcode_update(XEN_GUEST_HANDLE(const_void) buf, unsigned long len)
> >
On Tue, Apr 23, 2024 at 1:05 PM Julien Grall wrote:
>
>
>
> On 23/04/2024 10:35, Jens Wiklander wrote:
> > Hi Julien,
>
> Hi Jens,
>
> > On Mon, Apr 22, 2024 at 12:57 PM Julien Grall wrote:
> >>
> >> Hi Jens,
> >>
> >> On 22/04/2024 08:37, Jens Wiklander wrote:
> >>> Updates so request_irq() can
On 22.04.2024 20:14, Andrew Cooper wrote:
> --- a/xen/arch/x86/alternative.c
> +++ b/xen/arch/x86/alternative.c
> @@ -244,10 +244,31 @@ static void init_or_livepatch
> _apply_alternatives(struct alt_instr *start,
>
> memcpy(buf, repl, a->repl_len);
>
> +/* Walk buf[] and adjus
On Mon, Apr 22, 2024 at 3:09 PM Jan Beulich wrote:
>
> On 16.04.2024 11:15, Fouad Hilly wrote:
> > Update microcode version check at Intel and AMD Level by:
> > Preventing the low level code from sending errors if the microcode
> > version provided is not a newer version.
>
> And why is this chang
On Thu, Apr 18, 2024 at 11:05 AM Andrew Cooper
wrote:
>
> On 16/04/2024 10:15 am, Fouad Hilly wrote:
> > Update microcode version check at Intel and AMD Level by:
> > Preventing the low level code from sending errors if the microcode
> > version provided is not a newer version. Other errors will b
On 22.04.2024 20:14, Andrew Cooper wrote:
> ... to make subsequent patches legible.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
even if (perhaps due to changes in the "real" patch) some of this re-
indenting wants doing differently, just with ...
> --- a/x
On 22.04.2024 20:14, Andrew Cooper wrote:
> A subsequent patch is going to insert a loop, which interferes with the
> continue in the devirtualisation logic.
>
> Replace it with a goto, and a paragraph explaining why we intentionally avoid
> setting a->priv = 1.
>
> No functional change.
>
> Sig
On Tue, Apr 23, 2024 at 04:28:59PM +0200, Jan Beulich wrote:
> On 23.04.2024 16:26, Roger Pau Monné wrote:
> > On Tue, Apr 23, 2024 at 03:44:42PM +0200, Jan Beulich wrote:
> >> On 23.04.2024 15:12, Roger Pau Monne wrote:
> >>> Livepatch payloads containing symbols that belong to init sections can
Hi Julien,
> On 22 Apr 2024, at 13:40, Julien Grall wrote:
>
> Hi Jens,
>
> This is not a full review of the code. I will let Bertrand doing it.
>
> On 22/04/2024 08:37, Jens Wiklander wrote:
>> +void ffa_notif_init(void)
>> +{
>> +const struct arm_smccc_1_2_regs arg = {
>> +.a0 =
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 alter
The count_args_ macro violates Rule 20.7, but it can't be made
compliant with Rule 20.7 without breaking its functionality. Since
it's very unlikely for this macro to be misused, it is deviated.
No functional change.
Signed-off-by: Nicola Vetrini
---
automation/eclair_analysis/ECLAIR/deviations
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 to
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 alter
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 alter
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 alter
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 alter
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 alter
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 alter
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 alter
From: Simone Ballarin
Introduce accepted_guidelines.sh: a script to autogenerate the
configuration file accepted.ecl from docs/misra/rules.rst which enables
all accepted guidelines.
Introduce monitored.ecl: a manual selection of accepted guidelines
which are clean or almost clean, it is intended
Hi Bertrand,
On 23/04/2024 16:12, Bertrand Marquis wrote:
Hi Julien,
On 22 Apr 2024, at 13:40, Julien Grall wrote:
Hi Jens,
This is not a full review of the code. I will let Bertrand doing it.
On 22/04/2024 08:37, Jens Wiklander wrote:
+void ffa_notif_init(void)
+{
+const struct arm_s
On Mon, Apr 22, 2024 at 6:48 PM Anthony PERARD wrote:
>
> On Tue, Apr 16, 2024 at 10:15:45AM +0100, Fouad Hilly wrote:
> > diff --git a/tools/misc/xen-ucode.c b/tools/misc/xen-ucode.c
> > index 0c0b2337b4ea..e3c1943e3633 100644
> > --- a/tools/misc/xen-ucode.c
> > +++ b/tools/misc/xen-ucode.c
> >
Hi Julien,
> On 23 Apr 2024, at 17:16, Julien Grall wrote:
>
> Hi Bertrand,
>
> On 23/04/2024 16:12, Bertrand Marquis wrote:
>> Hi Julien,
>>> On 22 Apr 2024, at 13:40, Julien Grall wrote:
>>>
>>> Hi Jens,
>>>
>>> This is not a full review of the code. I will let Bertrand doing it.
>>>
>>>
On Mon, Apr 22, 2024 at 6:57 PM Anthony PERARD wrote:
>
> On Tue, Apr 16, 2024 at 10:15:46AM +0100, Fouad Hilly wrote:
> > Introduce --force option to xen-ucode to force skipping microcode version
> > check, which allows the user to update x86 microcode even if both versions
> > are the same.
> >
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 alter
Hi Julien,
On Mon, Apr 22, 2024 at 1:40 PM Julien Grall wrote:
>
> Hi Jens,
>
> This is not a full review of the code. I will let Bertrand doing it.
>
> On 22/04/2024 08:37, Jens Wiklander wrote:
> > +void ffa_notif_init(void)
> > +{
> > +const struct arm_smccc_1_2_regs arg = {
> > +.
On 23/04/24 12:26, Jan Beulich wrote:
On 23.04.2024 12:02, Federico Serafini wrote:
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -302,6 +302,19 @@ Deviations related to MISRA C:2012 Rules:
leave such files as is.
- Tagged as `deliberate` for ECLAIR.
+ *
On Tue, Apr 23, 2024 at 03:12:47PM +0200, Roger Pau Monne wrote:
> Introduce a xen-livepatch tool --force option, that's propagated into the
> hyerpvisor for livepatch operations. The intention is for the option to be
> used to bypass some checks that would otherwise prevent the patch from being
>
On 23.04.2024 17:52, Federico Serafini wrote:
> On 23/04/24 12:26, Jan Beulich wrote:
>> On 23.04.2024 12:02, Federico Serafini wrote:
>>> --- a/docs/misra/deviations.rst
>>> +++ b/docs/misra/deviations.rst
>>> @@ -302,6 +302,19 @@ Deviations related to MISRA C:2012 Rules:
>>> leave such f
On 23.04.2024 17:03, Roger Pau Monné wrote:
> On Tue, Apr 23, 2024 at 04:28:59PM +0200, Jan Beulich wrote:
>> On 23.04.2024 16:26, Roger Pau Monné wrote:
>>> On Tue, Apr 23, 2024 at 03:44:42PM +0200, Jan Beulich wrote:
On 23.04.2024 15:12, Roger Pau Monne wrote:
> Livepatch payloads contai
On 23.04.2024 16:53, Fouad Hilly wrote:
> On Mon, Apr 8, 2024 at 10:16 AM Jan Beulich wrote:
>> On 05.04.2024 14:11, Fouad Hilly wrote:
>>> @@ -708,11 +712,13 @@ static long cf_check microcode_update_helper(void
>>> *data)
>>> return ret;
>>> }
>>>
>>> -int microcode_update(XEN_GUEST_HANDLE
To save some bandwith that can be later on used to increase the test
coverage by adding new tests, drop the following non-debug test/build
jobs existing in both debug and non-debug variants:
- static memory (arm64, arm32)
- static shared memory (arm64)
- static heap (arm64)
- boot cpupools (arm
This came up as part of the following discussion:
https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2402291108290.853156@ubuntu-linux-20-04-desktop/
Michal Orzel (3):
automation: Drop some of the non-debug variants of the same Arm jobs
automation: Add arm{64,32} earlyprintk jobs
automati
Introduce qemu based Arm earlyprintk test and build jobs to cover this
feature in debug variant. The tests simply check for the presence of the
last message printed by the bootstrap code before entering the C world.
Signed-off-by: Michal Orzel
---
automation/gitlab-ci/build.yaml
At the moment, all the Arm64 Qemu tests use GICv2 which is the default
GIC version used by Qemu. Improve the coverage by adding a new test in
which Qemu will be configured to have GICv3.
Rename host device tree name to "virt.dtb" to be GIC version agnostic.
Use "gic-version" Qemu option to select
On Tue, Apr 23, 2024 at 04:16:10PM +0100, Fouad Hilly wrote:
> On Mon, Apr 22, 2024 at 6:48 PM Anthony PERARD
> wrote:
> > On Tue, Apr 16, 2024 at 10:15:45AM +0100, Fouad Hilly wrote:
> > > +if ( argc != 2 )
> > > +goto ext_err;
> >
> > Why only two arguments allowed? And why check `a
On Tue, Apr 23, 2024 at 04:26:53PM +0100, Fouad Hilly wrote:
> On Mon, Apr 22, 2024 at 6:57 PM Anthony PERARD
> wrote:
> > On Tue, Apr 16, 2024 at 10:15:46AM +0100, Fouad Hilly wrote:
> > > diff --git a/tools/misc/xen-ucode.c b/tools/misc/xen-ucode.c
> > > index e3c1943e3633..4178fd2221ea 100644
flight 185767 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185767/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-pvshim 13 debian-fixup fail in 185762 pass in 185767
test-armhf-armhf-xl-rtds 8
1 - 100 of 137 matches
Mail list logo
