On 11.07.2025 02:15, Stefano Stabellini wrote:
> On Thu, 10 Jul 2025, Dmytro Prokopchuk1 wrote:
>> --- a/xen/common/memory.c
>> +++ b/xen/common/memory.c
>> @@ -773,7 +773,7 @@ static long
>> memory_exchange(XEN_GUEST_HANDLE_PARAM(xen_memory_exchange_t) arg)
>>
>> nrspin_lock(&d
On 11.07.2025 05:50, Penny Zheng wrote:
> In `xenpm get-cpufreq-para `, ->freq_num and ->cpu_num checking are
> tied together via variable "has_num", while ->freq_num only has non-zero value
> when cpufreq driver in legacy P-states mode.
>
> So we drop the "has_num" condition check, and mirror the
On 11.07.2025 06:31, Penny Zheng wrote:
> Function sched_adjust_global is designed for XEN_SYSCTL_scheduler_op, so
> itself and its calling flow, like .adjust_global, shall all be wrapped.
>
> Signed-off-by: Penny Zheng
> Reviewed-by: Stefano Stabellini
> Acked-by: Stewart Hildebrand #a653
> --
On 11.07.2025 06:31, Penny Zheng wrote:
> From: Stefano Stabellini
>
> Wrap sysctl hypercall def and sysctl.o with CONFIG_SYSCTL, and since
> PV_SHIM_EXCLUSIVE needs sorting in the future, we move them out of
> PV_SHIM_EXCLUSIVE condition at the same time.
>
> We need to make SYSCTL with prompt
On 02.07.2025 10:12, Juergen Gross wrote:
> Add support for a Mini-OS config file containing config items with
> numerical values, e.g. CONFIG_FOO=7.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
Albeit I'm puzzled by the use in the next patch. Besides me perhaps simply
not knowing
On 11.07.2025 03:34, Stefano Stabellini wrote:
> On Thu, 10 Jul 2025, Jan Beulich wrote:
>> - the function being a timer handler, it would be preferable if the timer
>> wasn't ever activated in this mode (at which point rather than returning
>> early, the code above could simply be purged, mayb
Hi Michal,
Thank you for reviewing the patch. To answer the following question:
> > +/* DTB starting at this address has already been mapped. */
> When can this happen?
In xen/arch/arm/setup.c `start_xen` early_fdt_map(fdt_paddr) is called twice,
before and after `setup_page_tables` - which i
Hi Michal,
Thank you for reviewing the patch.
> > +/* Zeroing the region will also zero the region enable */
> > +memset(&xen_mpumap[index], 0, sizeof(pr_t));
> Is it ok that for a fast case (i.e. 0-31) our representation of prbar/prlar
> will
> be different from the HW i.e. xen_mpumap[in
On 11.07.2025 03:07, dm...@proton.me wrote:
> On Thu, Jul 10, 2025 at 01:16:24PM +0200, Jan Beulich wrote:
>> On 10.07.2025 03:35, dm...@proton.me wrote:
>>> @@ -877,6 +873,16 @@ struct domain *domain_create(domid_t domid,
>>>
>>> /* All error paths can depend on the above setup. */
>>>
>>> +
Reviewed-by: Alex XZ Cypher Zero
Add intel_idle support for MeteorLake.
C1 and C1E states on Meteorlake are mutually exclusive, like Alderlake
and Raptorlake, but they have little latency difference with measureable
power difference, so always enable "C1E promotion" bit and expose C1E
only.
E
From: Stefano Stabellini
Wrap sysctl hypercall def and sysctl.o with CONFIG_SYSCTL, and since
PV_SHIM_EXCLUSIVE needs sorting in the future, we move them out of
PV_SHIM_EXCLUSIVE condition at the same time.
We need to make SYSCTL with prompt back, add help info and set default
value as y. We sha
The following functions are only to deal with XEN_SYSCTL_page_offline_op,
then shall be wrapped:
- xsm_page_offline()
- online_page()
- query_page_offline()
Signed-off-by: Penny Zheng
Reviewed-by: Stefano Stabellini
---
v1 -> v2:
- add transient #ifdef in sysctl.c for correct compilation
- no ne
Function arch_do_sysctl is to perform arch-specific sysctl op.
Some functions, like psr_get_info() for x86, DTB overlay support for arm,
are solely available through sysctl op, then they all shall be wrapped
with CONFIG_SYSCTL
Also, remove all #ifdef CONFIG_SYSCTL-s in arch-specific sysctl.c, as
w
As function xsm_sysctl() is solely invoked in sysctl.c, we need to
wrap around it with CONFIG_SYSCTL
Signed-off-by: Penny Zheng
Reviewed-by: Stefano Stabellini
---
xen/include/xsm/xsm.h | 4
xen/xsm/dummy.c | 2 ++
xen/xsm/flask/hooks.c | 4
3 files changed, 10 insertions(+)
di
Remove all "depends on !PV_SHIM_EXCLUSIVE" (also the functionally
equivalent "if !...") in Kconfig file, since negative dependancy will badly
affect allyesconfig. Although "if !PV_SHIM_EXCLUSIVE" for CONFIG_VGA is not
truly a dependency, setting PV_SHIM_EXCLUSIVE y still makes it unconfigurable.
So
Function sched_adjust_global is designed for XEN_SYSCTL_scheduler_op, so
itself and its calling flow, like .adjust_global, shall all be wrapped.
Signed-off-by: Penny Zheng
Reviewed-by: Stefano Stabellini
Acked-by: Stewart Hildebrand #a653
---
v1 -> v2:
- no need to wrap declarations
- add trans
It can be beneficial for some dom0less systems to further reduce Xen footprint
via disabling some hypercalls handling code, which may not to be used &
required in such systems. Each hypercall has a separate option to keep
configuration flexible.
Options to disable hypercalls:
- sysctl
- domctl
- h
The following functions is to deal with XEN_SYSCTL_readconsole sub-op, and
shall be wrapped:
- xsm_readconsole()
- read_console_ring()
Signed-off-by: Penny Zheng
Reviewed-by: Stefano Stabellini
---
v2 -> v3:
- move #endif up ahead of the blank line
---
v3 -> v4:
- remove transient "#ifdef CONFIG
In amd-cppc passive mode, it's Xen governor which is responsible for
performance tuning, so governor and CPPC could co-exist. That is, both
governor-info and CPPC-info need to be printed together via xenpm tool.
If we tried to still put it in "struct xen_get_cpufreq_para" (e.g. just move
out of un
Users need to set "cpufreq=amd-cppc" in xen cmdline to enable amd-cppc driver,
which selects ACPI Collaborative Performance and Power Control (CPPC) on
supported AMD hardware to provide a finer grained frequency control mechanism.
`verbose` option can also be included to support verbose print.
Whe
New helpers print_cppc_para() and get_cpufreq_cppc() are introduced to deal
with CPPC-related parameters, in order to be re-used when later exporting new
sub-op "get-cpufreq-cppc".
Signed-off-by: Penny Zheng
---
v5 -> v6:
- new commit
---
tools/misc/xenpm.c | 53 +--
When cpufreq driver in cppc passive mode, it has both cppc and governor
info. We need to invoke two sysctl sub-ops ("get-cpufreq-cppc" and
"get-cpufreq-para") to produce both info.
A new helper cpufreq_in_cppc_passive_mode() is introduced to tell whether
cpufreq driver supports cppc passive mode.
amd-cppc has 2 operation modes: autonomous (active) mode and
non-autonomous (passive) mode.
In active mode, we don't need Xen governor to calculate and tune the cpu
frequency, while hardware built-in CPPC power algorithm will calculate the
runtime workload and adjust cores frequency automatically a
amd-cppc is the AMD CPU performance scaling driver that introduces a
new CPU frequency control mechanism. The new mechanism is based on
Collaborative Processor Performance Control (CPPC) which is a finer grain
frequency management than legacy ACPI hardware P-States.
Current AMD CPU platforms are us
Even if Xen governor is not used in amd-cppc active mode, we could
somehow deduce which performance policy (CPUFREQ_POLICY_xxx) user wants to
apply through which governor they choose, such as:
If user chooses performance governor, they want maximum performance, then
the policy shall be CPUFREQ_POLI
HWP and amd-cppc-epp are both governor-less driver, so we introduce "hw_auto"
flag to together bypass governor-related print in print_cpufreq_para().
In set_cpufreq_para(), a new helper is introduced to help error out when
cpufreq core intialized in governor-less mode.
---
v3 -> v4:
- Include vali
Introduce helper set_amd_cppc_para() and get_amd_cppc_para() to
SET/GET CPPC-related para for amd-cppc/amd-cppc-epp driver.
In get_cpufreq_cppc()/set_cpufreq_cppc(), we include
"processor_pminfo[cpuid]->init & XEN_CPPC_INIT" condition check to deal with
cpufreq driver in amd-cppc.
Also, a new fie
In order to provide backward compatibility with existing governors
that represent performance as frequency, like ondemand, the _CPC
table can optionally provide processor frequency range values, Lowest
frequency and Nominal frequency, to let OS use Lowest Frequency/
Performance and Nominal Frequenc
amd-cppc is the AMD CPU performance scaling driver that introduces a
new CPU frequency control mechanism on modern AMD APU and CPU series in
Xen. The new mechanism is based on Collaborative Processor Performance
Control (CPPC) which provides finer grain frequency management than
legacy ACPI hardwar
_PSD info, consisted of "shared_type" and "struct xen_psd_package", will not
only be provided from px-specific "struct xen_processor_performance", but also
in CPPC data.
Two new helper functions are introduced to deal with _PSD. They will later be
re-used for handling the same data for CPPC.
In th
DOM0 could deliever whatever performance statistic (Px, _CPC) it parses, it is
Xen's responsibility to decide which one it shall accept.
Xen rely on XEN_PROCESSOR_PM_xxx flag to tell which mode ( Px or CPPC )
current cpufreq driver supports, and accepts relative info. It will neglect
unsupported-mo
When _CPC table could not provide processor frequency range
values for Xen governor, we need to read processor max frequency
as anchor point.
So we extract amd cpu core frequency calculation logic from amd_log_freq(),
and wrap it as a new helper amd_process_freq().
Signed-off-by: Penny Zheng
Revi
Right now, only when we failed cpufreq driver registration with -ENODEV, we get
the chance to try the fallback option.
There are two code path erroring out other than -ENODEV in cpufreq driver
registration: one is when the driver itself is broken, like missing mandatory
hooks, cpufreq_register_driv
As we are going to add "struct xen_cppc_para" in "struct xen_sysctl_pm_op" as
a new xenpm sub-op later to specifically dealing with CPPC-info, we need to
follow the naming pattern, to change the struct name to "xen_get_cppc_para",
which is more suitable than "xen_cppc_para".
Signed-off-by: Penny Z
"ondemand" is more suitable to describe a preset in which epp value is set
with medium(CPPC_ENERGY_PERF_BALANCE), showing no preference over performance or
powersave, minimum with lowest and maximum with highest.
Signed-off-by: Penny Zheng
---
v5 -> v6:
- new commit
---
tools/misc/xenpm.c
A helper function handle_cpufreq_cmdline() is introduced to tidy different
handling pathes.
We also add a new helper cpufreq_opts_contain() to ignore redundant setting,
like "cpufreq=hwp;hwp;xen"
Signed-off-by: Penny Zheng
---
v2 -> v3:
- new commit
---
v3 -> v4:
- add one single helper to do the
In `xenpm get-cpufreq-para `, ->freq_num and ->cpu_num checking are
tied together via variable "has_num", while ->freq_num only has non-zero value
when cpufreq driver in legacy P-states mode.
So we drop the "has_num" condition check, and mirror the ->gov_num check for
both ->freq_num and ->cpu_num
Unlike Cx/Px states, for which we need an extra loop to summerize residency (
sum_cx[]/sum_px[]), we could call get_avgfreq_by_cpuid() right before printing.
Also, with later introduction of CPPC mode, average frequency print shall
not depend on the existence of legacy P-states, so we remove "px_ca
On Wed, 9 Jul 2025, Dmytro Prokopchuk1 wrote:
> MISRA C Rule 5.5 states that: "Identifiers shall
> be distinct from macro names".
>
> Update ECLAIR configuration to deviate:
> - clashes in 'xen/include/xen/bitops.h';
> - clashes in 'xen/include/xen/irq.h';
> - clashes in 'xen/common/grant_table.c'
On Thu, 10 Jul 2025, Jan Beulich wrote:
> On 08.07.2025 20:32, Stefano Stabellini wrote:
> > --- a/xen/arch/x86/time.c
> > +++ b/xen/arch/x86/time.c
> > @@ -2297,11 +2297,7 @@ static void cf_check time_calibration(void *unused)
> > };
> >
> > if ( clocksource_is_tsc() )
> > -{
> > -
On 7/10/25 20:15, Stefano Stabellini wrote:
> On Thu, 10 Jul 2025, Dmytro Prokopchuk1 wrote:
>> Rule 10.1: Operands shall not be of an
>> inappropriate essential type
>>
>> The following are non-compliant:
>> - unary minus on unsigned type;
>> - boolean used as a numeric value.
>>
>> Replace unary
On 7/10/25 17:39, Stefano Stabellini wrote:
> On Thu, 10 Jul 2025, Jan Beulich wrote:
>> On 10.07.2025 09:02, Roger Pau Monné wrote:
>>> On Wed, Jul 09, 2025 at 05:44:33PM -0700, Stefano Stabellini wrote:
2) means that the RTOS must be undisturbed when executing the critical
section, whic
On Thu, Jul 10, 2025 at 01:16:24PM +0200, Jan Beulich wrote:
> On 10.07.2025 03:35, dm...@proton.me wrote:
> > @@ -877,6 +873,16 @@ struct domain *domain_create(domid_t domid,
> >
> > /* All error paths can depend on the above setup. */
> >
> > +BUILD_BUG_ON(DOMAIN_CONSOLE_BUF_SIZE <= 0);
On Wed, 9 Jul 2025, Jürgen Groß wrote:
> On 08.07.25 21:01, Stefano Stabellini wrote:
> > On Thu, 3 Jul 2025, Juergen Gross wrote:
> > > When compiling the kernel with LLVM, the following warning was issued:
> > >
> > >drivers/xen/gntdev.c:991: warning: stack frame size (1160) exceeds
> > >
From: Denis Mukhin
Introduce domain_console for grouping data structures used for integrating
domain's diagnostic console with Xen's console driver.
Group all pbuf-related data structures under domain_console. Rename the moved
fields to plain .buf, .idx and .lock names, since all uses of the fi
On 2025-07-02 04:12, Juergen Gross wrote:
Especially for support of Xenstore-stubdom live update some memory must
be handed over to the new kernel without moving it around: as the
9pfs device used for storing and retrieving the state of Xenstore
needs to be kept operational across kexec (it can't
Up until f9f6b22ab "xen/arm: Map ITS doorbell register to IOMMU page
tables" the only caller of iommu_map on ARM was grant_table.c which has
a specific usage model and restrictions as described by the in-code
comment in arm_iommu_map_page.
f9f6b22ab introduced a second caller to iommu_map on ARM:
On Thu, 10 Jul 2025, Dmytro Prokopchuk1 wrote:
> Rule 10.1: Operands shall not be of an
> inappropriate essential type
>
> The following are non-compliant:
> - unary minus on unsigned type;
> - boolean used as a numeric value.
>
> Replace unary '-' operator with multiplying by '-1L' or '-1LL'.
>
CI tests:
https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/pipelines/1919687496
On 7/11/25 01:10, Dmytro Prokopchuk1 wrote:
> Rule 10.1: Operands shall not be of an
> inappropriate essential type
>
> The following are non-compliant:
> - unary minus on unsigned type;
> - boolean used as a nu
Rule 10.1: Operands shall not be of an
inappropriate essential type
The following are non-compliant:
- unary minus on unsigned type;
- boolean used as a numeric value.
Replace unary '-' operator with multiplying by '-1L' or '-1LL'.
Replace numeric constant '-1UL' with '~0UL'.
Replace numeric cons
On Thu, 10 Jul 2025, Jan Beulich wrote:
> On 10.07.2025 09:02, Roger Pau Monné wrote:
> > On Wed, Jul 09, 2025 at 05:44:33PM -0700, Stefano Stabellini wrote:
> >> 2) means that the RTOS must be undisturbed when executing the critical
> >> section, which is typically right after receiving the interr
On Thu, Jul 10, 2025 at 04:11:15PM +, Anthoine Bourgeois wrote:
> We found at Vates that there are lot of spurious interrupts when
> benchmarking the PV drivers of Xen. This issue appeared with a patch
> that addresses security issue XSA-391 (see Fixes below). On an iperf
> benchmark, spurious
On Thu, Jul 10, 2025 at 10:15:54AM +0200, Jan Beulich wrote:
> On 10.07.2025 03:59, dm...@proton.me wrote:
> > On Tue, Jun 24, 2025 at 09:33:04AM +0200, Jan Beulich wrote:
> >> On 24.06.2025 09:31, dm...@proton.me wrote:
> >>> On Tue, Jun 24, 2025 at 07:50:33AM +0200, Jan Beulich wrote:
> On 2
On Thu, 10 Jul 2025, Jan Beulich wrote:
> On 10.07.2025 03:59, dm...@proton.me wrote:
> > On Tue, Jun 24, 2025 at 09:33:04AM +0200, Jan Beulich wrote:
> >> On 24.06.2025 09:31, dm...@proton.me wrote:
> >>> On Tue, Jun 24, 2025 at 07:50:33AM +0200, Jan Beulich wrote:
> On 24.06.2025 05:56, dm..
We found at Vates that there are lot of spurious interrupts when
benchmarking the PV drivers of Xen. This issue appeared with a patch
that addresses security issue XSA-391 (see Fixes below). On an iperf
benchmark, spurious interrupts can represent up to 50% of the
interrupts.
Spurious interrupts a
On 22.03.2023 15:13, Jan Beulich wrote:
> On 20.03.2023 16:28, Anthony PERARD wrote:
>> This simple comment allows to detect when $(CC) changes version.
>> Kconfig will be rerun in this case. (Rerun is forced by
>> include/config/auto.conf.cmd which detects changes of CC_VERSION_TEXT
>> value).
>>
Use an existing macro instead of open-coding the operation and flags
handling, just like we already do in x86_emul_rmw(). While possibly
yielding slightly larger compiled code, it's easier to maintain this
way.
Note that the setting of dst.orig_val was already redundant with that
done ahead of the
Hi everyone. Just a friendly reminder that the July Xen Project Community
Call is happening in 45 minutes. Everyone is welcome!
Agenda: https://cryptpad.fr/pad/#/2/pad/edit/0f4wUR0R9bQp-kOVpzVp2rJl/
Meeting link: https://meet.jit.si/XenProjectCommunityCall
Hope to see you there!
Cody Zuschlag
X
On 26.06.25 17:13, Juergen Gross wrote:
With the related change having been added to Mini-OS, the single V1
patch can now be expanded to a 3 patch series, especially meant to
untangle the close dependencies between grub-pv and Mini-OS internals.
Changes in V2:
- add comment to patch 1
- added pa
On 30.05.2025 15:17, Sergii Dmytruk wrote:
> --- a/xen/arch/x86/include/asm/mm.h
> +++ b/xen/arch/x86/include/asm/mm.h
> @@ -106,6 +106,9 @@
> #define _PGC_need_scrub _PGC_allocated
> #define PGC_need_scrubPGC_allocated
>
> +/* How much of the directmap is prebuilt at compile time. */
> +
On 30.05.2025 15:17, Sergii Dmytruk wrote:
> --- a/xen/arch/x86/include/asm/mm.h
> +++ b/xen/arch/x86/include/asm/mm.h
> @@ -106,6 +106,9 @@
> #define _PGC_need_scrub _PGC_allocated
> #define PGC_need_scrubPGC_allocated
>
> +/* How much of the directmap is prebuilt at compile time. */
> +
All,
we're pleased to announce release of another bug fixing Xen version.
Xen 4.20.1 is available from its git repository
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.20
(tag RELEASE-4.20.1) or from the XenProject download page
https://xenproject.org/resources/downloa
On Wed Jul 9, 2025 at 4:24 PM CEST, Jan Beulich wrote:
> On 08.07.2025 20:07, Alejandro Vallejo wrote:
>> --- a/xen/include/xen/bootfdt.h
>> +++ b/xen/include/xen/bootfdt.h
>> @@ -107,6 +107,10 @@ struct boot_domain {
>> struct boot_module *initrd;
>>
>> const char *cmdline;
>> +
>> +#i
On 07.07.2025 11:01, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/aplic-priv.h
> @@ -0,0 +1,34 @@
> +/* SPDX-License-Identifier: MIT */
> +
> +/*
> + * xen/arch/riscv/aplic-priv.h
> + *
> + * Private part of aplic.h header.
> + *
> + * RISC-V Advanced Platform-Level Interrupt Cont
On 10.07.2025 13:19, Oleksii Kurochko wrote:
> On 7/8/25 3:58 PM, Jan Beulich wrote:
>> On 07.07.2025 11:01, Oleksii Kurochko wrote:
>>> +static struct aplic_priv aplic;
>> Is this altered post-init? IOW can it be __ro_after_init? Or otherwise at
>> least __read_mostly?
>
> Looking at the current
On 7/8/25 3:58 PM, Jan Beulich wrote:
On 07.07.2025 11:01, Oleksii Kurochko wrote:
--- /dev/null
+++ b/xen/arch/riscv/aplic-priv.h
@@ -0,0 +1,34 @@
+/* SPDX-License-Identifier: MIT */
+
+/*
+ * xen/arch/riscv/aplic-priv.h
+ *
+ * Private part of aplic.h header.
+ *
+ * RISC-V Advanced Platform-
On 10.07.2025 03:35, dm...@proton.me wrote:
> @@ -877,6 +873,16 @@ struct domain *domain_create(domid_t domid,
>
> /* All error paths can depend on the above setup. */
>
> +BUILD_BUG_ON(DOMAIN_CONSOLE_BUF_SIZE <= 0);
While the "equals 0" case can in principle happen, the "less than" p
Take care of the multiplication(s) involved in determining overall size
in the macros themselves, saturating to ULONG_MAX. This way on 64-bit
systems the subsequent check against UINT_MAX will fail, while on 32-
bit systems allocations of this size simply cannot be fulfilled anyway
(such an allocat
On 7/8/25 3:52 PM, Jan Beulich wrote:
On 07.07.2025 11:01, Oleksii Kurochko wrote:
imsic_init() is introduced to parse device tree node, which has the following
bindings [2], and based on the parsed information update IMSIC configuration
which is stored in imsic_cfg.
The following helpers are
Jan, I don't mind, you can adjust it.
Please, go ahead.
On 7/10/25 12:44, Dmytro Prokopchuk wrote:
> Yes, sure. I'll update commit message.
> Thanks!
>
> On 7/10/25 11:21, Jan Beulich wrote:
>> On 09.07.2025 23:38, Dmytro Prokopchuk1 wrote:
>>> Address a violation of MISRA C:2012 Rule 5.5:
>>> "I
Yes, sure. I'll update commit message.
Thanks!
On 7/10/25 11:21, Jan Beulich wrote:
> On 09.07.2025 23:38, Dmytro Prokopchuk1 wrote:
>> Address a violation of MISRA C:2012 Rule 5.5:
>> "Identifiers shall be distinct from macro names".
>>
>> Reports for service MC3A2.R5.5:
>> xen/drivers/passthroug
On 09.07.2025 22:12, Volodymyr Babchuk wrote:
> --- a/xen/Kconfig
> +++ b/xen/Kconfig
> @@ -55,6 +55,10 @@ config CC_HAS_ASM_GOTO_OUTPUT
> config CC_HAS_MCDC
> def_bool $(cc-option,-fcondition-coverage)
>
> +# Compiler supports -fprofile-update=atomic for correct SMP handling
> +config CC_
On 09.07.2025 23:38, Dmytro Prokopchuk1 wrote:
> Address a violation of MISRA C:2012 Rule 5.5:
> "Identifiers shall be distinct from macro names".
>
> Reports for service MC3A2.R5.5:
> xen/drivers/passthrough/iommu.c: non-compliant macro 'iommu_quarantine'
> xen/include/xen/iommu.h: non-compliant
On 10.07.2025 03:59, dm...@proton.me wrote:
> On Tue, Jun 24, 2025 at 09:33:04AM +0200, Jan Beulich wrote:
>> On 24.06.2025 09:31, dm...@proton.me wrote:
>>> On Tue, Jun 24, 2025 at 07:50:33AM +0200, Jan Beulich wrote:
On 24.06.2025 05:56, dm...@proton.me wrote:
> From: Denis Mukhin
>
On 10.07.2025 09:02, Roger Pau Monné wrote:
> On Wed, Jul 09, 2025 at 05:44:33PM -0700, Stefano Stabellini wrote:
>> 2) means that the RTOS must be undisturbed when executing the critical
>> section, which is typically right after receiving the interrupt and only
>> last for less than 1ms. In pract
On 10.07.2025 02:35, Stefano Stabellini wrote:
> On Wed, 9 Jul 2025, Jan Beulich wrote:
>>> What fine grained deviation do you have in mind?
>>
>> Ones for almost(?) everything that is having actual code changes right now
>> in this series.
>
> We could easily deviate alternative.c based on the fi
On Wed, Jul 09, 2025 at 05:44:33PM -0700, Stefano Stabellini wrote:
> On Wed, 9 Jul 2025, Jan Beulich wrote:
> > On 08.07.2025 19:11, Stefano Stabellini wrote:
> > > On Tue, 8 Jul 2025, Jan Beulich wrote:
> > >> On 08.07.2025 12:11, Roger Pau Monné wrote:
> > >>> On Mon, Jul 07, 2025 at 05:06:53PM
77 matches
Mail list logo
