While multiple -c options may be unexpected, we'd still better deal with
them properly.
Also restore the blank line that was bogusly zapped by the same commit.
Coverity-ID: 1638723
Fixes: e4ad2836842a ("xentrace: Implement cpu mask range parsing of human
values (-c)")
Signed-off-by: Jan Beulich
The ssid_label field requires separate freeing; make sure to call
libxl_dominfo_dispose(). And then, for good measure, also
libxl_dominfo_init().
Coverity-ID: 1638727
Coverity-ID: 1638728
Fixes: c458c404da16 ("xl: use libxl_domain_info to get the uuid in printf_info")
Fixes: 48dab9767d2e ("tools/x
The backend_domname field requires separate freeing; make sure to call
libxl_device_vtpm_dispose() also on respective error paths.
Coverity-ID: 1638719
Fixes: dde22055ac3a ("libxl: add vtpm support")
Signed-off-by: Jan Beulich
--- a/tools/xl/xl_vtpm.c
+++ b/tools/xl/xl_vtpm.c
@@ -44,12 +44,14 @@
On 2025-01-10 09:56, Nicola Vetrini wrote:
On 2025-01-10 09:29, Roger Pau Monné wrote:
On Thu, Jan 09, 2025 at 03:57:24PM -0800, Stefano Stabellini wrote:
On Thu, 9 Jan 2025, Nicola Vetrini wrote:
> On 2025-01-04 01:20, Stefano Stabellini wrote:
> > Hi Nicola, one question below
>
> I will u
On 14/01/2025 8:12 am, Jan Beulich wrote:
> The ssid_label field requires separate freeing; make sure to call
> libxl_dominfo_dispose(). And then, for good measure, also
> libxl_dominfo_init().
>
> Coverity-ID: 1638727
> Coverity-ID: 1638728
> Fixes: c458c404da16 ("xl: use libxl_domain_info to get
On 14/01/2025 8:12 am, Jan Beulich wrote:
> While multiple -c options may be unexpected, we'd still better deal with
> them properly.
>
> Also restore the blank line that was bogusly zapped by the same commit.
>
> Coverity-ID: 1638723
> Fixes: e4ad2836842a ("xentrace: Implement cpu mask range parsi
On 1/14/25 9:12 AM, Jan Beulich wrote:
The ssid_label field requires separate freeing; make sure to call
libxl_dominfo_dispose(). And then, for good measure, also
libxl_dominfo_init().
Coverity-ID: 1638727
Coverity-ID: 1638728
Fixes: c458c404da16 ("xl: use libxl_domain_info to get the uuid in p
Hello Oleksii,
This is in principle ready to go in now (I'm currently running a
private Eclair scan to ensure the patch is still OK against current
staging). I would like to ask for a release Ack.
Thanks, Roger.
On Tue, Nov 26, 2024 at 10:35:08AM +0100, Roger Pau Monne wrote:
> There are no vio
On 2025-01-14 12:22, Roger Pau Monné wrote:
Hello Oleksii,
This is in principle ready to go in now (I'm currently running a
private Eclair scan to ensure the patch is still OK against current
staging). I would like to ask for a release Ack.
One nit below, which I overlooked initially
Thank
On 1/14/25 9:12 AM, Jan Beulich wrote:
While multiple -c options may be unexpected, we'd still better deal with
them properly.
Also restore the blank line that was bogusly zapped by the same commit.
Coverity-ID: 1638723
Fixes: e4ad2836842a ("xentrace: Implement cpu mask range parsing of human
On 1/14/25 9:13 AM, Jan Beulich wrote:
The backend_domname field requires separate freeing; make sure to call
libxl_device_vtpm_dispose() also on respective error paths.
Coverity-ID: 1638719
Fixes: dde22055ac3a ("libxl: add vtpm support")
Signed-off-by: Jan Beulich
R-Acked-By: Oleksii Kuroc
On Tue, Jan 14, 2025 at 12:12:03PM +0100, Oleksii Kurochko wrote:
>
> On 1/13/25 6:52 PM, Roger Pau Monné wrote:
> > On Mon, Jan 13, 2025 at 05:07:55PM +0100, Marek Marczykowski-Górecki wrote:
> > > On Fri, Sep 13, 2024 at 09:59:06AM +0200, Roger Pau Monne wrote:
> > > > Allow setting the used wal
On 14.01.2025 10:59, Frediano Ziglio wrote:
> Output file didn't have correct alignment.
> Allows alignment into data or code up to 2mb.
>
> Signed-off-by: Frediano Ziglio
Afaic this is way too little of a description. For example, ...
> --- a/xen/arch/x86/boot/Makefile
> +++ b/xen/arch/x86/boo
On 1/14/25 12:27 PM, Roger Pau Monné wrote:
On Tue, Jan 14, 2025 at 12:12:03PM +0100, Oleksii Kurochko wrote:
On 1/13/25 6:52 PM, Roger Pau Monné wrote:
On Mon, Jan 13, 2025 at 05:07:55PM +0100, Marek Marczykowski-Górecki wrote:
On Fri, Sep 13, 2024 at 09:59:06AM +0200, Roger Pau Monne wrote:
On 1/14/25 12:40 PM, Oleksii Kurochko wrote:
On 1/14/25 12:27 PM, Roger Pau Monné wrote:
On Tue, Jan 14, 2025 at 12:12:03PM +0100, Oleksii Kurochko wrote:
On 1/13/25 6:52 PM, Roger Pau Monné wrote:
On Mon, Jan 13, 2025 at 05:07:55PM +0100, Marek Marczykowski-Górecki wrote:
On Fri, Sep 13,
Hi Roger,
On 1/14/25 12:22 PM, Roger Pau Monné wrote:
Hello Oleksii,
This is in principle ready to go in now (I'm currently running a
private Eclair scan to ensure the patch is still OK against current
staging). I would like to ask for a release Ack.
R-Acked-by: Oleksii Kurochko
Thanks.
~
Output file didn't have correct alignment.
Allows alignment into data or code up to 2mb.
Intermediate object files are kept in order to copy alignment
from object produced by the linker and final object (produced
by combine_two_binaries.py script).
Signed-off-by: Frediano Ziglio
---
xen/arch/x86
On 14/01/2025 8:13 am, Jan Beulich wrote:
> The backend_domname field requires separate freeing; make sure to call
> libxl_device_vtpm_dispose() also on respective error paths.
>
> Coverity-ID: 1638719
> Fixes: dde22055ac3a ("libxl: add vtpm support")
> Signed-off-by: Jan Beulich
Reviewed-by: And
Hello,
The following series should fix the usage of devices behind a VMD bridge
when running Linux as a Xen PV hardware domain (dom0). I've only been
able to test PV. I think PVH should also work but I don't have hardware
capable of testing it right now.
I don't expect the first two patches to b
MSI remapping bypass (directly configuring MSI entries for devices on the
VMD bus) won't work under Xen, as Xen is not aware of devices in such bus,
and hence cannot configure the entries using the pIRQ interface in the PV
case, and in the PVH case traps won't be setup for MSI entries for such
devi
The current hypercall interface for doing PCI device operations always uses
a segment field that has a 16 bit width. However on Linux there are buses
like VMD that hook up devices into the PCI hierarchy at segment >= 0x1,
after the maximum possible segment enumerated in ACPI.
Attempting to re
Setting pci_msi_ignore_mask inhibits the toggling of the mask bit for both
MSI and MSI-X entries globally, regardless of the IRQ chip they are using.
Only Xen sets the pci_msi_ignore_mask when routing physical interrupts over
event channels, to prevent PCI code from attempting to toggle the maskbit
On Tue, Jan 14, 2025 at 10:32:25AM +0100, Roger Pau Monné wrote:
> On Mon, Jan 13, 2025 at 06:42:44PM +, Teddy Astie wrote:
> > Solaris 11.4 tries to access this MSR on some Intel platforms without
> > properly
> > setting up a proper #GP handler, which leads to a immediate crash.
> >
> > Emu
On Mon, Jan 13, 2025 at 06:42:44PM +, Teddy Astie wrote:
> Solaris 11.4 tries to access this MSR on some Intel platforms without properly
> setting up a proper #GP handler, which leads to a immediate crash.
>
> Emulate the access of this MSR by giving it a legal value (all values set to
> defa
On 14/01/2025 4:25 am, Volodymyr Babchuk wrote:
> Volodymyr Babchuk (4):
> common: remove -fno-stack-protector from EMBEDDED_EXTRA_CFLAGS
> xen: common: add ability to enable stack protector
> xen: arm: enable stack protector feature
> CHANGELOG.md: Mention stack-protector feature
Reviewed
On Mon, Jan 13, 2025 at 09:53:21AM -0700, Keith Busch wrote:
> On Mon, Jan 13, 2025 at 05:45:20PM +0100, Roger Pau Monné wrote:
> > On Mon, Jan 13, 2025 at 08:11:19AM -0700, Keith Busch wrote:
> > > On Mon, Jan 13, 2025 at 11:03:58AM +0100, Roger Pau Monné wrote:
> > > >
> > > > Hm, OK, but isn't
On 1/13/25 6:52 PM, Roger Pau Monné wrote:
On Mon, Jan 13, 2025 at 05:07:55PM +0100, Marek Marczykowski-Górecki wrote:
On Fri, Sep 13, 2024 at 09:59:06AM +0200, Roger Pau Monne wrote:
Allow setting the used wallclock from the command line. When the option is set
to a value different than `aut
On Tue, Jan 14, 2025 at 12:44:39PM +0100, Oleksii Kurochko wrote:
>
> On 1/14/25 12:40 PM, Oleksii Kurochko wrote:
> >
> >
> > On 1/14/25 12:27 PM, Roger Pau Monné wrote:
> > > On Tue, Jan 14, 2025 at 12:12:03PM +0100, Oleksii Kurochko wrote:
> > > > On 1/13/25 6:52 PM, Roger Pau Monné wrote:
>
On 14/01/2025 4:25 am, Volodymyr Babchuk wrote:
> diff --git a/xen/common/stack-protector.c b/xen/common/stack-protector.c
> new file mode 100644
> index 00..8fa9f6147f
> --- /dev/null
> +++ b/xen/common/stack-protector.c
> @@ -0,0 +1,51 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
Output file didn't have correct alignment.
Allows alignment into data or code up to 2mb.
Signed-off-by: Frediano Ziglio
---
xen/arch/x86/boot/Makefile| 8
xen/tools/combine_two_binaries.py | 7 ++-
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/xen/arch/x86/
On 13/01/2025 6:42 pm, Teddy Astie wrote:
> Solaris 11.4 tries
Is it only Solaris 11.4, or is the simply the one repro you had?
Have you reported a bug?
> to access this MSR on some Intel platforms without properly
> setting up a proper #GP handler, which leads to a immediate crash.
Minor gram
On Tue, Jan 14, 2025 at 12:24:30PM +0100, Nicola Vetrini wrote:
> On 2025-01-14 12:22, Roger Pau Monné wrote:
> > Hello Oleksii,
> >
> > This is in principle ready to go in now (I'm currently running a
> > private Eclair scan to ensure the patch is still OK against current
> > staging). I would l
On 1/14/25 8:33 AM, Jan Beulich wrote:
+RISCV_ISA_EXT_DATA(i, RISCV_ISA_EXT_i),
+RISCV_ISA_EXT_DATA(m, RISCV_ISA_EXT_m),
+RISCV_ISA_EXT_DATA(a, RISCV_ISA_EXT_a),
+RISCV_ISA_EXT_DATA(f, RISCV_ISA_EXT_f),
+RISCV_ISA_EXT_DATA(d, RISCV_ISA_EXT_d),
+RISCV_ISA_EXT_DATA(q, RISCV
On 12.12.2024 02:17, Andrew Cooper wrote:
> On 12/12/2024 12:13 am, Volodymyr Babchuk wrote:
>> Hello Jan,
>>
>> Jan Beulich writes:
>>
>>> On 11.12.2024 03:04, Volodymyr Babchuk wrote:
Both GCC and Clang support -fstack-protector feature, which add stack
canaries to functions where stac
On Tue, Jan 14, 2025 at 03:48:54PM +0100, Nicola Vetrini wrote:
> Simone Ballarin is no longer actively involved in reviewing
> the ECLAIR integration for Xen. I am stepping up as a reviewer.
>
> Signed-off-by: Nicola Vetrini
Acked-by: Roger Pau Monné
Adding Simone to the Cc list, it would be
On 09.01.2025 18:33, Roger Pau Monné wrote:
> On Thu, Jan 09, 2025 at 09:59:58AM +0100, Jan Beulich wrote:
>> On 08.01.2025 15:26, Roger Pau Monne wrote:
>>> @@ -2048,8 +2060,6 @@ static void __context_switch(void)
>>> if ( pd != nd )
>>> cpumask_clear_cpu(cpu, pd->dirty_cpumask);
>>>
On 08.01.2025 16:11, Roger Pau Monne wrote:
> The pv_{set,destroy}_gdt() functions rely on the L1 table(s) that contain such
> mappings being stashed in the domain structure, and thus such mappings being
> modified by merely updating the L1 entries.
>
> Switch both pv_{set,destroy}_gdt() to instea
On 08.01.2025 15:26, Roger Pau Monne wrote:
> Hello,
>
> The aim of this series is to introduce the functionality required to
> create linear mappings visible to a single pCPU.
>
> Doing so requires having a per-vCPU root page-table (L4), and hence
> requires shadowing the guest selected L4 on PV
From: Slavisa Petrovic
This patch introduces initial support for running RISC-V as a Xen guest.
It provides the necessary infrastructure and stubs for Xen-specific
operations. Key changes include:
- Modifications to the RISC-V kernel to integrate Xen-specific hypercalls
and interfaces, with fu
On 02.01.2025 09:45, Tu Dinh wrote:
> --- a/xen/arch/x86/include/asm/msr-index.h
> +++ b/xen/arch/x86/include/asm/msr-index.h
> @@ -112,6 +112,8 @@
> #define MCU_OPT_CTRL_GDS_MIT_DIS (_AC(1, ULL) << 4)
> #define MCU_OPT_CTRL_GDS_MIT_LOCK (_AC(1, ULL) << 5)
>
> +#define MS
On 08.01.2025 15:26, Roger Pau Monne wrote:
> In preparation for the per-domain area being per-vCPU. This requires moving
> some of the {create,destroy}_perdomain_mapping() calls to the domain
> initialization and tear down paths into vCPU initialization and tear down.
Am I confused or DYM "s/ to
On 02.01.2025 09:45, Tu Dinh wrote:
> Signed-off-by: Tu Dinh
> ---
> tools/libs/light/libxl_cpuid.c | 3 +++
> tools/misc/xen-cpuid.c | 3 +++
> 2 files changed, 6 insertions(+)
>
> diff --git a/tools/libs/light/libxl_cpuid.c b/tools/libs/light/libxl_cpuid.c
> index 063fe86eb7..05be36f25
On 02.01.2025 09:45, Tu Dinh wrote:
> --- a/xen/arch/x86/include/asm/cpufeature.h
> +++ b/xen/arch/x86/include/asm/cpufeature.h
> @@ -219,6 +219,11 @@ static inline bool boot_cpu_has(unsigned int feat)
> #define cpu_has_rfds_no boot_cpu_has(X86_FEATURE_RFDS_NO)
> #define cpu_has_rfds_clea
On 02.01.2025 09:45, Tu Dinh wrote:
> --- a/xen/arch/x86/cpu-policy.c
> +++ b/xen/arch/x86/cpu-policy.c
> @@ -190,6 +190,16 @@ static void sanitise_featureset(uint32_t *fs)
> }
> }
>
> +static void recalculate_arch_lbr(struct cpu_policy *p)
> +{
> +if ( p->basic.max_leaf < 0x1c ||
> +
On 02.01.2025 09:45, Tu Dinh wrote:
> Signed-off-by: Tu Dinh
This needs a non-empty description to clarify why this would be needed.
Jan
> --- a/xen/arch/x86/include/asm/domain.h
> +++ b/xen/arch/x86/include/asm/domain.h
> @@ -638,6 +638,7 @@ struct arch_vcpu
> * #NM handler, we XRSTOR th
On Tue, Jan 14, 2025 at 9:41 PM Milan Djokic wrote:
>
> From: Slavisa Petrovic
>
> This patch introduces initial support for running RISC-V as a Xen guest.
> It provides the necessary infrastructure and stubs for Xen-specific
> operations. Key changes include:
>
> - Modifications to the RISC-V ke
On 2025-01-14 16:00, Roger Pau Monné wrote:
On Tue, Jan 14, 2025 at 03:48:54PM +0100, Nicola Vetrini wrote:
Simone Ballarin is no longer actively involved in reviewing
the ECLAIR integration for Xen. I am stepping up as a reviewer.
Signed-off-by: Nicola Vetrini
Acked-by: Roger Pau Monné
On 14/01/2025 1:22 pm, Jan Beulich wrote:
> On 12.12.2024 02:17, Andrew Cooper wrote:
>> On 12/12/2024 12:13 am, Volodymyr Babchuk wrote:
>>> Hello Jan,
>>>
>>> Jan Beulich writes:
>>>
On 11.12.2024 03:04, Volodymyr Babchuk wrote:
> Both GCC and Clang support -fstack-protector feature, wh
The ssid_label field requires separate freeing; make sure to call
libxl_dominfo_dispose() as well as libxl_dominfo_init(). Since vcpuset()
calls only the former, add a call to the latter there at the same time.
Coverity-ID: 1638727
Coverity-ID: 1638728
Fixes: c458c404da16 ("xl: use libxl_domain_in
Hi,
On 09/01/2025 16:57, Thomas Zimmermann wrote:
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 8.
Signed-off-by: Thomas Zimmermann
Cc: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_gem.c | 15 +++
1 file cha
On 14/01/2025 1:47 pm, Jan Beulich wrote:
> On 14.01.2025 14:28, Andrew Cooper wrote:
>> On 14/01/2025 1:22 pm, Jan Beulich wrote:
>>> On 12.12.2024 02:17, Andrew Cooper wrote:
On 12/12/2024 12:13 am, Volodymyr Babchuk wrote:
> Hello Jan,
>
> Jan Beulich writes:
>
>> On 11
Simone Ballarin is no longer actively involved in reviewing
the ECLAIR integration for Xen. I am stepping up as a reviewer.
Signed-off-by: Nicola Vetrini
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 392f780f7617..c11b82eca98f
On Tue, Jan 14, 2025 at 03:23:21PM +0100, Oleksii Kurochko wrote:
>
> On 1/14/25 1:13 PM, Roger Pau Monné wrote:
> > On Tue, Jan 14, 2025 at 12:44:39PM +0100, Oleksii Kurochko wrote:
> > > On 1/14/25 12:40 PM, Oleksii Kurochko wrote:
> > > >
> > > > On 1/14/25 12:27 PM, Roger Pau Monné wrote:
> >
On 14/01/2025 1:29 pm, Jan Beulich wrote:
> The ssid_label field requires separate freeing; make sure to call
> libxl_dominfo_dispose() as well as libxl_dominfo_init(). Since vcpuset()
> calls only the former, add a call to the latter there at the same time.
>
> Coverity-ID: 1638727
> Coverity-ID:
On 14.01.2025 14:28, Andrew Cooper wrote:
> On 14/01/2025 1:22 pm, Jan Beulich wrote:
>> On 12.12.2024 02:17, Andrew Cooper wrote:
>>> On 12/12/2024 12:13 am, Volodymyr Babchuk wrote:
Hello Jan,
Jan Beulich writes:
> On 11.12.2024 03:04, Volodymyr Babchuk wrote:
>> Both
On 1/14/25 1:13 PM, Roger Pau Monné wrote:
On Tue, Jan 14, 2025 at 12:44:39PM +0100, Oleksii Kurochko wrote:
On 1/14/25 12:40 PM, Oleksii Kurochko wrote:
On 1/14/25 12:27 PM, Roger Pau Monné wrote:
On Tue, Jan 14, 2025 at 12:12:03PM +0100, Oleksii Kurochko wrote:
On 1/13/25 6:52 PM, Roger P
On 1/14/25 3:58 PM, Roger Pau Monné wrote:
On Tue, Jan 14, 2025 at 03:23:21PM +0100, Oleksii Kurochko wrote:
On 1/14/25 1:13 PM, Roger Pau Monné wrote:
On Tue, Jan 14, 2025 at 12:44:39PM +0100, Oleksii Kurochko wrote:
On 1/14/25 12:40 PM, Oleksii Kurochko wrote:
On 1/14/25 12:27 PM, Roger P
On 08.01.2025 15:26, Roger Pau Monne wrote:
> The pv_map_ldt_shadow_page() and pv_destroy_ldt() functions rely on the L1
> table(s) that contain such mappings being stashed in the domain structure, and
> thus such mappings being modified by merely updating the require L1 entries.
>
> Switch pv_map
If randconfig enables coverage support the build times out due to GNU LD
taking too long. For the time being prevent coverage from being enabled in
clang randconfig job.
Signed-off-by: Roger Pau Monné
---
Cc: Oleksii Kurochko
---
I will fix the orphaned section stuff separately, as I'm consider
On 14/01/2025 5:43 pm, Roger Pau Monne wrote:
> If randconfig enables coverage support the build times out due to GNU LD
> taking too long. For the time being prevent coverage from being enabled in
> clang randconfig job.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Andrew Cooper
> ---
> Cc: O
Le 14/01/2025 à 17:13, Milan Djokic a écrit :
> diff --git a/test.txt b/test.txt
> new file mode 100644
> index ..e54267998982
> --- /dev/null
> +++ b/test.txt
> @@ -0,0 +1,21 @@
> +WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
> +#120:
> +new file mode 10064
From: Josh Poimboeuf
Deferring a code patching IPI is unsafe if the patched code is in a
noinstr region. In that case the text poke code must trigger an
immediate IPI to all CPUs, which can rudely interrupt an isolated NO_HZ
CPU running in userspace.
If a noinstr static call only needs to be pa
Context
===
We've observed within Red Hat that isolated, NOHZ_FULL CPUs running a
pure-userspace application get regularly interrupted by IPIs sent from
housekeeping CPUs. Those IPIs are caused by activity on the housekeeping CPUs
leading to various on_each_cpu() calls, e.g.:
64359.05220959
The static call is only ever updated in
__init pv_time_init()
__init xen_time_setup_guest()
so mark it appropriately as __ro_after_init.
Signed-off-by: Valentin Schneider
---
arch/arm64/kernel/paravirt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/
Later commits will cause objtool to warn about static calls being used in
.noinstr sections in order to safely defer instruction patching IPIs
targeted at NOHZ_FULL CPUs.
pv_sched_clock is updated in:
o __init vmware_paravirt_ops_setup()
o __init xen_init_time_common()
o kvm_sched_clock_init() <-
call_dest_name() does not get passed the file pointer of validate_call(),
which means its invocation of insn_reloc() will always return NULL. Make it
take a file pointer.
While at it, make sure call_dest_name() uses arch_dest_reloc_offset(),
otherwise it gets the pv_ops[] offset wrong.
Fabricatin
A later commit will reduce the size of the RCU watching counter to free up
some bits for another purpose. Paul suggested adding a config option to
test the extreme case where the counter is reduced to its minimum usable
width for rcutorture to poke at, so do that.
Make it only configurable under R
The static call is only ever updated in
__init pv_time_init()
__init xen_init_time_common()
__init vmware_paravirt_ops_setup()
__init xen_time_setup_guest(
so mark it appropriately as __ro_after_init.
Signed-off-by: Valentin Schneider
---
arch/x86/kernel/paravirt.c | 2 +-
1 file chang
Later commits will cause objtool to warn about static calls being used in
.noinstr sections in order to safely defer instruction patching IPIs
targeted at NOHZ_FULL CPUs.
perf_lopwr_cb is used in .noinstr code, but is only ever updated in __init
amd_brs_lopwr_init(), and can thus be marked as __ro
From: Josh Poimboeuf
Deferring a code patching IPI is unsafe if the patched code is in a
noinstr region. In that case the text poke code must trigger an
immediate IPI to all CPUs, which can rudely interrupt an isolated NO_HZ
CPU running in userspace.
Some noinstr static branches may really need
The static call is only ever updated in
__init pv_time_init()
__init xen_time_setup_guest()
so mark it appropriately as __ro_after_init.
Signed-off-by: Valentin Schneider
---
arch/loongarch/kernel/paravirt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/loongarch
I had to look into objtool itself to understand what this warning was
about; make it more explicit.
Signed-off-by: Valentin Schneider
Acked-by: Josh Poimboeuf
---
tools/objtool/check.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/objtool/check.c b/tools/objtool/chec
The static call is only ever updated in:
__init pv_time_init()
__init xen_time_setup_guest()
so mark it appropriately as __ro_after_init.
Signed-off-by: Valentin Schneider
---
arch/riscv/kernel/paravirt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/riscv/kernel
Later commits will cause objtool to warn about static calls being used in
.noinstr sections in order to safely defer instruction patching IPIs
targeted at NOHZ_FULL CPUs.
x86_idle is updated in:
o xen_set_default_idle() <- __init xen_arch_setup()
o __init select_idle_routine()
IOW purely init con
We now have an RCU_EXPERT config for testing small-sized RCU dynticks
counter: CONFIG_RCU_DYNTICKS_TORTURE.
Modify scenario TREE04 to exercise to use this config in order to test a
ridiculously small counter (2 bits).
Link:
http://lore.kernel.org/r/4c2cb573-168f-4806-b1d9-164e8276e66a@paulmck-l
From: Josh Poimboeuf
Warn about static branches/calls in noinstr regions, unless the
corresponding key is RO-after-init or has been manually whitelisted with
DEFINE_STATIC_KEY_*_NOINSTR(().
Signed-off-by: Josh Poimboeuf
[Added NULL check for insn_call_dest() return value]
Signed-off-by: Valenti
Later commits will cause objtool to warn about static keys being used in
.noinstr sections in order to safely defer instruction patching IPIs
targeted at NOHZ_FULL CPUs.
stack_erasing_bypass is used in .noinstr code, and can be modified at runtime
(proc/sys/kernel/stack_erasing write). However it
Later patches will require issuing a __flush_tlb_all() from noinstr code.
This requires making both __flush_tlb_local() and __flush_tlb_global()
noinstr-compliant.
For __flush_tlb_local(), xen_flush_tlb() has already been made noinstr, so
it's just native_flush_tlb_global(), and simply __always_in
Later commits will cause objtool to warn about static keys being used in
.noinstr sections in order to safely defer instruction patching IPIs
targeted at NOHZ_FULL CPUs.
These keys are used in .noinstr code, and can be modified at runtime
(/proc/kernel/vmx* write). However it is not expected that
Later commits will cause objtool to warn about static keys being used in
.noinstr sections in order to safely defer instruction patching IPIs
targeted at NOHZ_FULL CPUs.
mds_idle_clear is used in .noinstr code, and can be modified at
runtime (SMT hotplug). Suppressing the text_poke_sync() IPI has
Later commits will cause objtool to warn about static keys being used in
.noinstr sections in order to safely defer instruction patching IPIs
targeted at NOHZ_FULL CPUs.
__sched_clock_stable is used in .noinstr code, and can be modified at
runtime (e.g. time_cpufreq_notifier()). Suppressing the te
CT_STATE_KERNEL being zero means it can be (and is) omitted in a handful of
places. A later patch will change CT_STATE_KERNEL into a non-zero value,
prepare that by using it where it should be:
o In the initial CT state
o At kernel entry / exit
No change in functionality intended.
Signed-off-by:
sched_clock_running is only ever enabled in the __init functions
sched_clock_init() and sched_clock_init_late(), and is never disabled. Mark
it __ro_after_init.
Signed-off-by: Valentin Schneider
---
kernel/sched/clock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/s
vunmap()'s issued from housekeeping CPUs are a relatively common source of
interference for isolated NOHZ_FULL CPUs, as they are hit by the
flush_tlb_kernel_range() IPIs.
Given that CPUs executing in userspace do not access data in the vmalloc
range, these IPIs could be deferred until their next k
With NO_HZ_IDLE, we get CONTEXT_TRACKING_IDLE, so we get these
transitions:
ct_idle_enter()
ct_kernel_exit()
ct_state_inc_clear_work()
ct_idle_exit()
ct_kernel_enter()
ct_work_flush()
With just CONTEXT_TRACKING_IDLE, ct_state_inc_clear_work() is just
ct_state_inc() and ct
Later patches will require issuing a __flush_tlb_all() from noinstr code.
Both __flush_tlb_local() and __flush_tlb_global() are now
noinstr-compliant, so __flush_tlb_all() can be made noinstr itself.
Signed-off-by: Valentin Schneider
---
arch/x86/include/asm/tlbflush.h | 2 +-
arch/x86/mm/tlb.c
The static call is only ever updated in
__init xen_time_setup_guest()
so mark it appropriately as __ro_after_init.
Signed-off-by: Valentin Schneider
---
arch/arm/kernel/paravirt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/kernel/paravirt.c b/arch/arm/kernel
ct_nmi_{enter, exit}() only touches the RCU watching counter and doesn't
modify the actual CT state part context_tracking.state. This means that
upon receiving an IRQ when idle, the CT_STATE_IDLE->CT_STATE_KERNEL
transition only happens in ct_idle_exit().
One can note that ct_nmi_enter() can only
A later patch will require to easily exclude CT_STATE_KERNEL from a genuine
a ct->state read CT_STATE_KERNEL, which requires that value being non-zero
and exclusive with the other CT_STATE_* values.
This increases the size of the CT_STATE region of the ct->state variable by
two bits.
Signed-off-b
text_poke_bp_batch() sends IPIs to all online CPUs to synchronize
them vs the newly patched instruction. CPUs that are executing in userspace
do not need this synchronization to happen immediately, and this is
actually harmful interference for NOHZ_FULL CPUs.
As the synchronization IPIs are sent u
On Tue, Jan 14, 2025 at 6:51 PM Valentin Schneider wrote:
> vunmap()'s issued from housekeeping CPUs are a relatively common source of
> interference for isolated NOHZ_FULL CPUs, as they are hit by the
> flush_tlb_kernel_range() IPIs.
>
> Given that CPUs executing in userspace do not access data i
On 1/14/25 09:51, Valentin Schneider wrote:
> + cr4 = this_cpu_read(cpu_tlbstate.cr4);
> + asm volatile("mov %0,%%cr4": : "r" (cr4 ^ X86_CR4_PGE) : "memory");
> + asm volatile("mov %0,%%cr4": : "r" (cr4) : "memory");
> + /*
> + * In lieu of not having the pinning crap, hard fai
smp_call_function() & friends have the unfortunate habit of sending IPIs to
isolated, NOHZ_FULL, in-userspace CPUs, as they blindly target all online
CPUs.
Some callsites can be bent into doing the right, such as done by commit:
cc9e303c91f5 ("x86/cpu: Disable frequency requests via aperfmperf
From: Peter Zijlstra
Later patches will require issuing a __flush_tlb_all() from noinstr code.
This requires making both __flush_tlb_local() and __flush_tlb_global()
noinstr-compliant.
For __flush_tlb_global(), both native_flush_tlb_global() and xen_flush_tlb()
need to be made noinstr.
Forgo us
On Tue, 14 Jan 2025, Simone Ballarin wrote:
> On 2025-01-14 16:00, Roger Pau Monné wrote:
> > On Tue, Jan 14, 2025 at 03:48:54PM +0100, Nicola Vetrini wrote:
> > > Simone Ballarin is no longer actively involved in reviewing
> > > the ECLAIR integration for Xen. I am stepping up as a reviewer.
> > >
On Tue, 14 Jan 2025, Andrew Cooper wrote:
> On 14/01/2025 5:43 pm, Roger Pau Monne wrote:
> > If randconfig enables coverage support the build times out due to GNU LD
> > taking too long. For the time being prevent coverage from being enabled in
> > clang randconfig job.
> >
> > Signed-off-by: Rog
+Oleksii
On Tue, 14 Jan 2025, Milan Djokic wrote:
> From: Slavisa Petrovic
>
> This patch introduces initial support for running RISC-V as a Xen guest.
> It provides the necessary infrastructure and stubs for Xen-specific
> operations. Key changes include:
>
> - Modifications to the RISC-V kern
[AMD Official Use Only - AMD Internal Distribution Only]
Hi,
> -Original Message-
> From: Jan Beulich
> Sent: Thursday, January 9, 2025 5:46 PM
> To: Penny, Zheng
> Cc: Stabellini, Stefano ; Huang, Ray
> ; Ragiadakou, Xenia ;
> Andryuk, Jason ; Andrew Cooper
> ; Roger Pau Monné ; Julien
Hi,
On 2025/1/9 22:57, Thomas Zimmermann wrote:
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch according to hardware requirements.
Signed-off-by: Thomas Zimmermann
Cc: Sui Jingfeng
Cc: Sui Jingfeng
Reviewed-by: Sui Jingfeng
---
drive
On Tue, Jan 14, 2025 at 06:51:23PM +0100, Valentin Schneider wrote:
> The static call is only ever updated in:
>
> __init pv_time_init()
> __init xen_time_setup_guest()
>
> so mark it appropriately as __ro_after_init.
>
> Signed-off-by: Valentin Schneider
> ---
> arch/riscv/kernel/paravirt
1 - 100 of 112 matches
Mail list logo
