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() )
> -{
> -local_irq_disable();
> -r.master_stime = r
Nathan,
> I'm not sure this will work if the first minor frame is also missed (which can
> happen in some odd cases). In that scenario, you need to iterate through the
> schedule after resyncing the expected next major frame.
>
> Building off your changes, this should work:
>
> -if ( sched_
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
> >>>
> >>> Move PL011 emulator to the new location
On Wed, Jun 25, 2025 at 07:25:29AM +0200, Jan Beulich wrote:
> On 25.06.2025 00:54, dm...@proton.me wrote:
> > On Tue, Jun 24, 2025 at 09:40:02AM +0200, Jan Beulich wrote:
> >> On 24.06.2025 09:36, dm...@proton.me wrote:
> >>> On Tue, Jun 24, 2025 at 07:53:04AM +0200, Jan Beulich wrote:
> On 2
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 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 -0700, Stefano Stabellini wrote:
> Hi all,
>
> This short patch
On 7/9/25 19:28, Stefano Stabellini wrote:
> Hi all,
>
> 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_p
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 file name alone. But
for the rest:
emulate.c: casts from
Hi all,
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
CI tests:
https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/pipelines/1917527911
On 7/10/25 00:38, Dmytro Prokopchuk1 wrote:
> This patch series eliminates/deviates MISRA C Rule 5.5 violations for ARM64.
>
> Thread discussion:
> https://patchew.org/Xen/cover.1751659393.git.dmytro._5fprokopch.
Address a violation of MISRA C:2012 Rule 5.5:
"Identifiers shall be distinct from macro names".
Reports for service MC3A2.R5.5:
xen/include/xen/fdt-domain-build.h: non-compliant parameter 'copy_to_guest'
xen/include/xen/guest_access.h: non-compliant macro 'copy_to_guest'
Rename 'copy_to_guest' fu
This patch series eliminates/deviates MISRA C Rule 5.5 violations for ARM64.
Thread discussion:
https://patchew.org/Xen/cover.1751659393.git.dmytro._5fprokopch...@epam.com/
Changes in v2:
- fixed code alignment in "device-tree: address violation of MISRA C Rule 5.5"
- updated commit message in "i
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'.
Signed-off-by: Dmytro Prokopchuk
---
automation/eclair_
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 variable 'iommu_quarantine'
There is a clash between funct
By default GCC uses "simple" coverage counter update
mechanism. It is perfectly fine for single-threaded (or single CPU in
our case) setups, but will cause race conditions on SMP systems.
For example, I observed that counters are going backwards when running
Xen inside QEMU.
GCC starting from ver
Hi Nicola,
> On 24 Jun 2025, at 02:20, victorm.l...@amd.com wrote:
>
> From: Nicola Vetrini
>
> Use {get,put}_unaligned_t to ensure that reads and writes are
> safe to perform even on potentially misaligned pointers.
>
Make sense as we convert a void* to uint32_t * so might be misaligned.
>
On 7/9/25 11:16, Jason Andryuk wrote:
> Hi,
>
> I'm running Xen in QEMU with vgic3 and started hitting:
>
> (XEN) Xen BUG at drivers/passthrough/arm/iommu_helpers.c:49
>
> BUG_ON(!is_domain_direct_mapped(d));
>
> I'm using dmo0less to create a split hardware and control domains. That
> me
On Mon, Jul 07, 2025 at 04:52:04PM +0200, Petr Beneš wrote:
> On Mon, Jul 7, 2025 at 3:35 PM Anthony PERARD wrote:
> >
> > It seems that altp2m_count is going to be used for the creation of all
> > guest, right? That is in addition to HVM, it will be also used for PV
> > guest and on Arm, and any
On Mon, Jul 07, 2025 at 05:28:26PM +0200, Nicola Vetrini wrote:
> diff --git a/automation/gitlab-ci/analyze.yaml
> b/automation/gitlab-ci/analyze.yaml
> index 5b00b9f25ca6..9cec0f65a439 100644
> --- a/automation/gitlab-ci/analyze.yaml
> +++ b/automation/gitlab-ci/analyze.yaml
> @@ -8,7 +8,10 @@
>
Hi,
I'm running Xen in QEMU with vgic3 and started hitting:
(XEN) Xen BUG at drivers/passthrough/arm/iommu_helpers.c:49
BUG_ON(!is_domain_direct_mapped(d));
I'm using dmo0less to create a split hardware and control domains. That
means hwdom is not direct mapped, but is_iommu_enabled() is
Hi Michal,
On 09/07/2025 14:38, Orzel, Michal wrote:
On 09/07/2025 15:12, Ayan Kumar Halder wrote:
There are a number of places where Xen triggers a BUG() due to 'impossible'
conditions. One of these impossible condition is when gicv3_info.nr_lrs is
equal to 0 or greater than 16.
Add a OFT ma
On 09.07.2025 11:46, Alejandro Vallejo wrote:
> On Tue Jul 8, 2025 at 8:32 PM CEST, Stefano Stabellini wrote:
>> Today, checking for non-fatal MCE errors on AMD is very invasive: it
>> involves a periodic timer interrupting the physical CPU execution at
>> regular intervals. Moreover, when the time
On 24.06.2025 05:56, dm...@proton.me wrote:
> @@ -458,16 +459,16 @@ struct arch_domain
> } __cacheline_aligned;
>
> #ifdef CONFIG_HVM
> -#define X86_EMU_LAPICXEN_X86_EMU_LAPIC
> -#define X86_EMU_HPET XEN_X86_EMU_HPET
> -#define X86_EMU_PM XEN_X86_EMU_PM
> -#define X86_EMU_RTC
On 08.07.2025 20:07, Alejandro Vallejo wrote:
> From: Alejandro Vallejo
>
> Moving forward the idea is for there to be:
>
> 1. Basic DT support: used by dom0less/hyperlaunch.
> 2. Full DT support: used for device discovery and HW setup.
>
> Rename HAS_DEVICE_TREE to HAS_DEVICE_TREE_DISCOVER
On 02.07.25 10: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 b
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;
> +
> +#if __has_include()
> +struct arch_boot_domain arch;
> +#endif
+Jeff
On 6/25/25 23:51, Choi, Anderson wrote:
> We are observing a slight delay in the start of major frame with the current
> implementation of ARINC653 scheduler, which breaks the determinism in the
> periodic execution of domains.
>
> This seems to result from the logic where the variable "nex
On 08.07.2025 20:07, Alejandro Vallejo wrote:
> From: Alejandro Vallejo
>
> These types resemble each other very closely in layout and intent,
> and with "struct boot_module" already in common code it makes perfect
> sense to merge them. In order to do so, rename identical fields with
> conflicti
On Tue, Jul 08, 2025 at 10:11:18AM -0700, 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 -0700, Stefano Stabellini wrote:
> > > Interrupt forwarding
> > > from Xen into HVM/PVH guests uses
On 09/07/2025 15:12, Ayan Kumar Halder wrote:
> There are a number of places where Xen triggers a BUG() due to 'impossible'
> conditions. One of these impossible condition is when gicv3_info.nr_lrs is
> equal to 0 or greater than 16.
>
> Add a OFT marker in the code and link it to document expl
There are a number of places where Xen triggers a BUG() due to 'impossible'
conditions. One of these impossible condition is when gicv3_info.nr_lrs is
equal to 0 or greater than 16.
Add a OFT marker in the code and link it to document explaining why this
condition is impossible to be covered while
On 08.07.25 23:14, Jason Andryuk wrote:
On 2025-07-02 04:12, Juergen Gross wrote:
When initializing the memory allocator, don't add memory pages of
modules and the initial boot info structure to the free memory.
This is relevant only when running in PVH mode, as in PV mode only
memory above the
On 2025-07-09 13:41, Nicola Vetrini wrote:
On 2025-07-09 12:10, Jan Beulich wrote:
This addresses a Misra rule 8.4 ("A compatible declaration shall be
visible when an object or function with external linkage is defined")
violation.
Fixes: a16f2b3e0669 ("xen/pmstat: introduce CONFIG_PM_OP")
Sign
On 2025-07-09 12:10, Jan Beulich wrote:
This addresses a Misra rule 8.4 ("A compatible declaration shall be
visible when an object or function with external linkage is defined")
violation.
Fixes: a16f2b3e0669 ("xen/pmstat: introduce CONFIG_PM_OP")
Signed-off-by: Jan Beulich
Reviewed-by: Nico
This addresses a Misra rule 8.4 ("A compatible declaration shall be
visible when an object or function with external linkage is defined")
violation.
Fixes: a16f2b3e0669 ("xen/pmstat: introduce CONFIG_PM_OP")
Signed-off-by: Jan Beulich
--- a/xen/drivers/acpi/pm-op.c
+++ b/xen/drivers/acpi/pm-op.c
On Tue Jul 8, 2025 at 8:32 PM CEST, Stefano Stabellini wrote:
> Today, checking for non-fatal MCE errors on AMD is very invasive: it
> involves a periodic timer interrupting the physical CPU execution at
> regular intervals. Moreover, when the timer fires, the handler sends an
> IPI to all physical
On Tue Jul 8, 2025 at 8:32 PM CEST, Stefano Stabellini wrote:
> On real time configuration with the null scheduler, we shouldn't
> interrupt the guest execution unless strictly necessary: the guest could
> be a real time guest (e.g. FreeRTOS) and interrupting its execution
> could lead to a missed
Ack. Sorry for forgetting this
On Wed, 9 Jul 2025, 10:44 Jan Beulich, wrote:
> While the change is fine on staging, where the toolchain baseline was
> moved, we need to remain compatible with older gas on stable branches
> for now.
>
> Fixes: fa254938f00a ("x86/idle: Move monitor()/mwait() wrap
On Tue, Jul 1, 2025 at 4:18 PM Marek Marczykowski-Górecki
wrote:
>
> On Tue, Jul 01, 2025 at 03:31:19PM +0100, Frediano Ziglio wrote:
> > On Fri, Jun 27, 2025 at 5:20 PM Marek Marczykowski-Górecki
> > wrote:
> > >
> > > On Fri, Jun 27, 2025 at 04:58:43PM +0100, Frediano Ziglio wrote:
> > > > On F
On 09.07.2025 10:04, Koichiro Den wrote:
> On Mon, Jul 07, 2025 at 10:01:47AM +0200, Jan Beulich wrote:
>> On 05.07.2025 16:27, Koichiro Den wrote:
>>> --- a/xen/arch/arm/mm.c
>>> +++ b/xen/arch/arm/mm.c
>>> @@ -180,7 +180,21 @@ int xenmem_add_to_physmap_one(
>>> case XENMAPSPACE_dev_mmio:
>>>
On 09.07.2025 11:07, Frediano Ziglio wrote:
> On Tue, Jul 8, 2025 at 4:41 PM Jan Beulich wrote:
>>
>> On 08.07.2025 15:56, Frediano Ziglio wrote:
>>> EFI code path split options from EFI LoadOptions fields in 2
>>> pieces, first EFI options, second Xen options.
>>> "get_argv" function is called fi
On Tue, Jul 8, 2025 at 4:41 PM Jan Beulich wrote:
>
> On 08.07.2025 15:56, Frediano Ziglio wrote:
> > EFI code path split options from EFI LoadOptions fields in 2
> > pieces, first EFI options, second Xen options.
> > "get_argv" function is called first to get the number of arguments
> > in the Lo
While the change is fine on staging, where the toolchain baseline was
moved, we need to remain compatible with older gas on stable branches
for now.
Fixes: fa254938f00a ("x86/idle: Move monitor()/mwait() wrappers into
cpu-idle.c")
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/acpi/cpu_idle.c
++
On 09.07.2025 10:24, Oleksii Kurochko wrote:
>
> On 7/8/25 6:04 PM, Jan Beulich wrote:
>> On 08.07.2025 17:42, Oleksii Kurochko wrote:
>>> On 7/8/25 2:45 PM, Jan Beulich wrote:
On 08.07.2025 12:37, Oleksii Kurochko wrote:
> On 7/8/25 11:01 AM, Oleksii Kurochko wrote:
>> On 7/8/25 9:10
On 02/07/2025 16:14, Hari Limaye wrote:
> From: Luca Fancellu
>
> Implement remove_early_mappings for MPU systems.
>
> Signed-off-by: Luca Fancellu
> Signed-off-by: Hari Limaye
> Reviewed-by: Ayan Kumar Halder
> ---
> Changes from v1:
> - Add Ayan's R-b
> ---
> xen/arch/arm/mpu/setup.c |
Hi Jan,
Thank you for your review.
> On 08/07/ 2025 19:15, Jan Beulich wrote:
>> +pcpu.o: pcpu.c pcpu.h
>> +$(CC) $(CFLAGS) -c $< -o $@
>> +
>> +%.o: %.c
>> +$(CC) $(CFLAGS) -c $< -o $@
> As you mean to re-submit, you may also want to tidy (back) the above. You
> don't say why you need
On 02/07/2025 16:14, Hari Limaye wrote:
> From: Luca Fancellu
>
> Implement the function early_fdt_map(), which is responsible for mapping
> the Device Tree Blob in the early stages of the boot process, for MPU
> systems.
>
> We make use of the map_pages_to_xen() and destroy_xen_mappings() AP
On Tue, Jul 08, 2025 at 05:10:46PM -0400, Stewart Hildebrand wrote:
> On 7/5/25 10:27, Koichiro Den wrote:
> > Implement ARM DEN 0057A PV time support for domains created via the
> > toolstack, utilizing the newly introduced XENMAPSPACE_pv_time.
> >
> > Signed-off-by: Koichiro Den
> > ---
> > to
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 co
On 7/8/25 6:04 PM, Jan Beulich wrote:
On 08.07.2025 17:42, Oleksii Kurochko wrote:
On 7/8/25 2:45 PM, Jan Beulich wrote:
On 08.07.2025 12:37, Oleksii Kurochko wrote:
On 7/8/25 11:01 AM, Oleksii Kurochko wrote:
On 7/8/25 9:10 AM, Jan Beulich wrote:
On 07.07.2025 18:10, Oleksii Kurochko wrote
On Mon, Jul 07, 2025 at 10:01:47AM +0200, Jan Beulich wrote:
> On 05.07.2025 16:27, Koichiro Den wrote:
> > --- a/xen/arch/arm/mm.c
> > +++ b/xen/arch/arm/mm.c
> > @@ -180,7 +180,21 @@ int xenmem_add_to_physmap_one(
> > case XENMAPSPACE_dev_mmio:
> > rc = map_dev_mmio_page(d, gfn, _mf
On 02/07/2025 16:13, Hari Limaye wrote:
> From: Penny Zheng
>
> This commit expands xen_mpumap_update/xen_mpumap_update_entry to include
> destroying an existing entry.
>
> We define a new helper "disable_mpu_region_from_index" to disable the MPU
> region based on index. If region is within [
On Tue, Jul 08, 2025 at 04:12:50PM -0400, Stewart Hildebrand wrote:
> On 7/5/25 10:27, Koichiro Den wrote:
> > The /reserved-memory node is inherently not specific to static-shmem.
> > Move it to a more generic domain build context. While at it, add an
> > empty kernel_info_get_shm_mem_const() for
On 09.07.2025 00:23, Dmytro Prokopchuk1 wrote:
> These external variables ('iommu_pt_cleanup_lock'
> and 'iommu_pt_cleanup_list') are no longer used
> in the codebase. Remove them.
>
> Fixes: b5622eb627 (iommu: remove unused iommu_ops method and tasklet,
> 2020-09-22)
> Signed-off-by: Dmytro Prok
On 08.07.2025 19:40, Stefano Stabellini wrote:
> On Tue, 8 Jul 2025, Jan Beulich wrote:
>> On 08.07.2025 02:07, Stefano Stabellini wrote:
>>> On real time configuration with the null scheduler, we shouldn't
>>> interrupt the guest execution unless strictly necessary: the guest could
>>> be a real t
55 matches
Mail list logo
