Re: [XEN PATCH] automation: Avoid changing source files for randconfig tests

2025-03-27 Thread Stefano Stabellini
On Thu, 27 Mar 2025, Anthony PERARD wrote: > On Wed, Mar 26, 2025 at 07:10:52PM -0700, Stefano Stabellini wrote: > > On Wed, 26 Mar 2025, Anthony PERARD wrote: > > > diff --git a/automation/scripts/build b/automation/scripts/build > > > index 522efe774e..8a3b8fb6b2 100755 > > > --- a/automation/scr

Re: [XEN PATCH] CI: Change pipeline name for scheduled pipeline

2025-03-27 Thread Stefano Stabellini
On Thu, 27 Mar 2025, Anthony PERARD wrote: > This description is already displayed on the web UI of the list of > pipeline, but using it as "name" will make it available in webhooks as > well and can be used by a bot. > > This doesn't change the behavior for other pipeline types, where the > varia

Re: [PATCH] trace: convert init_trace_bufs() to constructor

2025-03-27 Thread Julien Grall
Hi Jan, On 27/03/2025 16:10, Jan Beulich wrote: On 27.03.2025 16:49, Julien Grall wrote: On 27/03/2025 15:08, Jan Beulich wrote: On 27.03.2025 15:49, Julien Grall wrote: On 13/03/2025 13:38, Jan Beulich wrote: --- Same could then apparently be done for heap_init_late(). Thoughts? Looking a

Re: [PATCH v3] ARM/vgic: Use for_each_set_bit() in vgic-mmio*

2025-03-27 Thread Stefano Stabellini
On Thu, 27 Mar 2025, Andrew Cooper wrote: > These are all loops over a scalar value, and don't need to call general bitop > helpers behind the scenes. > > Clamp data to the width of the access in dispatch_mmio_write(), rather than > doing so in every handler. > > No functional change. > > Signed

[PATCH v2] xen/arm/efi: merge neighboring banks

2025-03-27 Thread Stefano Stabellini
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)

Re: [PATCH v2] xen/arm/efi: merge neighboring banks

2025-03-27 Thread Volodymyr Babchuk
Hi Stefano, Stefano Stabellini writes: > 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 - 00d

[PATCH v2] xen: add kconfig for event_fifo

2025-03-27 Thread Stefano Stabellini
Evtchn fifos are not needed on smaller systems; the older interface is lightweight and sufficient. Also, event_fifo causes runtime anonymous memory allocations, which are undesirable. Additionally, it exposes an extra interface to the guest, which is also undesirable unless necessary. Make it pos

Re: [PATCH] xen: simplify bitmap_to_xenctl_bitmap for little endian

2025-03-27 Thread Stefano Stabellini
On Mon, 24 Mar 2025, Jan Beulich wrote: > On 22.03.2025 00:09, Stefano Stabellini wrote: > > On Thu, 20 Mar 2025, Jan Beulich wrote: > >> On 20.03.2025 01:57, Stefano Stabellini wrote: > >>> On Wed, 19 Mar 2025, Jan Beulich wrote: > What about xenctl_bitmap_to_bitmap()? > >>> > >>> Let me se

[PATCH v3] xen: simplify bitmap_to_xenctl_bitmap for little endian

2025-03-27 Thread Stefano Stabellini
The little endian implementation of bitmap_to_xenctl_bitmap leads to unnecessary xmallocs and xfrees. Given that Xen only supports little endian architectures, it is worth optimizing. This patch removes the need for the xmalloc on little endian architectures. Signed-off-by: Stefano Stabellini --

Re: [xen-tip:linux-next 12/12] WARNING: modpost: vmlinux: section mismatch in reference: mc_debug_data+0x0 (section: .data) -> mc_debug_data_early (section: .init.data)

2025-03-27 Thread Jürgen Groß
On 27.03.25 15:40, Borislav Petkov wrote: On Thu, Mar 27, 2025 at 03:21:45PM +0100, Jürgen Groß wrote: Well, that is wasting nearly 3kB of the data section. Maybe not a big deal, but still... We could do it until the proper fix is in place, no? 3K is meh, especially for the hypervisor kernel

Re: [PATCH] trace: convert init_trace_bufs() to constructor

2025-03-27 Thread Jan Beulich
On 27.03.2025 16:49, Julien Grall wrote: > On 27/03/2025 15:08, Jan Beulich wrote: >> On 27.03.2025 15:49, Julien Grall wrote: >>> On 13/03/2025 13:38, Jan Beulich wrote: --- Same could then apparently be done for heap_init_late(). Thoughts? >>> >>> Looking at the code, I couldn't figure

Re: [PATCH 1/6] SUPPORT.md: make Linux based stubdom fully supported

2025-03-27 Thread Juergen Gross
On 26.03.25 17:04, Juergen Gross wrote: All patches needed for running with a Linux stubdom device model are in the tree and QubesOS is using and testing Linux stubdoms nowadays. Switch support from "Tech Preview" to "Supported". Signed-off-by: Juergen Gross --- CHANGELOG.md | 1 + SUPPORT.

Re: preparations for 4.19.2

2025-03-27 Thread Jan Beulich
On 27.03.2025 15:26, Andrew Cooper wrote: > On 27/03/2025 2:13 pm, Jan Beulich wrote: >> All, >> >> the release is due in a little over a week. Please point out backports you >> find >> missing from the respective staging branch, but which you consider relevant. >> I'm >> already aware of >> >> b

