On 27.03.2025 18:33, Oleksii Kurochko wrote:
> BITS_PER_* values can be defined in a common way using compiler-provided
> macros.
> Thus, these definitions are moved to xen/config.h to reduce duplication across
> architectures.
>
> Additionally, *_BYTEORDER macros are removed, as BITS_PER_* value
On 27/03/2025 4:05 pm, Oleksii Kurochko wrote:
>
>
> On 3/27/25 4:37 PM, Andrew Cooper wrote:
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: Anthony PERARD
>> CC: Michal Orzel
>> CC: Jan Beulich
>> CC: Julien Grall
>> CC: Roger Pau Monné
>> CC: Stefano Stabellini
>> CC: Oleksii Kurochko
>>
>
From: Volodymyr Babchuk
The changes have been tested only on the Renesas R-Car H3 Starter Kit board.
Signed-off-by: Volodymyr Babchuk
Signed-off-by: Oleksandr Andrushchenko
Signed-off-by: Mykola Kvach
---
xen/drivers/char/scif-uart.c | 34 --
1 file changed, 3
From: Mykyta Poturai
Invocation of the CPU_UP_PREPARE notification
on ARM64 during resume causes a crash:
(XEN) [ 315.807606] Error bringing CPU1 up: -16
(XEN) [ 315.811926] Xen BUG at common/cpu.c:258
[...]
(XEN) [ 316.142765] Xen call trace:
(XEN) [ 316.146048][<0a202264>] enab
On 28/03/2025 08:08, Mykola Kvach wrote:
>
>
> From: Volodymyr Babchuk
>
> The changes have been tested only on the Renesas R-Car H3 Starter Kit board.
>
> Signed-off-by: Volodymyr Babchuk
> Signed-off-by: Oleksandr Andrushchenko
> Signed-off-by: Mykola Kvach
I'm afraid that without a su
On 3/28/25 8:59 AM, Andrew Cooper wrote:
On 27/03/2025 4:05 pm, Oleksii Kurochko wrote:
On 3/27/25 4:37 PM, Andrew Cooper wrote:
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Oleksii
On 3/28/25 8:49 AM, Jan Beulich wrote:
On 27.03.2025 18:33, Oleksii Kurochko wrote:
BITS_PER_* values can be defined in a common way using compiler-provided macros.
Thus, these definitions are moved to xen/config.h to reduce duplication across
architectures.
Additionally, *_BYTEORDER macros ar
On 28/03/2025 7:49 am, Jan Beulich wrote:
> On 27.03.2025 18:33, Oleksii Kurochko wrote:
>> BITS_PER_* values can be defined in a common way using compiler-provided
>> macros.
>> Thus, these definitions are moved to xen/config.h to reduce duplication
>> across
>> architectures.
>>
>> Additionally
Hi Michal,
On 28/03/2025 08:39, Orzel, Michal wrote:
On 28/03/2025 08:08, Mykola Kvach wrote:
From: Volodymyr Babchuk
The changes have been tested only on the Renesas R-Car H3 Starter Kit board.
Signed-off-by: Volodymyr Babchuk
Signed-off-by: Oleksandr Andrushchenko
Signed-off-by: Myko
On 27/03/2025 5:33 pm, Oleksii Kurochko wrote:
> As Anrew mentioned here
> https://lore.kernel.org/xen-devel/f294e2b1-db03-46b2-b46d-61e89b55c...@suse.com/T/#ma4205392964ff913d9dfa8e044a4af59ed6aef88:
> "This patch possibly wants to wait until I've fixed the compiler checks to
> update to the n
Hi,
On Fri, Mar 21, 2025 at 10:25 AM Bertrand Marquis
wrote:
>
> Hi Jens,
>
> > On 21 Mar 2025, at 09:55, Jens Wiklander wrote:
> >
> > Hi Bertrand,
> >
> > On Mon, Mar 10, 2025 at 3:51 PM Bertrand Marquis
> > wrote:
> >>
> >> When VM to VM support is activated and there is no suitable FF-A sup
From: Arnd Bergmann
Modules without a description now cause a warning:
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/xen/xenbus/xenbus_probe_frontend.o
Signed-off-by: Arnd Bergmann
---
v2: change the description as suggested by Jürgen
---
drivers/xen/xenbus/xenbus_probe_frontend.
Hi Andrew,
Andrew Cooper writes:
> On 27/03/2025 10:03 pm, Volodymyr Babchuk wrote:
>> Hi Jan,
>>
>> Jan Beulich writes:
>>
>>> On 27.03.2025 01:40, Volodymyr Babchuk wrote:
GCC 14.1 has 9 gcov counters and also can call new merge function
__gcov_merge_ior(), so we need a new stub f
While building xen with GCC 14.2.1 with "-fcondition-coverage" option,
the compiler produces a false positive warning:
arch/x86/irq.c: In function ‘create_irq’:
arch/x86/irq.c:281:11: error: ‘desc’ may be used uninitialized
[-Werror=maybe-uninitialized]
281 | ret = init_one_irq_desc(d
On 28.03.2025 11:51, Anthony PERARD wrote:
> On Thu, Mar 27, 2025 at 02:32:04PM +0100, Jan Beulich wrote:
>> HWP work made the cleanup of the "available governors" array
>> conditional, neglecting the fact that the condition used may not be the
>
> I don't know why the cleanup was made conditional
On Fri, 28 Mar 2025, Jan Beulich wrote:
> >>> + copy_to_guest(xenctl_bitmap->bitmap, bytemap, copy_bytes -
> >>> 1) )
> >>> +err = -EFAULT;
> >>> +
> >>> +xfree(bytemap);
> >>> +}
> >>> +else
> >>> +{
> >>> +const uint8_t *bytemap = (const uint8_
Hi Jan,
I am not very familiar with CC_SPLIT_SECTIONS. But I will try to answer
the Arm questions.
On 13/03/2025 08:10, Jan Beulich wrote:
Leverage the new infrastructure in xen/linkage.h to also switch to per-
function sections (when configured), deriving the specific name from the
"base" se
We now have compiler types for every standard type we use.
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
---
xen/include/xen/stdint.h | 19 ---
xen/include/xen/types.h | 3 +
When booting from U-Boot bootefi, there can be a high number of
neighboring RAM banks. See for example:
(XEN) RAM: - 00bf
(XEN) RAM: 00c0 - 00c00fff
(XEN) RAM: 00c01000 - 00df
(XEN) RAM: 00e0 - 0279dfff
(XEN)
Hi Jens,
> On 21 Mar 2025, at 11:09, Jens Wiklander wrote:
>
> Hi,
>
> On Fri, Mar 21, 2025 at 10:25 AM Bertrand Marquis
> wrote:
>>
>> Hi Jens,
>>
>>> On 21 Mar 2025, at 09:55, Jens Wiklander wrote:
>>>
>>> Hi Bertrand,
>>>
>>> On Mon, Mar 10, 2025 at 3:51 PM Bertrand Marquis
>>> wrote:
On 28/03/2025 1:44 pm, Andrew Cooper wrote:
> From: Lin Liu
>
> These wrappers simply hide a deference, which adds to the cognitive complexity
> of reading the code. As such, they're not going to be included in the new
> byteswap infrastructure.
>
> No functional change.
>
> Signed-off-by: Lin Li
By default, the `aia` option is set to "none" which selects the SiFive PLIC for
handling wired interrupts. However, since PLIC is now considered obsolete and
will not be supported by Xen now, APLIC and IMSIC are selected instead to manage
both wired interrupts and MSIs.
Signed-off-by: Oleksii Kuro
Hi Jan,
On 13/03/2025 08:07, Jan Beulich wrote:
Locally override SYM_PUSH_SECTION() to retain the intended section
association.
Signed-off-by: Jan Beulich
Tested-by: Luca Fancellu # arm
---
v7: New.
--- a/xen/arch/arm/arm32/mmu/head.S
+++ b/xen/arch/arm/arm32/mmu/head.S
@@ -160,6 +160,13 @@
Hi Jan,
On 13/03/2025 08:06, Jan Beulich wrote:
No functional change, albeit all globals now become hidden, and aliasing
symbols (__aeabi_{u,}idiv) lose their function-ness and size.
Signed-off-by: Jan Beulich
Tested-by: Luca Fancellu # arm
Acked-by: Julien Grall
Cheers,
--
Julien Grall
On Fri, 2025-03-21 at 18:42 +, David Woodhouse wrote:
> On Fri, 2025-03-21 at 14:32 -0400, Michael S. Tsirkin wrote:
> > On Fri, Mar 21, 2025 at 03:38:10PM +, David Woodhouse wrote:
> > > On Tue, 2021-02-09 at 14:21 +0800, Claire Chang wrote:
> > > > This series implements mitigations for l
Hi Jan,
On 13/03/2025 08:08, Jan Beulich wrote:
Locally override SYM_PUSH_SECTION() to retain the intended section
association.
Signed-off-by: Jan Beulich
Tested-by: Luca Fancellu # arm
---
v8: Re-base.
v7: New.
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -48,13 +48,20
Hi Jan,
On 13/03/2025 08:08, Jan Beulich wrote:
Locally override SYM_PUSH_SECTION() to retain the intended section
association.
Signed-off-by: Jan Beulich
Tested-by: Luca Fancellu # arm
---
v8: Re-base.
v7: New.
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -48,13 +48,20
On 28.03.2025 13:19, Volodymyr Babchuk wrote:
> gcc 14 (with patch "Add condition coverage (MC/DC)") introduced 9th
> gcov counter. Also this version can call new merge function
> __gcov_merge_ior(), so we need a new stub for it.
>
> Signed-off-by: Volodymyr Babchuk
Reviewed-by: Jan Beulich
On Fri, Mar 28, 2025 at 12:19:18PM +, Volodymyr Babchuk wrote:
> Condition coverage, also known as MC/DC (modified condition/decision
> coverage) is a coverage metric that tracks separate outcomes in
> boolean expressions.
>
> This patch adds CONFIG_CONDITION_COVERAGE option to enable MC/DC fo
Introduce preinitialization stuff for the RISC-V Advanced Platform-Level
Interrupt Controller (APLIC) in Xen:
- Implementing the APLIC pre-initialization function (`aplic_preinit()`),
ensuring that only one APLIC instance is supported in S mode.
- Initialize APLIC's correspoinding DT node.
-
Currently, only the device tree method is available to locate and perform
pre-initialization steps for the interrupt controller (at the moment, only
one interrupt controller is going to be supported). When `acpi_disabled`
is true, the system will scan for a node with the "interrupt-controller"
prop
preinit_xen_time() does two things:
1. Parse timebase-frequency properpy of /cpus node to initialize cpu_khz
variable.
2. Initialize boot_clock_cycles with the current time counter value to
have starting point for Xen.
timebase-frequency is read as a uint32_t because it is unlikely that the
On 28.03.2025 00:33, Stefano Stabellini wrote:
> On Mon, 24 Mar 2025, Jan Beulich wrote:
>> On 22.03.2025 00:09, Stefano Stabellini wrote:
>>> @@ -384,21 +382,40 @@ int bitmap_to_xenctl_bitmap(struct xenctl_bitmap
>>> *xenctl_bitmap,
>>> uint8_t zero = 0;
>>> int err = 0;
>>> unsign
On 28.03.2025 13:19, Volodymyr Babchuk wrote:
> Condition coverage, also known as MC/DC (modified condition/decision
> coverage) is a coverage metric that tracks separate outcomes in
> boolean expressions.
>
> This patch adds CONFIG_CONDITION_COVERAGE option to enable MC/DC for
> GCC. Clang is not
With the common code moved fully onto xen/byteorder.h, clean up the dregs.
The use of byteorder.h in io.h appears to have been copy&paste from ARM. It's
not needed, but macros and types are.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Be
On Thu, Mar 27, 2025 at 05:43:02PM +, Andrew Cooper wrote:
> The $(eval $(check-y)) is badly positioned:
>
> xen.git/xen$ make
> *** FATAL BUILD ERROR: Xen requires at least GCC 0x150100
> *** FATAL BUILD ERROR: Xen requires at least GCC 0x150100
> *** FATAL BUILD ERROR: Xen requires a
Condition coverage, also known as MC/DC (modified condition/decision
coverage) is a coverage metric that tracks separate outcomes in
boolean expressions.
This patch adds CONFIG_CONDITION_COVERAGE option to enable MC/DC for
GCC. Clang is not supported right now.
Signed-off-by: Volodymyr Babchuk
On 28.03.25 12:32, Arnd Bergmann wrote:
From: Arnd Bergmann
Modules without a description now cause a warning:
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/xen/xenbus/xenbus_probe_frontend.o
Signed-off-by: Arnd Bergmann
Reviewed-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9D
gcc 14 (with patch "Add condition coverage (MC/DC)") introduced 9th
gcov counter. Also this version can call new merge function
__gcov_merge_ior(), so we need a new stub for it.
Signed-off-by: Volodymyr Babchuk
---
Changes is v2:
- Check for gcc 14, not gcc 14.1
---
xen/common/coverage/gcc_4_
This series enables MC/DC for Xen when building with GCC.
Condition coverage, also known as MC/DC (modified condition/decision
coverage) is a coverage metric that tracks separate outcomes in
boolean expressions. This metric is used in critical software
components, so it natural to collect it for X
From: Teddy Astie Sent: Thursday, March 27, 2025 7:12
AM
> To: linux-ker...@vger.kernel.org; linux...@vger.kernel.org
> Cc: Xen-devel
> Subject: Allocating SEV C-bit-cleared pages (without relying on swiotlb)
>
> Hello Linux mailing list !
>
> For porting Linux code to make it work on Xen with
On 28/03/2025 2:05 pm, Anthony PERARD wrote:
> On Thu, Mar 27, 2025 at 05:43:02PM +, Andrew Cooper wrote:
>> The $(eval $(check-y)) is badly positioned:
>>
>> xen.git/xen$ make
>> *** FATAL BUILD ERROR: Xen requires at least GCC 0x150100
>> *** FATAL BUILD ERROR: Xen requires at least GCC
From: Lin Liu
These wrappers simply hide a deference, which adds to the cognitive complexity
of reading the code. As such, they're not going to be included in the new
byteswap infrastructure.
No functional change.
Signed-off-by: Lin Liu
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC
The diffstat speaks for itself.
This is a follow-up to Lin's years-old series, rebased to account for RISC-V
and PPC, and simplified owing to our new compiler baseline.
Andrew Cooper (8):
xen/lzo: Remove more remanants of TMEM
xen: Remove __{BIG,LITTLE}_ENDIAN_BITFIELD
xsm/flask: Switch {as
From: Lin Liu
unaligned.h already inlcudes byteorder.h, so most can simply be dropped.
No functional change.
Signed-off-by: Lin Liu
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Volodymyr Babchuk
CC: Bertrand Marq
From: Lin Liu
In divmod.c, additionally swap xen/lib.h for xen/macros.h as only ABS() is
needed.
In find-next-bit.c, ext2 has nothing to do with this logic. Despite the
comments, it was a local modification when the logic was imported from Linux,
because Xen didn't have a suitable helper.
The
From: Lin Liu
The current swab??() infrastructure is unecesserily complicated, and can be
repated entirely with compiler builtins.
All supported compilers provide __BYTE_ORDER__ and __builtin_bswap??().
Nothing in Xen cares about the values of __{BIG,LITTLE}_ENDIAN; just that one
of them is def
From: Lin Liu
It is no longer used.
Signed-off-by: Lin Liu
Reviewed-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Shawn Anastasio
CC: Oleksii Kurochko
From: Lin Liu
This needs to be done in several steps, because of common vs arch issues.
Start by using the new common infastructure inside the arch infrastructure.
libelf-private.h is awkward, and the only thing in Xen using swabXX()
directly. It needs updating at the same time.
Signed-off-by:
From: Lin Liu
These wrappers simply hide a deference, which adds to the cognitive complexity
of reading the code. As such, they're not going to be included in the new
byteswap infrastructure.
No functional change.
Signed-off-by: Lin Liu
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC
Sort the includes while at it.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Shawn Anastasio
CC: Oleksii Kurochko
CC:
With the common code moved fully onto xen/byteorder.h, clean up the dregs.
Sort includes in some files while swapping over to xen/byteorder.h.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC:
From: Lin Liu
This file has its own implementation of swap bytes. Clean up
the code with xen/byteswap.h.
No functional change.
Signed-off-by: Lin Liu
Acked-by: Jan Beulich
Reviewed-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Mo
There is a singular user. It's unlikely we'll gain a big-endian build of Xen,
but it's far more unlikely that bitfields will differ from main endianness.
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Sta
Sort the includes. Drop useless includes of xen/types.h
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Shawn Anastasio
CC: Oleksii Kurochko
C
With the common code moved fully onto xen/byteorder.h, clean up the dregs.
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Shawn Anastasio
CC: O
On 28.03.2025 13:19, Volodymyr Babchuk wrote:
> While building xen with GCC 14.2.1 with "-fcondition-coverage" option,
> the compiler produces a false positive warning:
>
> arch/x86/irq.c: In function ‘create_irq’:
> arch/x86/irq.c:281:11: error: ‘desc’ may be used uninitialized
> [-Werror=ma
[Public]
Hi,
> -Original Message-
> From: Jan Beulich
> Sent: Tuesday, March 25, 2025 3:54 PM
> To: Penny, Zheng
> Cc: Huang, Ray ; Andrew Cooper
> ; Roger Pau Monné ;
> Anthony PERARD ; Orzel, Michal
> ; Julien Grall ; Stefano Stabellini
> ; xen-devel@lists.xenproject.org
> Subject: Re
On Wed, 26 Mar 2025, Penny Zheng wrote:
> We intend to remove all "depends on !PV_SHIM_EXCLUSIVE" (also the functionally
> equivalent "if !...") in Kconfig file, since negative dependancy will badly
> affect allyesconfig.
> This commit is based on "x86: provide an inverted Kconfig control for
> shi
On Wednesday, March 26th, 2025 at 6:44 AM, Jan Beulich
wrote:
>
>
> On 19.03.2025 00:36, dm...@proton.me wrote:
>
> > @@ -564,10 +586,25 @@ static void __serial_rx(char c)
> > /* Deliver input to the PV shim console. */
> > rc = consoled_guest_tx(c);
> >
> > - if ( rc )
> > + switch ( rc )
> > +
On Wed, 26 Mar 2025, Penny Zheng wrote:
> 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
On Wed, 26 Mar 2025, Penny Zheng wrote:
> The following functions are only used to deal with XEN_SYSCTL_physinfo,
> then they shall be wrapped:
> - arch_do_physinfo
> - get_outstanding_claims
>
> Signed-off-by: Penny Zheng
Reviewed-by: Stefano Stabellini
On Wed, 26 Mar 2025, Penny Zheng wrote:
> Function avail_domheap_pages() is only invoked by get_outstanding_claims(),
> so it could be inlined into its sole caller.
> Move up avail_heap_pages() to avoid declaration before
> get_outstanding_claims().
>
> Signed-off-by: Penny Zheng
Reviewed-by: St
On Wed, 26 Mar 2025, Penny Zheng wrote:
> The following function is only to serve spinlock profiling via
> XEN_SYSCTL_lockprof_op, so it shall be wrapped:
> - spinlock_profile_control
>
> Signed-off-by: Penny Zheng
Reviewed-by: Stefano Stabellini
On Wed, 26 Mar 2025, Penny Zheng wrote:
> perfc_control() and perfc_copy_info() are responsible for providing control
> of perf counters via XEN_SYSCTL_perfc_op in DOM0, so they both shall
> be wrapped.
>
> Signed-off-by: Penny Zheng
Reviewed-by: Stefano Stabellini
On Wed, 26 Mar 2025, Penny Zheng wrote:
> We intend to introduce CONFIG_PM_STATS for wrapping all operations
> regarding performance management statistics.
> The major codes reside in xen/drivers/acpi/pmstat.c, including two main
> pm-related sysctl op: do_get_pm_info() and do_pm_op().
> So This co
On Wed, 26 Mar 2025, Penny Zheng wrote:
> We intend to move the following functions into drivers/acpi/pmstat.c, as they
> are all designed for performance statistic:
> - cpufreq_residency_update
> - cpufreq_statistic_reset
> - cpufreq_statistic_update
> - cpufreq_statistic_init
> - cpufreq_statisti
On Wed, 26 Mar 2025, Penny Zheng wrote:
> 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
On Wed, 26 Mar 2025, Penny Zheng wrote:
> 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
Hi,
On 27/03/2025 17:33, Oleksii Kurochko wrote:
BITS_PER_* values can be defined in a common way using compiler-provided macros.
Thus, these definitions are moved to xen/config.h to reduce duplication across
architectures.
Additionally, *_BYTEORDER macros are removed, as BITS_PER_* values now
Dear Xen Community,
I hope this message finds you well.
I have heard that there exists a minimal Xen configuration optimized for
safety-critical products, particularly in automotive applications, with the
code size reduced to approximately 50k SLOC.
Could anyone provide guidance or point me to
On 28/03/2025 09:13, Orzel, Michal wrote:
On 28/03/2025 09:57, Julien Grall wrote:
Hi Michal,
On 28/03/2025 08:39, Orzel, Michal wrote:
On 28/03/2025 08:08, Mykola Kvach wrote:
From: Volodymyr Babchuk
The changes have been tested only on the Renesas R-Car H3 Starter Kit board.
S
On 27/03/2025 5:33 pm, Oleksii Kurochko wrote:
> diff --git a/xen/include/xen/config.h b/xen/include/xen/config.h
> index d888b2314d..7d43159efb 100644
> --- a/xen/include/xen/config.h
> +++ b/xen/include/xen/config.h
> @@ -98,4 +98,14 @@
> #define ZERO_BLOCK_PTR ((void *)-1L)
> #endif
>
> +#de
On Thu, Mar 27, 2025 at 02:32:04PM +0100, Jan Beulich wrote:
> HWP work made the cleanup of the "available governors" array
> conditional, neglecting the fact that the condition used may not be the
I don't know why the cleanup was made conditional, as long as the bounce
buffer is declared with DEC
hi, Thomas Gleixner,
On Thu, Mar 27, 2025 at 01:03:46PM +0100, Thomas Gleixner wrote:
> On Thu, Mar 27 2025 at 16:29, kernel test robot wrote:
> > kernel test robot noticed "Kernel_panic-not_syncing:Fatal_exception" on:
> >
> > commit: d9f2164238d814d119e8c979a3579d1199e271bb ("PCI/MSI: Convert
>
On 28.03.2025 05:07, Penny, Zheng wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: Tuesday, March 25, 2025 6:49 PM
>>
>> On 06.03.2025 09:39, Penny Zheng wrote:
>>> @@ -261,7 +276,20 @@ static int cf_check amd_cppc_cpufreq_target(struct
>> cpufreq_policy *policy,
>>> ret
On 27.03.2025 18:43, Andrew Cooper wrote:
> We have checks in both xen/compiler.h, and Config.mk. Both are incomplete.
>
> The check in Config.mk sees $(CC) in system and cross-compiler form, so cannot
> express anything more than the global baseline. Change it to simply 5.1.
>
> In xen/compile
The lazy MMU batching may be only be entered and left under the
protection of the page table locks for all page tables which may
be modified. Yet, there were cases arch_enter_lazy_mmu_mode()
was called without the locks taken, e.g. commit b9ef323ea168
("powerpc/64s: Disable preemption in hash lazy
The lazy MMU mode can only be entered and left under the protection
of the page table locks for all page tables which may be modified.
Yet, when it comes to kernel mappings apply_to_pte_range() does not
take any locks. That does not conform arch_enter|leave_lazy_mmu_mode()
semantics and could poten
On 28/03/2025 09:57, Julien Grall wrote:
>
>
> Hi Michal,
>
> On 28/03/2025 08:39, Orzel, Michal wrote:
>>
>>
>> On 28/03/2025 08:08, Mykola Kvach wrote:
>>>
>>>
>>> From: Volodymyr Babchuk
>>>
>>> The changes have been tested only on the Renesas R-Car H3 Starter Kit board.
>>>
>>> Signed-of
On 28.03.2025 09:27, Penny, Zheng wrote:
> [Public]
>
> Hi,
>
>> -Original Message-
>> From: Jan Beulich
>> Sent: Tuesday, March 25, 2025 3:54 PM
>> To: Penny, Zheng
>> Cc: Huang, Ray ; Andrew Cooper
>> ; Roger Pau Monné ;
>> Anthony PERARD ; Orzel, Michal
>> ; Julien Grall ; Stefano St
Hi All!
On s390 if make arch_enter_lazy_mmu_mode() do preempt_enable() and
arch_leave_lazy_mmu_mode() do preempt_disable() I am getting this:
[ 553.332108] preempt_count: 1, expected: 0
[ 553.332117] no locks held by multipathd/2116.
[ 553.332128] CPU: 24 PID: 2116 Comm: multipathd
apply_to_page_range() enters lazy MMU mode and then invokes
kasan_populate_vmalloc_pte() callback on each page table walk
iteration. The lazy MMU mode may only be entered only under
protection of the page table lock. However, the callback can
go into sleep when trying to allocate a single page.
Ch
Reverse 'create' vs 'mm == &init_mm' conditions and move
page table mask modification out of the atomic context.
Signed-off-by: Alexander Gordeev
---
mm/memory.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index fb7
With the common code moved fully onto xen/byteorder.h, clean up the dregs.
It turns out that msi.h has not needed byteorder.h since the use of
__{BIG,LITTLE}_ENDIAN_BITFIELD was dropped in commit d58f3941ce3f ("x86/MSI:
use standard C types in structures/unions").
No functional change.
Signed-of
This logic was inserted by commit 447f613c5404 ("lzo: update LZO compression
to current upstream version") but was only relevant for the TMEM logic, so
should have been deleted in commit c492e19fdd05 ("xen: remove tmem from
hypervisor")
Fixes: c492e19fdd05 ("xen: remove tmem from hypervisor")
Sign
In a 64bit-clean environment, blowfish fails:
make[6]: Leaving directory
'/builddir/build/BUILD/xen-4.19.1/tools/tests/x86_emulator'
In file included from /usr/include/features.h:535,
from /usr/include/bits/libc-header-start.h:33,
from /usr/include/stdin
Le 28/03/2025 à 17:31, Michael Kelley a écrit :
> From: Teddy Astie Sent: Thursday, March 27, 2025
> 7:12 AM
>> To: linux-ker...@vger.kernel.org; linux...@vger.kernel.org
>> Cc: Xen-devel
>> Subject: Allocating SEV C-bit-cleared pages (without relying on swiotlb)
>>
>> Hello Linux mailing list !
88 matches
Mail list logo
