On 7/25/25 5:07 PM, Edwin Török wrote:
> diff --git a/xen/arch/x86/cpu/vpmu_amd.c b/xen/arch/x86/cpu/vpmu_amd.c
> index a6117dfebf..024d0c1eb7 100644
> --- a/xen/arch/x86/cpu/vpmu_amd.c
> +++ b/xen/arch/x86/cpu/vpmu_amd.c
> @@ -543,7 +543,7 @@ static const struct arch_vpmu_ops *__init
> common_in
[Public]
> -Original Message-
> From: Jan Beulich
> Sent: Monday, August 4, 2025 4:48 PM
> To: Penny, Zheng
> Cc: Huang, Ray ; Andrew Cooper
> ; Anthony PERARD ;
> Orzel, Michal ; Julien Grall ; Roger Pau
> Monné ; Stefano Stabellini ;
> xen-
> de...@lists.xenproject.org
> Subject: Re:
The purpose of this patch is to allow the Xen hypervisor to pass extra
data to GRUB in the form of a kernel command line, allowing the host to
customize the boot process of the guest. The command line from Xen is
parsed, and any variables within that start with the string
`xen_grub_env_` are expose
Xen traditionally allows customizing guest behavior by passing arguments
to the VM kernel via the kernel command line. This is no longer possible
when using GRUB with Xen, as the kernel command line is decided by the
GRUB configuration file within the guest, not data passed to the guest
by Xen.
To
The xen.h header was using an overly generic name to refer to the
maximum length of the command line passed from Xen to a guest. Rename it
to avoid confusion or conflicts in the future.
Signed-off-by: Aaron Rainbolt
---
include/xen/xen.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
When init_msi() fails, current logic return fail and free MSI-related
resources in vpci_deassign_device(). But the previous new changes will
hide MSI capability and return success, it can't reach
vpci_deassign_device() to remove resources if hiding success, so those
resources must be removed in cle
vpci_remove_register() only supports removing a register in a time,
but the follow-on changes need to remove all registers within a range.
So, refactor it to support removing all registers in a given region.
And it is no issue to remove a non exist register, so remove the
__must_check prefix.
Not
[Public]
> -Original Message-
> From: Jan Beulich
> Sent: Monday, August 4, 2025 3:43 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: [PAT
When MSI-X initialization fails vPCI will hide the capability, but
remove of handlers and data won't be performed until the device is
deassigned. Introduce a MSI-X cleanup hook that will be called when
initialization fails to cleanup MSI-X related hooks and free it's
associated data.
As all suppo
When init_rebar() fails, current logic return fail and free Rebar-related
resources in vpci_deassign_device(). But the previous new changes will
hide Rebar capability and return success, it can't reach
vpci_deassign_device() to remove resources if hiding success, so those
resources must be removed
Hi,
This series is to
emulate extended capability list for dom0;
hide legacy and extended capability when its initialization fails;
above two parts had been merged.
remove all related registers and other resources when initializing capability
fails, including patch #1, #2, #3, #4.
Best regards,
+ Cc: Oleskii
On Mon, Aug 04, 2025 at 11:46:36AM +0200, Jan Beulich wrote:
> On 31.07.2025 21:21, dm...@proton.me wrote:
> > --- a/xen/include/xen/sched.h
> > +++ b/xen/include/xen/sched.h
> > @@ -652,6 +652,8 @@ struct domain
> > unsigned int *llc_colors;
> > #endif
> >
> > +uint32_t em
On Mon, Aug 04, 2025 at 09:13:07AM +0200, Jan Beulich wrote:
> On 01.08.2025 21:30, dm...@proton.me wrote:
> > On Fri, Aug 01, 2025 at 08:02:56AM +0200, Jan Beulich wrote:
> >> On 31.07.2025 22:55, dm...@proton.me wrote:
> >>> On Wed, Jul 09, 2025 at 04:57:44PM +0200, Jan Beulich wrote:
> On 2
On 8/3/25 09:19, Andrew Cooper wrote:
> On 01/08/2025 9:24 pm, Stewart Hildebrand wrote:
>> In vcpu_create after scheduler data is allocated, if
>> vmtrace_alloc_buffer fails, it will jump to the wrong cleanup label
>> resulting in a memory leak.
>>
>> Move sched_destroy_vcpu and destroy_waitqueue_
On Mon, Aug 04, 2025 at 09:10:34AM +0200, Jan Beulich wrote:
> On 01.08.2025 20:58, dm...@proton.me wrote:
> > On Fri, Aug 01, 2025 at 09:30:34AM +0200, Jan Beulich wrote:
> >> Them not being altered by any means, their __read_mostly attribute is
> >> actually counter-productive: It causes the comp
On Mon, 4 Aug 2025 17:17:43 +0200
Daniel Kiper wrote:
> On Sun, Aug 03, 2025 at 10:57:03AM -0500, Aaron Rainbolt wrote:
> > On Fri, 1 Aug 2025 14:55:36 +0200 Daniel Kiper
> > wrote:
> > > On Fri, Jul 25, 2025 at 03:31:12PM -0500, Aaron Rainbolt wrote:
> > > > Xen traditionally allows customi
Hi everyone,
We’re getting ready for August's Xen Project Community Call on *Thursday, 7
August 2025* at *15:00 UTC* (4 pm UK time). We’d love for you to join. Feel
free to participate or just observe. This call is a great opportunity to
see what the community is working on, align our various effo
MISRA Rule 16.4: Every switch statement shall have a default label.
The default clause must contain either a statement or a comment
prior to its terminating break statement.
However, there is a documented deviation for this rule in Xen:
'docs/misra/deviations.rst':
* - R16.4
- A switch statement
On 8/4/25 03:57, Jan Beulich wrote:
> On 01.08.2025 22:24, Stewart Hildebrand wrote:
>> @@ -839,6 +839,9 @@ void sched_destroy_vcpu(struct vcpu *v)
>> {
>> struct sched_unit *unit = v->sched_unit;
>>
>> +if ( !unit )
>> +return;
>> +
>> kill_timer(&v->periodic_timer);
>>
On 31.07.2025 17:58, Oleksii Kurochko wrote:
> Implement p2m_set_allocation() to construct p2m pages pool for guests
> based on required number of pages.
>
> This is implemented by:
> - Adding a `struct paging_domain` which contains a freelist, a
> counter variable and a spinlock to `struct arch
On 31.07.2025 17:58, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/include/asm/p2m.h
> +++ b/xen/arch/riscv/include/asm/p2m.h
> @@ -3,11 +3,45 @@
> #define ASM__RISCV__P2M_H
>
> #include
> +#include
> +#include
> +#include
>
> #include
>
> #define paddr_bits PADDR_BITS
>
> +/* Get
While the logic there covers asymmetric cases, the resulting log
messages would likely raise more confusion than clarify anything. Split
the BSP action from the AP one, indicating the odd CPU in the AP log
message, thus avoiding the impression that global state would have
changed.
While there also
On Thu, Jul 31, 2025 at 06:28:14AM +, Chen, Jiqian wrote:
> On 2025/7/30 19:23, Andrew Cooper wrote:
> > On 28/07/2025 6:03 am, Jiqian Chen wrote:
> >> vpci_remove_register() only supports removing a register in a time,
> >> but the follow-on changes need to remove all registers within a range.
On 8/1/25 12:08 PM, Grygorii Strashko wrote:
From: Grygorii Strashko
Hence all common pIRQ code is under CONFIG_HAS_PIRQ idefs corresponding
RISCV arch pIRQ callbacks become unreachable, so drop them.
Signed-off-by: Grygorii Strashko
---
xen/arch/riscv/stubs.c | 20
1 f
On 31.07.2025 17:58, Oleksii Kurochko wrote:
> Current implementation is based on x86's way to allocate VMIDs:
> VMIDs partition the physical TLB. In the current implementation VMIDs are
> introduced to reduce the number of TLB flushes. Each time the guest's
> virtual address space changes,
On Sun, Aug 03, 2025 at 10:57:03AM -0500, Aaron Rainbolt wrote:
> On Fri, 1 Aug 2025 14:55:36 +0200 Daniel Kiper wrote:
> > On Fri, Jul 25, 2025 at 03:31:12PM -0500, Aaron Rainbolt wrote:
> > > Xen traditionally allows customizing guest behavior by passing
> > > arguments to the VM kernel via the
On Mon, Aug 04, 2025 at 03:57:24PM +0200, Jan Beulich wrote:
> On 04.08.2025 15:55, Roger Pau Monné wrote:
> > On Fri, Aug 01, 2025 at 05:06:32PM -0400, Stewart Hildebrand wrote:
> >> On 7/25/25 03:58, Roger Pau Monné wrote:
> >>> On Thu, Jul 24, 2025 at 06:44:32PM +0200, Roger Pau Monné wrote:
> >
On 31.07.2025 17:58, Oleksii Kurochko wrote:
> - Extended p2m_type_t with additional types: p2m_mmio_direct,
> p2m_grant_map_{rw,ro}.
> - Added macros to classify memory types: P2M_RAM_TYPES, P2M_GRANT_TYPES.
> - Introduced helper predicates: p2m_is_ram(), p2m_is_any_ram().
> - Define p2m_mmio_di
On 31.07.2025 17:58, Oleksii Kurochko wrote:
> Rename `p2m_mmio_direct_dev` to a more architecture-neutral alias
> `p2m_mmio_direct` to avoid leaking Arm-specific naming into common Xen code,
> such as dom0less passthrough property handling.
>
> This helps reduce platform-specific terminology in s
Hi Michal,
On 29/07/2025 10:22, Orzel, Michal wrote:
> On 28/07/2025 19:07, Oleksii Moisieiev wrote:
>> This commit introduces a new Kconfig option, `CONFIG_DOM0_BOOT`, to
>> allow for building Xen without support for booting a regular domain (Dom0).
>> This functionality is primarily intended for
On 30/07/2025 01:10, dm...@proton.me wrote:
> On Tue, Jul 29, 2025 at 10:20:54AM +0200, Jan Beulich wrote:
>> On 28.07.2025 23:28, dm...@proton.me wrote:
>>> On Mon, Jul 28, 2025 at 05:07:30PM +, Oleksii Moisieiev wrote:
This commit introduces a new Kconfig option, `CONFIG_DOM0_BOOT`, to
On 04.08.2025 15:55, Roger Pau Monné wrote:
> On Fri, Aug 01, 2025 at 05:06:32PM -0400, Stewart Hildebrand wrote:
>> On 7/25/25 03:58, Roger Pau Monné wrote:
>>> On Thu, Jul 24, 2025 at 06:44:32PM +0200, Roger Pau Monné wrote:
On Wed, Jul 23, 2025 at 12:37:41PM -0400, Stewart Hildebrand wrote:
On Fri, Aug 01, 2025 at 05:06:32PM -0400, Stewart Hildebrand wrote:
> On 7/25/25 03:58, Roger Pau Monné wrote:
> > On Thu, Jul 24, 2025 at 06:44:32PM +0200, Roger Pau Monné wrote:
> >> On Wed, Jul 23, 2025 at 12:37:41PM -0400, Stewart Hildebrand wrote:
> >>> @@ -283,7 +297,48 @@ static int __init a
On 31.07.2025 17:58, Oleksii Kurochko wrote:
> It instructs the remote harts to execute one or more HFENCE.GVMA instructions
> by making an SBI call, covering the range of guest physical addresses between
> start_addr and start_addr + size only for the given VMID.
>
> The remote fence operation ap
On 31.07.2025 17:58, Oleksii Kurochko wrote:
> Instruct the remote harts to execute one or more HFENCE.GVMA instructions,
> covering the range of guest physical addresses between start_addr and
> start_addr + size for all VMIDs.
>
> The remote fence operation applies to the entire address space if
On 04.08.2025 15:08, Roger Pau Monné wrote:
> On Tue, Jul 29, 2025 at 04:16:15PM +0200, Jan Beulich wrote:
>> On 24.07.2025 13:04, Roger Pau Monne wrote:
>>> --- a/xen/common/pdx.c
>>> +++ b/xen/common/pdx.c
>>> @@ -24,6 +24,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>>
On Tue, Jul 29, 2025 at 04:16:15PM +0200, Jan Beulich wrote:
> On 24.07.2025 13:04, Roger Pau Monne wrote:
> > --- a/xen/common/pdx.c
> > +++ b/xen/common/pdx.c
> > @@ -24,6 +24,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > /**
> > * Maximum (non-inclusive) usable pd
Introduce a new '-p/--pcpus' flag to display physical CPU utilization metrics
using xc_interface. This provides hypervisor-level CPU usage insights alongside
existing domain statistics. This helps correlate VM resource usage with host CPU
load patterns.
Changes:
- Add pcpu.c/pcpu.h for PCPU stat c
Hi Hari,
On 30/07/2025 09:45, Hari Limaye wrote:
CAUTION: This message has originated from an External Source. Please use proper
judgment and caution when opening attachments, clicking links, or responding to
this email.
From: Penny Zheng
In the function `init_staticmem_pages` we need to h
Hi Hari,
On 30/07/2025 09:45, Hari Limaye wrote:
CAUTION: This message has originated from an External Source. Please use proper
judgment and caution when opening attachments, clicking links, or responding to
this email.
From: Luca Fancellu
Introduce helpers (un)map_mm_range() in order to
Hi Hari,
On 30/07/2025 09:45, Hari Limaye wrote:
CAUTION: This message has originated from an External Source. Please use proper
judgment and caution when opening attachments, clicking links, or responding to
this email.
From: Luca Fancellu
Implement `setup_mm` for MPU systems. This varian
On 03.08.2025 11:47, Penny Zheng wrote:
> File hvm/vm_event.c and x86/vm_event.c are the extend to vm_event handling
> routines, and its compilation shall be guarded by CONFIG_VM_EVENT too.
> Futhermore, features about monitor_op and memory access are both based on
> vm event subsystem, so monitor.
Hi Hari,
On 30/07/2025 09:45, Hari Limaye wrote:
CAUTION: This message has originated from an External Source. Please use proper
judgment and caution when opening attachments, clicking links, or responding to
this email.
From: Luca Fancellu
Add a scheme to distinguish transient MPU regions
From: Leon Romanovsky
Block layer maps MMIO memory through dma_map_phys() interface
with help of DMA_ATTR_MMIO attribute. There is a need to unmap
that memory with the appropriate unmap function.
Signed-off-by: Leon Romanovsky
---
drivers/nvme/host/pci.c | 18 +-
1 file changed
From: Leon Romanovsky
Make sure that CPU is not synced and IOMMU is configured to take
MMIO path by providing newly introduced DMA_ATTR_MMIO attribute.
Signed-off-by: Leon Romanovsky
---
block/blk-mq-dma.c | 13 +++--
include/linux/blk-mq-dma.h | 6 +-
include/linux/blk_ty
From: Leon Romanovsky
In case peer-to-peer transaction traverses through host bridge,
the IOMMU needs to have IOMMU_MMIO flag, together with skip of
CPU sync.
The latter was handled by provided DMA_ATTR_SKIP_CPU_SYNC flag,
but IOMMU flag was missed, due to assumption that such memory
can be trea
From: Leon Romanovsky
Convert the KMSAN DMA handling function from page-based to physical
address-based interface.
The refactoring renames kmsan_handle_dma() parameters from accepting
(struct page *page, size_t offset, size_t size) to (phys_addr_t phys,
size_t size). A PFN_VALID check is added t
From: Leon Romanovsky
Extend base DMA page API to handle MMIO flow.
Signed-off-by: Leon Romanovsky
---
kernel/dma/mapping.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index 709405d46b2b4..f5f051737e5
From: Leon Romanovsky
Convert HMM DMA operations from the legacy page-based API to the new
physical address-based dma_map_phys() and dma_unmap_phys() functions.
This demonstrates the preferred approach for new code that should use
physical addresses directly rather than page+offset parameters.
T
From: Leon Romanovsky
After introduction of dma_map_phys(), there is no need to convert
from physical address to struct page in order to map page. So let's
use it directly.
Signed-off-by: Leon Romanovsky
---
block/blk-mq-dma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --g
From: Leon Romanovsky
Rename the IOMMU DMA mapping functions to better reflect their actual
calling convention. The functions iommu_dma_map_page() and
iommu_dma_unmap_page() are renamed to iommu_dma_map_phys() and
iommu_dma_unmap_phys() respectively, as they already operate on physical
addresses
From: Leon Romanovsky
Introduce new DMA mapping functions dma_map_phys() and dma_unmap_phys()
that operate directly on physical addresses instead of page+offset
parameters. This provides a more efficient interface for drivers that
already have physical addresses available.
The new functions are
From: Leon Romanovsky
General dma_direct_map_resource() is going to be removed
in next patch, so simply open-code it in xen driver.
Signed-off-by: Leon Romanovsky
---
drivers/xen/swiotlb-xen.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/xen
Hi Hari,
On 30/07/2025 09:45, Hari Limaye wrote:
CAUTION: This message has originated from an External Source. Please use proper
judgment and caution when opening attachments, clicking links, or responding to
this email.
From: Luca Fancellu
Implement the MPU variant of `setup_frametable_ma
From: Leon Romanovsky
Convert the DMA direct mapping functions to accept physical addresses
directly instead of page+offset parameters. The functions were already
operating on physical addresses internally, so this change eliminates
the redundant page-to-physical conversion at the API boundary.
From: Leon Romanovsky
Convert the DMA debug infrastructure from page-based to physical address-based
mapping as a preparation to rely on physical address for DMA mapping routines.
The refactoring renames debug_dma_map_page() to debug_dma_map_phys() and
changes its signature to accept a phys_addr
From: Leon Romanovsky
As a preparation for following map_page -> map_phys API conversion,
let's rename trace_dma_*map_page() to be trace_dma_*map_phys().
Signed-off-by: Leon Romanovsky
---
include/trace/events/dma.h | 4 ++--
kernel/dma/mapping.c | 4 ++--
2 files changed, 4 insertions(+
Changelog:
v1:
* Added new DMA_ATTR_MMIO attribute to indicate
PCI_P2PDMA_MAP_THRU_HOST_BRIDGE path.
* Rewrote dma_map_* functions to use thus new attribute
v0: https://lore.kernel.org/all/cover.1750854543.git.l...@kernel.org/
---
From: Leon Romanovsky
Combine iommu_dma_*map_phys with iommu_dma_*map_resource interfaces in
order to allow single phys_addr_t flow.
Signed-off-by: Leon Romanovsky
---
drivers/iommu/dma-iommu.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/io
From: Leon Romanovsky
This patch introduces the DMA_ATTR_MMIO attribute to mark DMA buffers
that reside in memory-mapped I/O (MMIO) regions, such as device BARs
exposed through the host bridge, which are accessible for peer-to-peer
(P2P) DMA.
This attribute is especially useful for exporting dev
From: Leon Romanovsky
Make sure that CPU is not synced if MMIO path is taken.
Signed-off-by: Leon Romanovsky
---
drivers/iommu/dma-iommu.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index ea2e
On 03.08.2025 11:47, Penny Zheng wrote:
> We have PG_log_dirty flag to wrap codes about paging log-dirty support.
> The main entry is paging_domctl(),
Yet paging_domctl() serves other paging modes, too. In fact for the shim
PG_SH_forced is actually a mode that could plausibly come into use (even
i
On 03.08.2025 11:47, Penny Zheng wrote:
> Flag PG_log_dirty is for paging log dirty support, not vram tracking support.
> However data structure sh_dirty_vram{} and function paging_log_dirty_range()
> designed for vram tracking support, are guarded with PG_log_dirty.
The struct decl is guarded by
"cpuid=no-rdrand" cannot actually be used to suppress the respective
boot warning on certain AMD hardware. That's because cleared_caps[] are
only applied after the ->c_init() hooks ran, i.e. cpu_has() still
returns true in init_amd().
Fixes: 93401e28a84b ("x86: clear RDRAND CPUID bit on AMD family
On 04.08.2025 13:00, Andrew Cooper wrote:
> On 04/08/2025 10:34 am, Jan Beulich wrote:
>> On 24.07.2025 16:07, Yann Sionneau wrote:
>>> xen.efi PE does not boot when loaded from shim or some patched
>>> downstream grub2.
>>>
>>> What happens is the bootloader would honour the MEM_DISCARDABLE
>>> fl
On 31.07.2025 21:22, dm...@proton.me wrote:
> From: Denis Mukhin
>
> Enable virtual NS16550 for PVH domains in xl.
>
> {map,unmap}_domain_emuirq_pirq() infrastructure is modified by adding new
> type of interrupt resources 'IRQ_EMU' which means 'emulated device IRQ'
> (similarly to IRQ_MSI_EMU)
On 04/08/2025 10:34 am, Jan Beulich wrote:
> On 24.07.2025 16:07, Yann Sionneau wrote:
>> xen.efi PE does not boot when loaded from shim or some patched
>> downstream grub2.
>>
>> What happens is the bootloader would honour the MEM_DISCARDABLE
>> flag of the .reloc section meaning it would not load
On 31.07.2025 21:22, dm...@proton.me wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -780,9 +780,10 @@ static bool emulation_flags_ok(const struct domain *d,
> uint32_t emflags)
> /* HVM domU */
> {
> .caps = CAP_HVM | CAP_DOMU,
> -
On 31.07.2025 21:22, dm...@proton.me wrote:
> From: Denis Mukhin
>
> Add initial in-hypervisor emulator for NS8250/NS16x50-compatible UARTs under
> CONFIG_VUART_NS16550 for x86 port of Xen.
>
> x86 port of Xen lacks vUART facility similar to Arm's SBSA emulator to support
> x86 guest OS bring u
On Tue, Jul 29, 2025 at 03:54:24PM +0100, Andrew Cooper wrote:
> On 24/07/2025 12:04 pm, Roger Pau Monne wrote:
> > diff --git a/xen/arch/arm/include/asm/Makefile
> > b/xen/arch/arm/include/asm/Makefile
> > index 4565baca6a4d..cec13c889dab 100644
> > --- a/xen/arch/arm/include/asm/Makefile
> > +++
On 31.07.2025 21:22, dm...@proton.me wrote:
> From: Denis Mukhin
>
> Added missing definitions needed for NS16550 UART emulator.
>
> Newly introduced MSR definitions re-used in the existing ns16550 driver.
>
> Also, corrected FCR DMA definition bit#3 (0x08) as per:
> https://www.ti.com/lit/d
On 31.07.2025 21:21, dm...@proton.me wrote:
> From: Denis Mukhin
>
> Move IRQ/IOMEM rangesets allocation before arch_domain_create().
>
> That guarantees that arch-specific code could access those rangesets to
> register traps for emulation.
>
> It is necessary for those emulators registering
On 31.07.2025 21:21, dm...@proton.me wrote:
> From: Denis Mukhin
>
> Introduce a driver framework to abstract UART emulators in the hypervisor.
>
> That allows for architecture-independent handling of virtual UARTs in the
> console driver and simplifies enabling new UART emulators.
>
> The fra
On Wed, Jul 23, 2025 at 02:00:55PM +0200, Jan Beulich wrote:
> Part of it stated the opposite of what actual behavior is.
>
> Fixes: 7126b7f806d5 ("x86/CPU: re-work populating of cpu_data[]")
> Reported-by: Juergen Gross
> Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
Thanks, Roger.
On 31.07.2025 21:21, dm...@proton.me wrote:
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -652,6 +652,8 @@ struct domain
> unsigned int *llc_colors;
> #endif
>
> +uint32_t emulation_flags;
Just one further remark: The field probably never should have been of this
On 24.07.2025 16:07, Yann Sionneau wrote:
> xen.efi PE does not boot when loaded from shim or some patched
> downstream grub2.
>
> What happens is the bootloader would honour the MEM_DISCARDABLE
> flag of the .reloc section meaning it would not load its content
> into memory.
>
> But Xen is parsi
On 04.08.2025 10:09, Penny, Zheng wrote:
> [Public]
>
>> -Original Message-
>> From: Jan Beulich
>> Sent: Thursday, July 17, 2025 12:00 AM
>> To: Penny, Zheng
>> Cc: Huang, Ray ; Andrew Cooper
>> ; Anthony PERARD ;
>> Orzel, Michal ; Julien Grall ; Roger
>> Pau
>> Monné ; Stefano Stabel
On 04.08.2025 10:09, Penny, Zheng wrote:
> [Public]
>
>> -Original Message-
>> From: Jan Beulich
>> Sent: Thursday, July 17, 2025 12:00 AM
>> To: Penny, Zheng
>> Cc: Huang, Ray ; Andrew Cooper
>> ; Anthony PERARD ;
>> Orzel, Michal ; Julien Grall ; Roger
>> Pau
>> Monné ; Stefano Stabel
On 04.08.2025 10:29, Penny, Zheng wrote:
> [Public]
>
>> -Original Message-
>> From: Jan Beulich
>> Sent: Monday, August 4, 2025 3:41 PM
>> To: Penny, Zheng
>> Cc: Huang, Ray ; Andrew Cooper
>> ; Anthony PERARD ;
>> Orzel, Michal ; Julien Grall ; Roger
>> Pau
>> Monné ; Stefano Stabelli
On 01.08.2025 11:22, Mykyta Poturai wrote:
> Create add_discovered_pci_devices function that calls pci_device_add
> on every PCI device discovered.
> The devices will be added to dom_io so that they can be assigned
> later to other domains.
And why's the intermediate step necessary? IOW can't they
[Public]
> -Original Message-
> From: Jan Beulich
> Sent: Monday, August 4, 2025 3:41 PM
> To: Penny, Zheng
> Cc: Huang, Ray ; Andrew Cooper
> ; Anthony PERARD ;
> Orzel, Michal ; Julien Grall ; Roger Pau
> Monné ; Stefano Stabellini ;
> xen-
> de...@lists.xenproject.org
> Subject: Re:
On 01.08.2025 11:22, Mykyta Poturai wrote:
> From: Luca Fancellu
>
> Currently pci_add_device is called from hypercalls requested by Dom0
> to add pci devices and when the device has no domain associated with
> it, it is assumed that hardware_domain is the owner.
>
> On the dom0less scenario, th
On 01.08.2025 11:22, Mykyta Poturai wrote:
> From: Edward Pickup
>
> This patch adds a Xen boot arguments that, if enabled, causes a call to
> existing code to scan pci devices enumerated by the firmware.
>
> This patch also makes an existing debug function viewable outside its
> translation uni
[Public]
> -Original Message-
> From: Jan Beulich
> Sent: Thursday, July 17, 2025 12:00 AM
> To: Penny, Zheng
> Cc: Huang, Ray ; Andrew Cooper
> ; Anthony PERARD ;
> Orzel, Michal ; Julien Grall ; Roger Pau
> Monné ; Stefano Stabellini ;
> xen-
> de...@lists.xenproject.org
> Subject: Re
On 02.08.2025 19:48, Dmytro Prokopchuk1 wrote:
> There are a lot of MISRA C R17.7 violations in the XEN.
> This rule states: "The value returned by a function having non-void
> return type shall be used".
>
> Actually, need to decide how to deal with these violations.
> Quick analyze shown that t
On 01.08.2025 22:24, Stewart Hildebrand wrote:
> @@ -839,6 +839,9 @@ void sched_destroy_vcpu(struct vcpu *v)
> {
> struct sched_unit *unit = v->sched_unit;
>
> +if ( !unit )
> +return;
> +
> kill_timer(&v->periodic_timer);
> kill_timer(&v->singleshot_timer);
> kil
On 03.08.2025 11:47, Penny Zheng wrote:
> 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.
>
>
On 03.08.2025 11:47, Penny Zheng wrote:
> In order to fix CI error of a randconfig picking both PV_SHIM_EXCLUSIVE=y and
> HVM=y results in hvm.c being built, but domctl.c not being built, which leaves
> a few functions, like domctl_lock_acquire/release() undefined, causing linking
> to fail.
> To f
On 03.08.2025 11:47, Penny Zheng wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -627,6 +627,10 @@ config SYSCTL
> This option shall only be disabled on some dom0less systems, or
> PV shim on x86, to reduce Xen footprint.
>
> +config DOMCTL
> + bool "Enable d
Hi Demi,
> On 3 Aug 2025, at 06:24, Demi Marie Obenour wrote:
>
> On 7/17/25 08:11, Bertrand Marquis wrote:
>> Create a CONFIG_FFA_VM_TO_VM parameter to activate FFA communication
>> between VMs.
>> When activated list VMs in the system with FF-A support in part_info_get.
>>
>> When VM to VM is
On 04.08.2025 08:47, Penny, Zheng wrote:
> [Public]
>
>> -Original Message-
>> From: Jan Beulich
>> Sent: Wednesday, July 16, 2025 11:39 PM
>> To: Penny, Zheng
>> Cc: Huang, Ray ; Andrew Cooper
>> ; Roger Pau Monné ;
>> Anthony PERARD ; Orzel, Michal
>> ; Julien Grall ; Stefano Stabellin
On 04.08.2025 07:47, Penny, Zheng wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: Wednesday, July 16, 2025 11:01 PM
>>
>> On 11.07.2025 05:50, Penny Zheng wrote:
>>> --- a/xen/drivers/cpufreq/cpufreq.c
>>> +++ b/xen/drivers/cpufreq/cpufreq.c
>>> @@ -64,12 +64,53 @@ LIST_HEAD_REA
On 04.08.2025 08:04, Penny, Zheng wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: Wednesday, July 16, 2025 11:01 PM
>>
>> On 11.07.2025 05:50, Penny Zheng wrote:
>>> --- a/xen/drivers/cpufreq/cpufreq.c
>>> +++ b/xen/drivers/cpufreq/cpufreq.c
>>> @@ -64,12 +64,53 @@ LIST_HEAD_REA
On 01.08.2025 21:30, dm...@proton.me wrote:
> On Fri, Aug 01, 2025 at 08:02:56AM +0200, Jan Beulich wrote:
>> On 31.07.2025 22:55, dm...@proton.me wrote:
>>> On Wed, Jul 09, 2025 at 04:57:44PM +0200, Jan Beulich wrote:
On 24.06.2025 05:56, dm...@proton.me wrote:
> @@ -458,16 +459,16 @@ str
On 01.08.2025 20:58, dm...@proton.me wrote:
> On Fri, Aug 01, 2025 at 09:30:34AM +0200, Jan Beulich wrote:
>> Them not being altered by any means, their __read_mostly attribute is
>> actually counter-productive: It causes the compiler to instantiate the
>> variables, when already with just the attr
95 matches
Mail list logo