RE: [PATCH v3 12/15] xen/x86: implement EPP support for the amd-cppc driver in active mode

2025-03-27 Thread Penny, Zheng
[Public] Hi, > -Original Message- > From: Jan Beulich > Sent: Tuesday, March 25, 2025 6:49 PM > To: Penny, Zheng > Cc: Huang, Ray ; Andrew Cooper > ; Anthony PERARD ; > Orzel, Michal ; Julien Grall ; Roger > Pau Monné ; Stefano Stabellini ; > xen-devel@lists.xenproject.org > Subject: Re

Re: [PATCH v4 1/5] xen/arm: Create tee command line parameter

2025-03-27 Thread Bertrand Marquis
Hi Julien, > On 26 Mar 2025, at 23:49, Julien Grall wrote: > > Hi Bertrand, > > On 24/03/2025 13:52, Bertrand Marquis wrote: >> Add a new command line parameter "tee=" to be used to explicitly select >> what tee mediator is to be used by Xen and fail if it does not exist >> or the probe functio

Re: [PATCH v1 2/3] xen: x86: irq: initialize irq desc in create_irq()

2025-03-27 Thread Nicola Vetrini
On 2025-03-27 09:03, Jan Beulich wrote: On 27.03.2025 01:40, 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

RE: [PATCH v3 08/15] xen/amd: export processor max frequency value

2025-03-27 Thread Penny, Zheng
[Public] Hi, > -Original Message- > From: Jan Beulich > Sent: Monday, March 24, 2025 11:52 PM > To: Penny, Zheng > Cc: Huang, Ray ; Andrew Cooper > ; Roger Pau Monné ; xen- > de...@lists.xenproject.org > Subject: Re: [PATCH v3 08/15] xen/amd: export processor max frequency value > > On

Re: [PATCH v1] xen/config.h: Move BITS_PER_* definitions from asm/config.h to xen/config.h

2025-03-27 Thread Jan Beulich
On 27.03.2025 01:44, Andrew Cooper wrote: > On 26/03/2025 5:47 pm, Oleksii Kurochko wrote: >> diff --git a/xen/include/xen/config.h b/xen/include/xen/config.h >> index d888b2314d..dbbf2fce62 100644 >> --- a/xen/include/xen/config.h >> +++ b/xen/include/xen/config.h >> @@ -98,4 +98,13 @@ >> #define

Re: [PATCH v2] tools/arm: Fix nr_spis handling v2

2025-03-27 Thread Bertrand Marquis
Hi Michal, > On 25 Mar 2025, at 12:00, Michal Orzel wrote: > > We are missing a way to detect whether a user provided a value for > nr_spis equal to 0 or did not provide any value (default is also 0) which > can cause issues when calculated nr_spis is > 0 and the value from domain > config is 0.

Re: [PATCH v1 1/3] xen: gcov: add support for gcc 14.1

2025-03-27 Thread Jan Beulich
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 for it. > > Signed-off-by: Volodymyr Babchuk As to the title - what about 14.2.0? Or the soon to appear 14.3.0? I recommend to say just 14

Re: [PATCH v1 1/3] vpci: Hide capability when it fails to initialize

2025-03-27 Thread Roger Pau Monné
On Thu, Mar 27, 2025 at 03:32:12PM +0800, Jiqian Chen wrote: > When vpci fails to initialize a capability of a device, it just > return error instead of catching and processing exception. That > makes the entire device unusable. > > So, refactor REGISTER_VPCI_INIT to contain more capability specif

Re: [PATCH] x86/CPU: don't hard-code MTRR availability

2025-03-27 Thread Jan Beulich
On 27.03.2025 10:15, Jan Beulich wrote: > On 27.03.2025 09:21, Roger Pau Monné wrote: >> My main concern is whether the !mtrr path is still functional. Have >> you tried booting the resulting hypervisor with MTRR masked on CPUID? >> >> (or alternatively short-circuiting cpu_has_mtrr == 0?) > > I

Re: [PATCH v2 15/19] xen/sysctl: wrap around XEN_SYSCTL_physinfo

2025-03-27 Thread Oleksii Kurochko
On 3/26/25 6:50 AM, 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 --- v1 -> v2: - no need to wrap declaration - add transient #ifdef in sysctl.c for co

Re: [PATCH v2 18/19] xen/sysctl: wrap around arch-specific arch_do_sysctl

2025-03-27 Thread Oleksii Kurochko
On 3/26/25 6:50 AM, 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 CONFIG_S

Re: [PATCH v2] x86/P2M: synchronize fast and slow paths of p2m_get_page_from_gfn()

2025-03-27 Thread Jan Beulich
On 27.03.2025 10:00, Roger Pau Monné wrote: > On Tue, Mar 25, 2025 at 08:17:04AM +0100, Jan Beulich wrote: >> Handling of both grants and foreign pages was different between the two >> paths. >> >> While permitting access to grants would be desirable, doing so would >> require more involved handlin

Re: [PATCH] x86/CPU: don't hard-code MTRR availability

