On Fri, Oct 24, 2025 at 4:33 AM Andrew Cooper wrote:
>
> The subject should have a "xen: " prefix, as this applies to the
> hypervisor and not other
>
> On 24/10/2025 1:16 am, Saman Dehghan wrote:
> > This change enables compatibility for measuring code coverage
> > with Clang versions 14 through
On 10/24/25 10:51, David Hildenbrand wrote:
> On 24.10.25 16:47, David Woodhouse wrote:
>> On Thu, 2025-10-23 at 22:06 +0200, David Hildenbrand wrote:
>>> On 15.10.25 10:27, Kevin Brodsky wrote:
We currently set a TIF flag when scheduling out a task that is in
lazy MMU mode, in order to r
On 2025-10-21 09:49, Thorsten Blum wrote:
Don't unnecessarily negate 'buffer' and simplify the return statement.
Signed-off-by: Thorsten Blum
Reviewed-by: Jason Andryuk
On 2025-10-23 04:57, Anthony PERARD wrote:
From: Anthony PERARD
If not available, fallback to using YAJL.
The code is using json_c_visit() which was introduced in 0.13.
json_object_new_null() and json_object_new_uint64() where added to
0.14. And the last one json_object_new_array_ext() was int
On 2025-10-23 11:19, Grygorii Strashko wrote:
From: Grygorii Strashko
Functions:
hvm_shadow_handle_cd()
hvm_set_uc_mode()
domain_exit_uc_mode()
are used only by Intel VMX code, so move them under CONFIG_INTEL_VMX ifdef.
Signed-off-by: Grygorii Strashko
Reviewed-by: Jason Andryuk
On 2025-10-23 11:18, Grygorii Strashko wrote:
From: Sergiy Kibrik
Add config option VIRIDIAN that covers viridian code within HVM.
Calls to viridian functions guarded by is_viridian_domain() and related macros.
Having this option may be beneficial by reducing code footprint for systems
that are
On 24/10/2025 7:40 pm, Jason Andryuk wrote:
> On 2025-10-23 11:05, Grygorii Strashko wrote:
>> From: Grygorii Strashko
>>
>> The hvm_set_guest_time() is used only inside vpt.c, so make it static.
>>
>> Signed-off-by: Grygorii Strashko
>
> Reviewed-by: Jason Andryuk
Acked-by: Andrew Cooper
Que
On 2025-10-23 11:05, Grygorii Strashko wrote:
From: Grygorii Strashko
The hvm_set_guest_time() is used only inside vpt.c, so make it static.
Signed-off-by: Grygorii Strashko
Reviewed-by: Jason Andryuk
On 24/10/2025 5:20 pm, Ross Lagerwall wrote:
> If nested vCPU initialization fails, cleanup the allocated memory since
> it is no longer handled by the caller.
>
> Fixes: c47984aabead ("nvmx: implement support for MSR bitmaps")
> Fixes: f5bdb4aaa165 ("x86/hvm: Obsolete the use of HVM_PARAM_NESTEDHV
Thank you Andrew for your prompt clarification.
We'll see what the best we can contribute while developing our coverage
patch.
Thanks,
Saman
On Thu, Oct 23, 2025 at 6:45 PM Andrew Cooper
wrote:
> On 24/10/2025 12:34 am, Saman Dehghan wrote:
> > Hi xen-devel,
> >
> > When preparing and testing a
If nested vCPU initialization fails, cleanup the allocated memory since
it is no longer handled by the caller.
Fixes: c47984aabead ("nvmx: implement support for MSR bitmaps")
Fixes: f5bdb4aaa165 ("x86/hvm: Obsolete the use of HVM_PARAM_NESTEDHVM")
Signed-off-by: Ross Lagerwall
---
xen/arch/x86/h
On 24/10/2025 4:58 pm, Andrew Cooper wrote:
> On 24/10/2025 4:13 pm, Frediano Ziglio wrote:
>> If a SR-IOV card presents an I/O space inside a BAR the
>> code will continue to loop on the same card.
>> This is due to the missing increment of the cycle variable.
>>
>> Signed-off-by: Frediano Ziglio
On 24/10/2025 4:13 pm, Frediano Ziglio wrote:
> If a SR-IOV card presents an I/O space inside a BAR the
> code will continue to loop on the same card.
> This is due to the missing increment of the cycle variable.
>
> Signed-off-by: Frediano Ziglio
Yes, that's buggy. Was this from a real card, or
Hi David,
On Fri, 2025-10-24 at 17:47 +0200, David Hildenbrand wrote:
> > Please have people test kernel changes on SPARC on real hardware. QEMU does
> > not
> > emulate sun4v, for example, and therefore testing in QEMU does not cover all
> > of SPARC hardware.
> >
> > There are plenty of people
On 24.10.25 17:38, John Paul Adrian Glaubitz wrote:
On Fri, 2025-10-24 at 16:13 +0100, David Woodhouse wrote:
On Fri, 2025-10-24 at 16:51 +0200, David Hildenbrand wrote:
On 24.10.25 16:47, David Woodhouse wrote:
On Thu, 2025-10-23 at 22:06 +0200, David Hildenbrand wrote:
On 15.10.25 10:27, Ke
On Fri, 2025-10-24 at 16:13 +0100, David Woodhouse wrote:
> On Fri, 2025-10-24 at 16:51 +0200, David Hildenbrand wrote:
> > On 24.10.25 16:47, David Woodhouse wrote:
> > > On Thu, 2025-10-23 at 22:06 +0200, David Hildenbrand wrote:
> > > > On 15.10.25 10:27, Kevin Brodsky wrote:
> > > > > We curren
Hi Harry,
> On 24 Oct 2025, at 16:37, Harry Ramsey wrote:
>
> From: Harry Ramsey
we will fix the authorship in v2, for now let’s leave this serie to collect the
comments from
the mailing list.
Cheers,
Luca
Hello,
This series aims to further the ongoing work to introduce support for MPU
systems in xen.
The patches in this series implement the logic to map MPU regions.
Thanks,
Harry Ramsey
Harry Ramsey (2):
arm/mpu: Implement setup_mm for MPU systems
arm/mpu: Implement reference counting for ov
Implement reference counting to enable overlapping MPU regions.
References are incremented and decremented in xen_mpumap_update_entry.
A region will be destoryed if the reference count is 0 upon calling
destroy_xen_mappings and if the full region range is specified.
Additionally XEN_MPUMAP_ENTRY_
From: Harry Ramsey
Implement `setup_mm` for MPU systems. This variant does not require
setting up a direct map.
To reduce code duplication the common initalisation code for both MPU
and MMU Arm64 configurations is refactored into `setup_mm`. Platform-specific
setup steps are now handled by a new
Implement the function `ioremap_attr` for MPU systems.
Signed-off-by: Harry Ramsey
---
xen/arch/arm/mpu/mm.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
index c5128244b7..3570ce6b27 100644
--- a/xen/arch/arm/mpu/mm.c
On Fri, 2025-10-24 at 17:05 +0200, Kevin Brodsky wrote:
> On 24/10/2025 16:47, David Woodhouse wrote:
> > On Thu, 2025-10-23 at 22:06 +0200, David Hildenbrand wrote:
> > > On 15.10.25 10:27, Kevin Brodsky wrote:
> > > > We currently set a TIF flag when scheduling out a task that is in
> > > > lazy
On 24.10.25 17:13, David Woodhouse wrote:
On Fri, 2025-10-24 at 16:51 +0200, David Hildenbrand wrote:
On 24.10.25 16:47, David Woodhouse wrote:
On Thu, 2025-10-23 at 22:06 +0200, David Hildenbrand wrote:
On 15.10.25 10:27, Kevin Brodsky wrote:
We currently set a TIF flag when scheduling out a
If a SR-IOV card presents an I/O space inside a BAR the
code will continue to loop on the same card.
This is due to the missing increment of the cycle variable.
Signed-off-by: Frediano Ziglio
---
xen/drivers/passthrough/pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/drivers/passth
On Fri, 2025-10-24 at 16:51 +0200, David Hildenbrand wrote:
> On 24.10.25 16:47, David Woodhouse wrote:
> > On Thu, 2025-10-23 at 22:06 +0200, David Hildenbrand wrote:
> > > On 15.10.25 10:27, Kevin Brodsky wrote:
> > > > We currently set a TIF flag when scheduling out a task that is in
> > > > laz
On 24/10/2025 16:47, David Woodhouse wrote:
> On Thu, 2025-10-23 at 22:06 +0200, David Hildenbrand wrote:
>> On 15.10.25 10:27, Kevin Brodsky wrote:
>>> We currently set a TIF flag when scheduling out a task that is in
>>> lazy MMU mode, in order to restore it when the task is scheduled
>>> again.
On 24/10/2025 16:42, David Hildenbrand wrote:
> On 24.10.25 14:09, Kevin Brodsky wrote:
>> On 23/10/2025 21:36, David Hildenbrand wrote:
>>> On 15.10.25 10:27, Kevin Brodsky wrote:
[...]
diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
b/arch/powerpc/include/asm/b
On 24.10.25 16:47, David Woodhouse wrote:
On Thu, 2025-10-23 at 22:06 +0200, David Hildenbrand wrote:
On 15.10.25 10:27, Kevin Brodsky wrote:
We currently set a TIF flag when scheduling out a task that is in
lazy MMU mode, in order to restore it when the task is scheduled
again.
The generic la
On Thu, 2025-10-23 at 22:06 +0200, David Hildenbrand wrote:
> On 15.10.25 10:27, Kevin Brodsky wrote:
> > We currently set a TIF flag when scheduling out a task that is in
> > lazy MMU mode, in order to restore it when the task is scheduled
> > again.
> >
> > The generic lazy_mmu layer now tracks
On 24.10.25 14:09, Kevin Brodsky wrote:
On 23/10/2025 21:36, David Hildenbrand wrote:
On 15.10.25 10:27, Kevin Brodsky wrote:
[...]
diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
b/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
index 146287d9580f..7704dbe8e88d 100644
--- a
On 24/10/2025 15:23, David Hildenbrand wrote:
+ * currently enabled.
*/
#ifdef CONFIG_ARCH_LAZY_MMU
static inline void lazy_mmu_mode_enable(void)
{
- arch_enter_lazy_mmu_mode();
+ struct lazy_mmu_state *state = ¤t->lazy_mmu_state;
+
+
On 24/10/2025 15:27, David Hildenbrand wrote:
> On 24.10.25 14:13, Kevin Brodsky wrote:
>> On 23/10/2025 21:52, David Hildenbrand wrote:
>>> On 15.10.25 10:27, Kevin Brodsky wrote:
[...]
* madvise_*_pte_range() call arch_leave() in multiple paths, some
followed by an immedia
On 24.10.25 14:13, Kevin Brodsky wrote:
On 23/10/2025 21:52, David Hildenbrand wrote:
On 15.10.25 10:27, Kevin Brodsky wrote:
[...]
* madvise_*_pte_range() call arch_leave() in multiple paths, some
followed by an immediate exit/rescheduling and some followed by a
conditional exit. Thes
On Thu, Oct 23, 2025 at 05:50:17PM +0200, Jan Beulich wrote:
> Using dynamically allocated / maintained vectors has several downsides:
> - possible nesting of IRQs due to the effects of IRQ migration,
> - reduction of vectors available for devices,
> - IRQs not moving as intended if there's shortag
+ * currently enabled.
*/
#ifdef CONFIG_ARCH_LAZY_MMU
static inline void lazy_mmu_mode_enable(void)
{
- arch_enter_lazy_mmu_mode();
+ struct lazy_mmu_state *state = ¤t->lazy_mmu_state;
+
+ VM_BUG_ON(state->count == U8_MAX);
No VM_BUG_ON() please.
I did wonder if this woul
On 24/10/2025 1:54 pm, Teddy Astie wrote:
> Le 24/10/2025 à 14:14, Xen.org security team a écrit :
>> Xen Security Advisory CVE-2025-58149 / XSA-476
>>
>> Incorrect removal of permissions on PCI device unplug
>>
>> ISSUE DESCRIPTION
>> =
>>
>> When passing thr
Le 24/10/2025 à 14:14, Xen.org security team a écrit :
> Xen Security Advisory CVE-2025-58149 / XSA-476
>
> Incorrect removal of permissions on PCI device unplug
>
> ISSUE DESCRIPTION
> =
>
> When passing through PCI devices, the detach logic in libxl won't re
On 23/10/2025 22:02, David Hildenbrand wrote:
> On 15.10.25 10:27, Kevin Brodsky wrote:
>> The generic lazy_mmu layer now tracks whether a task is in lazy MMU
>> mode. As a result we no longer need to track whether the per-CPU TLB
>> batch struct is active - we know it is if in_lazy_mmu_mode() retu
On Thu, Oct 23, 2025 at 05:49:57PM +0200, Jan Beulich wrote:
> Keeping channels enabled when they're unused is only causing problems:
> Extra interrupts harm performance, and extra nested interrupts could even
> have caused worse problems. However, on all Intel hardware I looked at
> closely, a 0->
On 23/10/2025 22:08, David Hildenbrand wrote:
> On 15.10.25 10:27, Kevin Brodsky wrote:
>> The lazy MMU mode cannot be used in interrupt context. This is
>> documented in , but isn't consistently handled
>> across architectures.
>>
>> arm64 ensures that calls to lazy_mmu_mode_* have no effect in
>>
On 23/10/2025 22:10, David Hildenbrand wrote:
> On 15.10.25 10:27, Kevin Brodsky wrote:
>> powerpc decides at runtime whether the lazy MMU mode should be used.
>>
>> To avoid the overhead associated with managing
>> task_struct::lazy_mmu_state if the mode isn't used, introduce
>> arch_wants_lazy_mm
On 23/10/2025 22:00, David Hildenbrand wrote:
> [...]
>
>
>>
>> In summary (count/enabled represent the values *after* the call):
>>
>> lazy_mmu_mode_enable() -> arch_enter() count=1 enabled=1
>> lazy_mmu_mode_enable() -> ø count=2 enabled=1
>> lazy_mmu_mode_pau
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2025-58149 / XSA-476
Incorrect removal of permissions on PCI device unplug
ISSUE DESCRIPTION
=
When passing through PCI devices, the detach logic in libxl won't remove
access permissio
On 23/10/2025 21:52, David Hildenbrand wrote:
> On 15.10.25 10:27, Kevin Brodsky wrote:
>> [...]
>>
>> * madvise_*_pte_range() call arch_leave() in multiple paths, some
>> followed by an immediate exit/rescheduling and some followed by a
>> conditional exit. These functions assume that they a
On 23/10/2025 21:36, David Hildenbrand wrote:
> On 15.10.25 10:27, Kevin Brodsky wrote:
>> [...]
>>
>> diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
>> b/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
>> index 146287d9580f..7704dbe8e88d 100644
>> --- a/arch/powerpc/include/asm
The subject should have a "xen: " prefix, as this applies to the
hypervisor and not other
On 24/10/2025 1:16 am, Saman Dehghan wrote:
> This change enables compatibility for measuring code coverage
> with Clang versions 14 through 20 by supporting their
Stale 14? It looks to be 11 now.
> respec
On 23.10.2025 20:00, Dmytro Prokopchuk1 wrote:
> --- a/xen/arch/arm/efi/efi-boot.h
> +++ b/xen/arch/arm/efi/efi-boot.h
> @@ -227,6 +227,7 @@ static EFI_STATUS __init
> efi_process_memory_map_bootinfo(EFI_MEMORY_DESCRIPTOR *
> }
> }
> #endif
> +/* SAF-15-safe casting
On 24.10.2025 02:16, Saman Dehghan wrote:
> This change enables compatibility for measuring code coverage
> with Clang versions 14 through 20 by supporting their
> respective raw profile formats.
Isn't the 14 here stale now?
> 1- Added support for LLVM raw profile versions 5, 6, 7, 8, 9, and 10.
The following analysis jobs are performed:
- eclair-{x86_64,ARM64}: analyze Xen using the default configuration for
that architecture; runs on runners tagged `eclair-analysis'.
- eclair-{x86-64,ARM64}-safety: analyze Xen using the configuration for
safety, which is more restricted; runs on run
49 matches
Mail list logo
