On 18.03.2024 14:24, Andrew Cooper wrote:
> On 18/03/2024 1:17 pm, Jan Beulich wrote:
>> On 18.03.2024 12:04, Andrew Cooper wrote:
>>> --- a/xen/common/virtual_region.c
>>> +++ b/xen/common/virtual_region.c
>>> @@ -9,12 +9,25 @@
>>> #include
>>> #include
>>>
>>> +extern const struct
On 18.03.2024 12:04, Andrew Cooper wrote:
> --- a/xen/common/virtual_region.c
> +++ b/xen/common/virtual_region.c
> @@ -39,6 +39,11 @@ static struct virtual_region core = {
> { __start_bug_frames_2, __stop_bug_frames_2 },
> { __start_bug_frames_3, __stop_bug_frames_3 },
> },
On 18.03.2024 12:04, Andrew Cooper wrote:
> Given 3 statically initialised objects, its easy to link the list at build
> time. There's no need to do it during runtime at boot (and with IRQs-off,
> even).
Hmm, technically that's correct, but isn't the overall result more fragile,
in being more
On 18/03/2024 1:17 pm, Jan Beulich wrote:
> On 18.03.2024 12:04, Andrew Cooper wrote:
>> The start/stop1/etc linkage scheme predates struct virtual_region, and as
>> setup_virtual_regions() shows, it's awkward to express in the new scheme.
>>
>> Change the linker to provide explicit start/stop
On 18.03.2024 12:04, Andrew Cooper wrote:
> The start/stop1/etc linkage scheme predates struct virtual_region, and as
> setup_virtual_regions() shows, it's awkward to express in the new scheme.
>
> Change the linker to provide explicit start/stop symbols for each bugframe
> type, and change
On 18.03.2024 12:04, Andrew Cooper wrote:
> Bugframe linkage is identical in all architectures. This is not surprising
> given that it is (now) only consumed by common/virtual_region.c
>
> Introduce a common BUGFRAMES define in xen.lds.h ahead of rearranging their
> structure.
>
> No functional
On 15.03.2024 16:55, Nicola Vetrini wrote:
> Delete unused functions from 'iommu_guest.c'.
>
> No functional change.
>
> Signed-off-by: Nicola Vetrini
> ---
> guest_iommu_add_ptr_log has still one caller, but even that seems
> suspicious.
As said, it should be dropped. You remove ...
> -/*
flight 185071 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185071/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit1 18 guest-start/debian.repeat fail in 185063 REGR.
vs. 184921
Tests
On 18/03/2024 9:13 am, Jan Beulich wrote:
> On 14.03.2024 19:51, Andrew Cooper wrote:
>> On 14/03/2024 6:47 pm, Andrew Cooper wrote:
>>> On 14/03/2024 2:30 pm, Jan Beulich wrote:
On 13.03.2024 18:27, Andrew Cooper wrote:
> --- a/xen/drivers/passthrough/x86/iommu.c
> +++
On 18/03/2024 10:54 am, Jan Beulich wrote:
> I can only guess that using block_speculation() there was a leftover
> from, earlier on, SPECULATIVE_HARDEN_LOCK depending on
> SPECULATIVE_HARDEN_BRANCH.
>
> Fixes: 197ecd838a2a ("locking: attempt to ensure lock wrappers are always
> inline")
>
On Mon, Mar 18, 2024 at 11:42:43AM +0100, Roger Pau Monné wrote:
> On Fri, Mar 15, 2024 at 03:48:46PM +, Anthony PERARD wrote:
> > Anthony PERARD (3):
> > make-fligh: Fix freebsd guest test test-id
> > mfi-common: Rework toolstack-disk_format test matrix
> > ap-common: Switch to Linux
On Mon, Mar 18, 2024 at 11:54 AM 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
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
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
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
There is nothing that setup_virtual_regions() does which can't be done at
build time. Make this happen.
Importantly, this removes logic from needed prior to setting up exceptions.
Andrew Cooper (4):
xen/link: Introduce a common BUGFRAMES definition
xen/virtual-region: Rework how bugframe
Given 3 statically initialised objects, its easy to link the list at build
time. There's no need to do it during runtime at boot (and with IRQs-off,
even).
As a consequence, register_virtual_region() can now move inside ifdef
CONFIG_LIVEPATCH like unregister_virtual_region().
Signed-off-by:
All other actions it used to perform have been converted to build-time
initialisation. The extable setup can done at build time too.
This is one fewer setup step required to get exceptions working.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Stefano
Bugframe linkage is identical in all architectures. This is not surprising
given that it is (now) only consumed by common/virtual_region.c
Introduce a common BUGFRAMES define in xen.lds.h ahead of rearranging their
structure.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan
The start/stop1/etc linkage scheme predates struct virtual_region, and as
setup_virtual_regions() shows, it's awkward to express in the new scheme.
Change the linker to provide explicit start/stop symbols for each bugframe
type, and change virtual_region to have a stop pointer rather than a
I can only guess that using block_speculation() there was a leftover
from, earlier on, SPECULATIVE_HARDEN_LOCK depending on
SPECULATIVE_HARDEN_BRANCH.
Fixes: 197ecd838a2a ("locking: attempt to ensure lock wrappers are always
inline")
Signed-off-by: Jan Beulich
---
Noticed while backporting to
On Fri, Mar 15, 2024 at 03:48:46PM +, Anthony PERARD wrote:
> Patch series available in this git branch:
> https://xenbits.xen.org/git-http/people/aperard/osstest.git br.linux-6.1-v2
>
> Hi,
>
> A set of patch which lead to using Linux 6.1 instead of 4.19 as a default
> kernel on x86.
>
>
On Fri, Mar 15, 2024 at 12:13:22PM +, Andrew Cooper wrote:
> The use of __clear_bit() forces dmask to be spilled to the stack, and
> interferes with the compiler heuristcs for some upcoming improvements to the
> ffs() code generation.
>
> First, shrink dmask to just the active vectors by
On Fri, Mar 15, 2024 at 07:57:04PM +, Andrew Cooper wrote:
> Right now, check_nmi_watchdog() has two processing loops over all online CPUs
> using prev_nmi_count as storage.
>
> Use a cpumask_t instead (1/32th as much initdata) and have wait_for_nmis()
> make the determination of whether it
On 14.03.2024 19:51, Andrew Cooper wrote:
> On 14/03/2024 6:47 pm, Andrew Cooper wrote:
>> On 14/03/2024 2:30 pm, Jan Beulich wrote:
>>> On 13.03.2024 18:27, Andrew Cooper wrote:
--- a/xen/drivers/passthrough/x86/iommu.c
+++ b/xen/drivers/passthrough/x86/iommu.c
@@ -641,7 +641,7 @@
On 16.03.2024 01:07, Stefano Stabellini wrote:
> On Fri, 15 Mar 2024, Jan Beulich wrote:
>> On 14.03.2024 23:17, Stefano Stabellini wrote:
>>> Xen makes assumptions about the size of integer types on the various
>>> architectures. Document these assumptions.
>>
>> My prior reservation wrt exact vs
On 16.03.2024 01:43, Stefano Stabellini wrote:
> On Fri, 15 Mar 2024, Jan Beulich wrote:
>> On 14.03.2024 23:59, Stefano Stabellini wrote:
>>> On Mon, 11 Mar 2024, Simone Ballarin wrote:
On 11/03/24 14:56, Jan Beulich wrote:
> On 11.03.2024 13:00, Simone Ballarin wrote:
>> On 11/03/24
On 3/14/24 17:04, Jan Beulich wrote:
On 13.03.2024 17:41, Vaishali Thakkar wrote:
The suffix _guest is redundant for asid bit. Drop it
to avoid adding extra code volume.
While we're here, replace 0/1 with false/true and use
VMCB accessors instead of open coding.
Suggested-by: Andrew Cooper
On 15.03.2024 19:05, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/configs/tiny64_defconfig
> +++ b/xen/arch/riscv/configs/tiny64_defconfig
> @@ -7,6 +7,23 @@
> # CONFIG_GRANT_TABLE is not set
> # CONFIG_SPECULATIVE_HARDEN_ARRAY is not set
> # CONFIG_MEM_ACCESS is not set
> +# CONFIG_ARGO is
On 15.03.2024 15:45, George Dunlap wrote:
> On Fri, Mar 15, 2024 at 2:13 PM Jan Beulich wrote:
>> On 15.03.2024 14:55, Julien Grall wrote:
>>> On 15/03/2024 13:24, Jan Beulich wrote:
On 15.03.2024 13:17, George Dunlap wrote:
> On Fri, Mar 15, 2024 at 11:57 AM Jan Beulich wrote:
>>>
flight 185069 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185069/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 185062
test-amd64-amd64-xl-qemuu-win7-amd64
On 18.03.24 08:14, Xin Li (Intel) wrote:
The stack of a task has been separated from the memory of a task_struct
struture for a long time on x86, as a result __{start,end}_init_task no
longer mark the start and end of the init_task structure, but its stack
only.
Rename __{start,end}_init_task
The stack of a task has been separated from the memory of a task_struct
struture for a long time on x86, as a result __{start,end}_init_task no
longer mark the start and end of the init_task structure, but its stack
only.
Rename __{start,end}_init_task to __{start,end}_init_stack.
Note other
On 15.03.24 11:58, Julien Grall wrote:
On 14/03/2024 14:22, Henry Wang wrote:
Hi Julien,
Hi,
On 3/14/2024 9:27 PM, Julien Grall wrote:
Hi Henry,
On 28/02/2024 01:58, Henry Wang wrote:
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index a84e706d77..d9ebd55d4a 100644
---
101 - 142 of 142 matches
Mail list logo