2025-03-27 Thread Roger Pau Monné
On Thu, Mar 27, 2025 at 10:15:03AM +0100, Jan Beulich wrote: > On 27.03.2025 09:21, Roger Pau Monné wrote: > > On Tue, Mar 25, 2025 at 08:18:11AM +0100, Jan Beulich wrote: > >> In particular if we're running virtualized, the underlying hypervisor > >> (which may be another Xen) may not surface MTRR

Re: [PATCH v2 3/4] xen/riscv: implement basic aplic_preinit()

2025-03-27 Thread Oleksii Kurochko
On 3/27/25 8:39 AM, Jan Beulich wrote: On 26.03.2025 17:49, Oleksii Kurochko wrote: On 3/26/25 4:19 PM, Jan Beulich wrote: On 25.03.2025 18:36, Oleksii Kurochko wrote: Introduce preinitialization stuff for the RISC-V Advanced Platform-Level Interrupt Controller (APLIC) in Xen: - Implementi

Re: [PATCH v2 15/19] xen/sysctl: wrap around XEN_SYSCTL_physinfo

2025-03-27 Thread Jan Beulich
On 27.03.2025 10:35, Oleksii Kurochko wrote: > > On 3/26/25 6:50 AM, 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 >> --- >> v1 -> v2: >

Re: [PATCH] x86/CPU: don't hard-code MTRR availability

2025-03-27 Thread Jan Beulich
On 27.03.2025 10:50, Roger Pau Monné wrote: > On Thu, Mar 27, 2025 at 10:15:03AM +0100, Jan Beulich wrote: >> On 27.03.2025 09:21, Roger Pau Monné wrote: >>> On Tue, Mar 25, 2025 at 08:18:11AM +0100, Jan Beulich wrote: In particular if we're running virtualized, the underlying hypervisor

Re: [PATCH V2] xen/arm: Initialize acpi_disabled to true during declaration

2025-03-27 Thread Julien Grall
Hi, On 26/03/2025 08:57, Orzel, Michal wrote: On 25/03/2025 17:54, Oleksandr Tyshchenko wrote: On 25.03.25 18:09, Julien Grall wrote: Hi Oleksandr, Hello Julien On 25/03/2025 16:05, Oleksandr Tyshchenko wrote: Furthermore, what happen if we decide to use ACPI afterwards? Wouldn't t

Re: [PATCH v3 05/15] xen/x86: introduce "cpufreq=amd-cppc" xen cmdline

2025-03-27 Thread Jan Beulich
On 27.03.2025 04:12, Penny, Zheng wrote: >> -Original Message- >> From: Jan Beulich >> Sent: Wednesday, March 26, 2025 6:55 PM >> >> On 26.03.2025 09:35, Penny, Zheng wrote: -Original Message- From: Jan Beulich Sent: Monday, March 24, 2025 11:26 PM On 06.0

Re: [PATCH v1 2/3] xen: x86: irq: initialize irq desc in create_irq()

2025-03-27 Thread Jan Beulich
On 27.03.2025 01:40, 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

Re: [PATCH v1] xen/config.h: Move BITS_PER_* definitions from asm/config.h to xen/config.h

2025-03-27 Thread Jan Beulich
On 26.03.2025 18:47, Oleksii Kurochko wrote: > --- a/xen/include/xen/config.h > +++ b/xen/include/xen/config.h > @@ -98,4 +98,13 @@ > #define ZERO_BLOCK_PTR ((void *)-1L) > #endif > > +#define BYTES_PER_LONG __SIZEOF_LONG__ > + > +#define BITS_PER_BYTE __CHAR_BIT__ > +#define BITS_PER_INT

Re: [PATCH] xen/percpu: don't initialize percpu on resume

2025-03-27 Thread Jan Beulich
On 27.03.2025 06:22, Mykola Kvach wrote: > --- a/xen/common/percpu.c > +++ b/xen/common/percpu.c > @@ -30,7 +30,12 @@ static int init_percpu_area(unsigned int cpu) > char *p; > > if ( __per_cpu_offset[cpu] != INVALID_PERCPU_AREA ) > -return park_offline_cpus ? 0 : -EBUSY; > +

Re: [PATCH] xen/percpu: don't initialize percpu on resume

2025-03-27 Thread Jan Beulich
On 27.03.2025 06:22, Mykola Kvach wrote: > 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.14

[linux-next:master] [PCI/MSI] d9f2164238: Kernel_panic-not_syncing:Fatal_exception

2025-03-27 Thread kernel test robot
02503271537.b451d717-...@intel.com The kernel config and materials to reproduce are available at: https://download.01.org/0day-ci/archive/20250327/202503271537.b451d717-...@intel.com [5.420499][T1] IOAPIC[0]: Preconfigured routing entry (2-16 -> IRQ 16 Level:1 ActiveLow:1) [5.429420]

Re: [PATCH] x86/CPU: don't hard-code MTRR availability

2025-03-27 Thread Roger Pau Monné
On Tue, Mar 25, 2025 at 08:18:11AM +0100, Jan Beulich wrote: > In particular if we're running virtualized, the underlying hypervisor > (which may be another Xen) may not surface MTRRs, and offer PAT only. At least for Xen, I think we offer MTRR uniformly, even on PVH guests? > Fixes: 5a281883cdc3

Re: [PATCH v4 2/5] xen/arm: ffa: Introduce VM to VM support

