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
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
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
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
When booting from U-Boot bootefi, there can be a high number of
neighboring RAM banks. See for example:
(XEN) RAM: - 00bf
(XEN) RAM: 00c0 - 00c00fff
(XEN) RAM: 00c01000 - 00df
(XEN) RAM: 00e0 - 0279dfff
(XEN)
Hi 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
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
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
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
--
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
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
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.
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
[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
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
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
[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
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
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.
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
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
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
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
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
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
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
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
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:
>
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
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
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
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
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
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;
> +
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
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]
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
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:
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
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
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
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
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
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
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
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
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
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 |
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
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
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
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
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
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"
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
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
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
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
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,
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
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
>> -
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
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
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
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
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
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
> +
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
[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
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
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
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
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
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
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
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.
>>
>>
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(+)
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-
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
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
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
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
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
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
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
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
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
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’:
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
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
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,
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
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
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
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
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
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
>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
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
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 - 100 of 129 matches
Mail list logo