2025-03-27 Thread Bertrand Marquis
Hi Julien, > On 27 Mar 2025, at 00:14, Julien Grall wrote: > > Hi Bertrand, > > I didn't dig in the spec and neither some of the callers. So I will mainly > focus on the implementation from Xen PoV. Perfectly ok I think, Jens review should cover the spec point of view. > > On 24/03/2025 13:

[PATCH v1 3/3] vpci/msi: Remove registers when init_msi() fails

2025-03-27 Thread Jiqian Chen
When init_msi() fails, the new codes will try to hide MSI capability, so it can't rely on vpci_deassign_device() to remove all MSI related registers anymore, those registers must be cleaned up in failure path of init_msi. To do that, use a vpci_register array to record all MSI registers and call v

Re: [PATCH 3/6] tools: remove support for running a guest with qemu-traditional

2025-03-27 Thread Jan Beulich
On 26.03.2025 17:04, Juergen Gross wrote: > --- a/tools/firmware/hvmloader/pci.c > +++ b/tools/firmware/hvmloader/pci.c > @@ -108,24 +108,7 @@ void pci_setup(void) > uint64_t mmio_hole_size = 0; > > const char *s; > -/* > - * Do we allow hvmloader to relocate guest memory in ord

[PATCH v1 2/3] vpci/rebar: Remove registers when init_rebar() fails

2025-03-27 Thread Jiqian Chen
When init_rebar() fails, the new codes will try to hide Rebar capability, so it can't rely on vpci_deassign_device() to remove all Rebar related registers anymore, those registers must be cleaned up in failure path of init_rebar. To do that, use a vpci_register array to record all Rebar registers

[PATCH v1 1/3] vpci: Hide capability when it fails to initialize

2025-03-27 Thread Jiqian Chen
When vpci fails to initialize a capability of a device, it just return error instead of catching and processing exception. That makes the entire device unusable. So, refactor REGISTER_VPCI_INIT to contain more capability specific information, and try to hide capability when initialization fails in

Re: NULL pointer dereference in cpufreq_update_limits(?) under Xen PV dom0 - regression in 6.13

2025-03-27 Thread Jan Beulich
On 27.03.2025 01:51, Marek Marczykowski-Górecki wrote: > Hi, > > I've got a report[1] that 6.13.6 crashes as listed below. It worked fine in > 6.12.11. We've tried few simple things to narrow the problem down, but > without much success. > > This is running in Xen 4.17.5, PV dom0, which probably

Re: [PATCH v2 15/19] xen/sysctl: wrap around XEN_SYSCTL_physinfo

2025-03-27 Thread Oleksii Kurochko
On 3/27/25 10:58 AM, Jan Beulich wrote: On 27.03.2025 10:35, Oleksii Kurochko wrote: On 3/26/25 6:50 AM, 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 Zhen

Re: [PATCH] x86/MTRR: hook mtrr_bp_restore() back up

2025-03-27 Thread Andrew Cooper
On 27/03/2025 2:20 pm, Jan Beulich wrote: > On 27.03.2025 15:10, Roger Pau Monné wrote: >> On Thu, Mar 27, 2025 at 02:28:42PM +0100, Jan Beulich wrote: >>> On 27.03.2025 13:48, Roger Pau Monné wrote: On Thu, Mar 27, 2025 at 01:30:44PM +0100, Jan Beulich wrote: > On 27.03.2025 12:38, Roger

Re: [PATCH v4 29/30] x86/mm, mm/vmalloc: Defer flush_tlb_kernel_range() targeting NOHZ_FULL CPUs

2025-03-27 Thread Valentin Schneider
On 20/02/25 09:38, Dave Hansen wrote: > But, honestly, I'm still not sure this is worth all the trouble. If > folks want to avoid IPIs for TLB flushes, there are hardware features > that *DO* that. Just get new hardware instead of adding this complicated > pile of software that we have to maintain

Re: [PATCH] x86/MTRR: constrain AP sync and BSP restore

2025-03-27 Thread Andrew Cooper
On 27/03/2025 11:03 am, Jan Beulich wrote: > On 27.03.2025 11:53, Roger Pau Monné wrote: >> On Thu, Mar 27, 2025 at 10:54:23AM +0100, Jan Beulich wrote: >>> mtrr_set_all() has quite a bit of overhead, which is entirely useless >>> when set_mtrr_state() really does nothing. Furthermore, with >>> mtr

Re: [PATCH v2] CHANGELOG: Minimum toolchain requirements for x86 and ARM

2025-03-27 Thread Oleksii Kurochko
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 v2: * State x86 and ARM, rather than implying all architectures. --- CHANGELOG.md |

Re: [xen-tip:linux-next 12/12] WARNING: modpost: vmlinux: section mismatch in reference: mc_debug_data+0x0 (section: .data) -> mc_debug_data_early (section: .init.data)

2025-03-27 Thread Borislav Petkov
On Thu, Mar 27, 2025 at 03:21:45PM +0100, Jürgen Groß wrote: > Well, that is wasting nearly 3kB of the data section. > > Maybe not a big deal, but still... We could do it until the proper fix is in place, no? 3K is meh, especially for the hypervisor kernel, I'd say... -- Regards/Gruss, Bor

Re: [PATCH 2/6] docs: remove qemu-traditional support from documentation

2025-03-27 Thread Jürgen Groß
On 27.03.25 08:00, Jan Beulich wrote: On 26.03.2025 17:04, Juergen Gross wrote: @@ -1903,10 +1894,7 @@ it may be useful to request a different one, like UEFI. =item B -Loads ROMBIOS, a 16-bit x86 compatible BIOS. This is used by default -when B. This is the only BIOS -option supported w

Re: [PATCH] x86/MTRR: hook mtrr_bp_restore() back up

2025-03-27 Thread Jan Beulich
On 27.03.2025 16:23, Andrew Cooper wrote: > On 27/03/2025 2:20 pm, Jan Beulich wrote: >> On 27.03.2025 15:10, Roger Pau Monné wrote: >>> On Thu, Mar 27, 2025 at 02:28:42PM +0100, Jan Beulich wrote: On 27.03.2025 13:48, Roger Pau Monné wrote: > On Thu, Mar 27, 2025 at 01:30:44PM +0100, Jan

Re: [PATCH v1] xen/config.h: Move BITS_PER_* definitions from asm/config.h to xen/config.h

2025-03-27 Thread Oleksii Kurochko
On 3/27/25 2:16 PM, Jan Beulich wrote: On 27.03.2025 13:50, Oleksii Kurochko wrote: On 3/27/25 1:44 AM, Andrew Cooper wrote: On 26/03/2025 5:47 pm, Oleksii Kurochko wrote: diff --git a/xen/include/xen/config.h b/xen/include/xen/config.h index d888b2314d..dbbf2fce62 100644 --- a/xen/include/xe

Re: [PATCH v1] xen/config.h: Move BITS_PER_* definitions from asm/config.h to xen/config.h

2025-03-27 Thread Jan Beulich
On 27.03.2025 17:12, Oleksii Kurochko wrote: > > On 3/27/25 2:16 PM, Jan Beulich wrote: >> On 27.03.2025 13:50, Oleksii Kurochko wrote: >>> On 3/27/25 1:44 AM, Andrew Cooper wrote: On 26/03/2025 5:47 pm, Oleksii Kurochko wrote: > diff --git a/xen/include/xen/config.h b/xen/include/xen/con

Re: [PATCH 1/6] SUPPORT.md: make Linux based stubdom fully supported

2025-03-27 Thread Jürgen Groß
On 27.03.25 16:54, Jan Beulich wrote: On 27.03.2025 16:25, Juergen Gross wrote: On 26.03.25 17:04, Juergen Gross wrote: All patches needed for running with a Linux stubdom device model are in the tree and QubesOS is using and testing Linux stubdoms nowadays. Switch support from "Tech Preview"

[PATCH v2] xen/config.h: Move BITS_PER_* definitions from asm/config.h to xen/config.h

2025-03-27 Thread Oleksii Kurochko
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 come directly from the compiler environment. The ar

Re: [PATCH v1] xen/config.h: Move BITS_PER_* definitions from asm/config.h to xen/config.h

2025-03-27 Thread Oleksii Kurochko
On 3/27/25 1:44 AM, Andrew Cooper wrote: On 26/03/2025 5:47 pm, Oleksii Kurochko wrote: diff --git a/xen/include/xen/config.h b/xen/include/xen/config.h index d888b2314d..dbbf2fce62 100644 --- a/xen/include/xen/config.h +++ b/xen/include/xen/config.h @@ -98,4 +98,13 @@ #define ZERO_BLOCK_PTR

[PATCH v3] Xen: Update compiler checks

2025-03-27 Thread Andrew Cooper
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/compiler.h, rewrite the expression for clarity/brevity. Incl

Re: [PATCH v2] Xen: Update compiler checks

2025-03-27 Thread Oleksii Kurochko
On 3/27/25 5:31 PM, Andrew Cooper wrote: We have checks in both xen/compiler.h, and Config.mk. Both are incomplete. Remove the one from compiler.h, as it's pointless to perform in addition to the xen.git-wide one as well. Expand the checks to cover RISCV wanting GCC 11.1, and to cover Clang on

Re: [PATCH v2] Xen: Update compiler checks

2025-03-27 Thread Jan Beulich
On 27.03.2025 17:31, Andrew Cooper wrote: > We have checks in both xen/compiler.h, and Config.mk. Both are incomplete. > Remove the one from compiler.h, as it's pointless to perform in addition to > the xen.git-wide one as well. Isn't this premature? The Config.mk one doesn't terminate the build,

Re: [PATCH v2] Xen: Update compiler checks

2025-03-27 Thread Andrew Cooper
On 27/03/2025 4:31 pm, Andrew Cooper wrote: > diff --git a/Config.mk b/Config.mk > index 8a73f3da62b4..a9d62fc10cfa 100644 > --- a/Config.mk > +++ b/Config.mk > @@ -125,8 +125,18 @@ define cc-ver-check-closure > endif > endef > > -# Require GCC v4.1+ > -check-$(gcc) = $(call cc-ver-check,CC

Re: [PATCH 3/3] CHANGELOG: Minimum toolchain requirements

2025-03-27 Thread Andrew Cooper
On 21/03/2025 4:24 pm, Oleksii Kurochko wrote: > > > On 3/20/25 4:59 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 >> -

Re: [PATCH v2] Xen: Update compiler checks

2025-03-27 Thread Andrew Cooper
On 27/03/2025 4:37 pm, Oleksii Kurochko wrote: > > > On 3/27/25 5:31 PM, Andrew Cooper wrote: >> We have checks in both xen/compiler.h, and Config.mk. Both are incomplete. >> Remove the one from compiler.h, as it's pointless to perform in addition to >> the xen.git-wide one as well. >> >> Expand t

Re: [PATCH v2] Xen: Update compiler checks

2025-03-27 Thread Andrew Cooper
On 27/03/2025 4:39 pm, Jan Beulich wrote: > On 27.03.2025 17:31, Andrew Cooper wrote: >> We have checks in both xen/compiler.h, and Config.mk. Both are incomplete. >> Remove the one from compiler.h, as it's pointless to perform in addition to >> the xen.git-wide one as well. > Isn't this premature

Re: [PATCH 05/10] xenbus: add module description

2025-03-27 Thread Jürgen Groß
On 24.03.25 18: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 --- drivers/xen/xenbus/xenbus_probe_frontend.c | 1 + 1

Re: [PATCH 3/3] CHANGELOG: Minimum toolchain requirements

2025-03-27 Thread Andrew Cooper
On 27/03/2025 4:55 pm, Oleksii Kurochko wrote: > > > On 3/27/25 4:45 PM, Andrew Cooper wrote: >> On 21/03/2025 4:24 pm, Oleksii Kurochko wrote: >>> On 3/20/25 4:59 PM, Andrew Cooper wrote: Signed-off-by: Andrew Cooper --- CC: Anthony PERARD CC: Michal Orzel CC: Jan Beuli

Re: [PATCH 3/3] CHANGELOG: Minimum toolchain requirements

2025-03-27 Thread Oleksii Kurochko
On 3/27/25 4:45 PM, Andrew Cooper wrote: On 21/03/2025 4:24 pm, Oleksii Kurochko wrote: On 3/20/25 4:59 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 Kurochk

Re: [PATCH v1 3/3] xen: debug: gcov: add condition coverage support

2025-03-27 Thread Jan Beulich
On 27.03.2025 01:40, Volodymyr Babchuk wrote: > --- a/xen/Kconfig.debug > +++ b/xen/Kconfig.debug > @@ -44,6 +44,15 @@ config COVERAGE > > If unsure, say N here. > > +config CONDITION_COVERAGE > + bool "Condition coverage support" > + depends on COVERAGE && !CC_IS_CLANG > +

Re: [PATCH v1 1/3] xen: gcov: add support for gcc 14.1

2025-03-27 Thread Andrew Cooper
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 for it. >>> >>> Signed-off-by: Volodymyr Babchuk

RE: [PATCH v3 05/15] xen/x86: introduce "cpufreq=amd-cppc" xen cmdline

2025-03-27 Thread Penny, Zheng
[Public] Hi, > -Original Message- > From: Jan Beulich > Sent: Thursday, March 27, 2025 3:48 PM > To: Penny, Zheng > Cc: Huang, Ray ; Andrew Cooper > ; Anthony PERARD ; > Orzel, Michal ; Julien Grall ; Roger > Pau Monné ; Stefano Stabellini ; > xen-devel@lists.xenproject.org > Subject: R

Re: linux-next: duplicate patches in the xen-tip tree

2025-03-27 Thread Stephen Rothwell
Hi Stephen, On Wed, 26 Mar 2025 09:03:10 +1100 Stephen Rothwell wrote: > > The following commits are also in Linus Torvalds' tree as different > commits (but the same patches): > > d9f2164238d8 ("PCI/MSI: Convert pci_msi_ignore_mask to per MSI domain flag") > cae5129fccb1 ("PCI: vmd: Disabl

Re: [xen-tip:linux-next 12/12] WARNING: modpost: vmlinux: section mismatch in reference: mc_debug_data+0x0 (section: .data) -> mc_debug_data_early (section: .init.data)

2025-03-27 Thread Borislav Petkov
On Thu, Mar 27, 2025 at 04:15:11PM +0100, Jürgen Groß wrote: > Another approach could be to have: > > -static DEFINE_PER_CPU(struct mc_debug_data *, mc_debug_data) = > - &mc_debug_data_early; > +static DEFINE_PER_CPU(struct mc_debug_data *, mc_debug_data); > > and to use an inline access func

Re: [PATCH] trace: convert init_trace_bufs() to constructor

2025-03-27 Thread Julien Grall
Hi Jan, On 27/03/2025 15:08, Jan Beulich wrote: On 27.03.2025 15:49, Julien Grall wrote: On 13/03/2025 13:38, Jan Beulich wrote: There's no need for each arch to invoke it directly, and there's no need for having a stub either. With the present placement of the calls to init_constructors() it

Re: [PATCH v2 1/4] xen/riscv: introduce preinit_xen_time()

2025-03-27 Thread Jan Beulich
On 26.03.2025 20:49, Oleksii Kurochko wrote: > On 3/26/25 4:13 PM, Jan Beulich wrote: >> On 25.03.2025 18:36, Oleksii Kurochko wrote: >>> +/* Set up the timer on the boot CPU (early init function) */ >>> +static void __init preinit_dt_xen_time(void) >>> +{ >>> +static const struct dt_device_mat

Re: [PATCH] x86/CPU: don't hard-code MTRR availability

2025-03-27 Thread Roger Pau Monné
On Thu, Mar 27, 2025 at 10:59:58AM +0100, Jan Beulich wrote: > On 27.03.2025 10:50, Roger Pau Monné wrote: > > On Thu, Mar 27, 2025 at 10:15:03AM +0100, Jan Beulich wrote: > >> On 27.03.2025 09:21, Roger Pau Monné wrote: > >>> On Tue, Mar 25, 2025 at 08:18:11AM +0100, Jan Beulich wrote: > In p

Re: [PATCH] trace: convert init_trace_bufs() to constructor

2025-03-27 Thread Julien Grall
Hi Jan, On 13/03/2025 13:38, Jan Beulich wrote: There's no need for each arch to invoke it directly, and there's no need for having a stub either. With the present placement of the calls to init_constructors() it can easily be a constructor itself. Signed-off-by: Jan Beulich Acked-by: Julien

Re: [PATCH] trace: convert init_trace_bufs() to constructor

2025-03-27 Thread Jan Beulich
On 27.03.2025 15:49, Julien Grall wrote: > On 13/03/2025 13:38, Jan Beulich wrote: >> There's no need for each arch to invoke it directly, and there's no need >> for having a stub either. With the present placement of the calls to >> init_constructors() it can easily be a constructor itself. >> >>

[PATCH v2] CHANGELOG: Minimum toolchain requirements for x86 and ARM

2025-03-27 Thread Andrew Cooper
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 v2: * State x86 and ARM, rather than implying all architectures. --- CHANGELOG.md | 3 +++ 1 file changed, 3 insertions(+)

Re: [PATCH 1/6] SUPPORT.md: make Linux based stubdom fully supported

2025-03-27 Thread Jan Beulich
On 27.03.2025 16:25, Juergen Gross wrote: > On 26.03.25 17:04, Juergen Gross wrote: >> All patches needed for running with a Linux stubdom device model are >> in the tree and QubesOS is using and testing Linux stubdoms nowadays. >> >> Switch support from "Tech Preview" to "Supported". >> >> Signed-

[PATCH v2] Xen: Update compiler checks

2025-03-27 Thread Andrew Cooper
We have checks in both xen/compiler.h, and Config.mk. Both are incomplete. Remove the one from compiler.h, as it's pointless to perform in addition to the xen.git-wide one as well. Expand the checks to cover RISCV wanting GCC 11.1, and to cover Clang on x86. PPC still is unspecified, and inherit

Re: [PATCH] x86/MTRR: constrain AP sync and BSP restore

2025-03-27 Thread Roger Pau Monné
On Thu, Mar 27, 2025 at 10:54:23AM +0100, Jan Beulich wrote: > mtrr_set_all() has quite a bit of overhead, which is entirely useless > when set_mtrr_state() really does nothing. Furthermore, with > mtrr_state.def_type never initialized from hardware, post_set()'s > unconditional writing of the MSR

Re: [PATCH v2] x86/P2M: synchronize fast and slow paths of p2m_get_page_from_gfn()

2025-03-27 Thread Roger Pau Monné
On Tue, Mar 25, 2025 at 08:17:04AM +0100, Jan Beulich wrote: > Handling of both grants and foreign pages was different between the two > paths. > > While permitting access to grants would be desirable, doing so would > require more involved handling; undo that for the time being. In > particular t

[PATCH] xen: fix multicall debug feature

2025-03-27 Thread Juergen Gross
Initializing a percpu variable with the address of a struct tagged as .initdata is breaking the build with CONFIG_SECTION_MISMATCH_WARN_ONLY not set to "y". Fix that by using an access function instead returning the .initdata struct address if the percpu space of the struct hasn't been allocated y

Re: NULL pointer dereference in cpufreq_update_limits(?) under Xen PV dom0 - regression in 6.13

2025-03-27 Thread Marek Marczykowski-Górecki
On Thu, Mar 27, 2025 at 12:02:24PM +0100, Rafael J. Wysocki wrote: > cpufreq_update_limits() needs to ensure that the driver is there. > > The attached patch should address this issue, Marek please verify. Yes, it fixes the problem, thanks! -- Best Regards, Marek Marczykowski-Górecki Invisible

Re: [PATCH v1 1/3] xen: gcov: add support for gcc 14.1

2025-03-27 Thread Volodymyr Babchuk
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 for it. >> >> Signed-off-by: Volodymyr Babchuk > > As to the title - what about 14.2.0? Or the soon to

Re: [PATCH 2/6] docs: remove qemu-traditional support from documentation

2025-03-27 Thread Jan Beulich
On 26.03.2025 17:04, Juergen Gross wrote: > @@ -1903,10 +1894,7 @@ it may be useful to request a different one, like UEFI. > > =item B > > -Loads ROMBIOS, a 16-bit x86 compatible BIOS. This is used by default > -when B. This is the only BIOS > -option supported when B. This is > -the BIOS used

Re: [PATCH 0/6] remove qemu-traditional

2025-03-27 Thread Jan Beulich
On 26.03.2025 17:10, Andrew Cooper wrote: > On 26/03/2025 4:04 pm, Juergen Gross wrote: >> Remove the qemu-traditional support. This includes the Mini-OS >> based ioemu-stubdom. >> >> I _think_ rombios support could be removed, too, but this can be >> done in a second step. > > XenServer is still

Re: [PATCH v2] x86/P2M: synchronize fast and slow paths of p2m_get_page_from_gfn()

2025-03-27 Thread Roger Pau Monné
On Tue, Mar 25, 2025 at 08:17:04AM +0100, Jan Beulich wrote: > Handling of both grants and foreign pages was different between the two > paths. > > While permitting access to grants would be desirable, doing so would > require more involved handling; undo that for the time being. In > particular t

Re: [PATCH v1 2/3] xen: x86: irq: initialize irq desc in create_irq()

2025-03-27 Thread Nicola Vetrini
On 2025-03-27 09:37, Nicola Vetrini wrote: On 2025-03-27 09:03, Jan Beulich wrote: On 27.03.2025 01:40, 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’:

[XEN PATCH] CI: Change pipeline name for scheduled pipeline

2025-03-27 Thread Anthony PERARD
This description is already displayed on the web UI of the list of pipeline, but using it as "name" will make it available in webhooks as well and can be used by a bot. This doesn't change the behavior for other pipeline types, where the variable isn't set. Signed-off-by: Anthony PERARD --- Not

Re: NULL pointer dereference in cpufreq_update_limits(?) under Xen PV dom0 - regression in 6.13

2025-03-27 Thread Rafael J. Wysocki
On Thu, Mar 27, 2025 at 11:14 AM Jan Beulich wrote: > > On 27.03.2025 01:51, Marek Marczykowski-Górecki wrote: > > Hi, > > > > I've got a report[1] that 6.13.6 crashes as listed below. It worked fine in > > 6.12.11. We've tried few simple things to narrow the problem down, but > > without much suc

Re: [PATCH] x86/MTRR: constrain AP sync and BSP restore

2025-03-27 Thread Jan Beulich
On 27.03.2025 11:53, Roger Pau Monné wrote: > On Thu, Mar 27, 2025 at 10:54:23AM +0100, Jan Beulich wrote: >> mtrr_set_all() has quite a bit of overhead, which is entirely useless >> when set_mtrr_state() really does nothing. Furthermore, with >> mtrr_state.def_type never initialized from hardware,

[PATCH v2] xen/percpu: don't initialize percpu on resume

2025-03-27 Thread Mykola Kvach
From: Mykola Kvach 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>] enable

Re: [linux-next:master] [PCI/MSI] d9f2164238: Kernel_panic-not_syncing:Fatal_exception

2025-03-27 Thread Thomas Gleixner
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 > pci_msi_ignore_mask to per MSI domain flag") > https://git.kernel.org/cgit/linux/kernel/git/ne

Re: [PATCH v2] x86/P2M: synchronize fast and slow paths of p2m_get_page_from_gfn()

2025-03-27 Thread Roger Pau Monné
On Thu, Mar 27, 2025 at 10:24:02AM +0100, Jan Beulich wrote: > On 27.03.2025 10:00, Roger Pau Monné wrote: > > On Tue, Mar 25, 2025 at 08:17:04AM +0100, Jan Beulich wrote: > >> Handling of both grants and foreign pages was different between the two > >> paths. > >> > >> While permitting access to g

[PATCH] x86/MTRR: hook mtrr_bp_restore() back up

2025-03-27 Thread Jan Beulich
Unlike stated in the offending commit's description, load_system_tables() wasn't the only thing left to retain from the earlier restore_rest_processor_state(). While there also do Misra-related tidying for the function itself: The function being used from assembly only means it doesn't need to hav

Re: [PATCH v2 1/4] xen/riscv: introduce preinit_xen_time()

2025-03-27 Thread Jan Beulich
On 27.03.2025 12:48, Oleksii Kurochko wrote: > I think it can be left as it is now as if timebase-frequency will be u64 then > it means that it will be needed to read two u32 values and in this case > dt_property_read_u32() > will return 0 and the panic will occur. Fair enough; please say a word

Re: [PATCH] x86/MTRR: hook mtrr_bp_restore() back up

2025-03-27 Thread Jan Beulich
On 27.03.2025 12:38, Roger Pau Monné wrote: > On Thu, Mar 27, 2025 at 12:20:47PM +0100, Jan Beulich wrote: >> Unlike stated in the offending commit's description, >> load_system_tables() wasn't the only thing left to retain from the >> earlier restore_rest_processor_state(). >> >> While there also

[PATCH] libxc/PM: correct (not just) error handling in xc_get_cpufreq_para()

2025-03-27 Thread Jan Beulich
>From their introduction all xc_hypercall_bounce_pre() uses, when they failed, would properly cause exit from the function including cleanup, yet without informing the caller of the failure. Purge the unlock_1 label for being both pointless and mis-named. An earlier attempt to switch to the usual

Re: [PATCH v2 02/19] xen: introduce CONFIG_SYSCTL

2025-03-27 Thread Jan Beulich
On 26.03.2025 06:50, Penny Zheng wrote: > From: Stefano Stabellini > > We intend to introduces a new Kconfig CONFIG_SYSCTL, which shall only > be disabled on some dom0less systems, to reduce Xen footprint. Nit: "We intend to ..." takes about future work, yet the new control is ... > --- a/xen/c

Re: [PATCH v2] xen/percpu: don't initialize percpu on resume

2025-03-27 Thread Mykola Kvach
On Thu, Mar 27, 2025 at 1:32 PM Mykola Kvach wrote: > Hmm, looks like this line... > From: Mykola Kvach ...shouldn't be here > > 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] X

  1   2   >