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
[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
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
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 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
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
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
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)
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
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
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 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,
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
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 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
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 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
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 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 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 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 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: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 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 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 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 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
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 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.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"
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.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 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 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 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-
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 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
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 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
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 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.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 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.
>>
>>
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
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.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 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 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
On 27.03.25 15:13, Borislav Petkov wrote:
On Wed, Jul 24, 2024 at 11:55:39AM +0200, Jürgen Groß wrote:
I'd prefer a general way to handle this problem, like e.g. some kind of
__refdata tagging for percpu variables.
Any reason for not doing the trivial thing?
diff --git a/arch/x86/xen/multical
On Thu, Mar 27, 2025 at 03:32:14PM +0800, Jiqian Chen wrote:
> 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
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
>
> be7f0cc651d8 ARM/vgic: Fix out-of-bounds accesses in
On 27.03.2025 13:51, Oleksii Kurochko wrote:
>
> On 3/27/25 9:18 AM, Jan Beulich wrote:
>> 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
>>>
>>> +#
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 Pau Monné wrote:
> On Thu, Mar 27, 2025 at 1
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
be7f0cc651d8ARM/vgic: Fix out-of-bounds accesses in vgic_mmio_write_sgir()
and I'm further aware that there a
On 3/27/25 8:42 AM, Jan Beulich wrote:
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 co
On Wed, Jul 24, 2024 at 11:55:39AM +0200, Jürgen Groß wrote:
> I'd prefer a general way to handle this problem, like e.g. some kind of
> __refdata tagging for percpu variables.
Any reason for not doing the trivial thing?
diff --git a/arch/x86/xen/multicalls.c b/arch/x86/xen/multicalls.c
index 10c
Hello Linux mailing list !
For porting Linux code to make it work on Xen with AMD-SEV, I need to
change the allocation of some pages to use "shared pages" (C-bit
cleared) instead of private pages (C-bit set, which is the default kind)
as these pages needs to be shared with the hypervisor/Dom0.
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 Pau Monné wrote:
> >>> On Thu, Mar 27, 2025 at 12:20:47PM +0100, Jan Beulich wrote:
> Unli
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-off-by: Andrew Cooper
---
CC: Stefano Stabellini
CC: Juli
On 27.03.2025 13:53, Andrew Cooper wrote:
> On 27/03/2025 8:21 am, Jan Beulich wrote:
>> 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
-
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
>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 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 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_table
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/xen/config.h
>>> +++ b/xen/
On 3/27/25 05:00, Nicola Vetrini wrote:
> 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 w
On 27.03.2025 12:37, Mykola Kvach wrote:
> On Thu, Mar 27, 2025 at 1:32 PM Mykola Kvach wrote:
>>
>
> Hmm, looks like this line...
>
>> From: Mykola Kvach
>
> ...shouldn't be here
And instead it should be "From: Mykyta Poturai ", to
match ...
>> Invocation of the CPU_UP_PREPARE notification
On 27/03/2025 8:21 am, Jan Beulich wrote:
> 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/inclu
On 3/27/25 9:18 AM, Jan Beulich wrote:
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
On Thu, Mar 27, 2025 at 01:30:44PM +0100, Jan Beulich wrote:
> 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 t
On Thu, Mar 27, 2025 at 03:32:13PM +0800, Jiqian Chen wrote:
> 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.
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
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
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:27 AM Jan Beulich wrote:
>
> 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:25
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 do Misra-related tidying for the function itself:
On Thu, Mar 27, 2025 at 11:54:09AM +0100, Jan Beulich wrote:
> On 27.03.2025 11:38, Roger Pau Monné wrote:
> > 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:
> Hand
Hi,
On Thu, Mar 27, 2025 at 10:25 AM Jan Beulich wrote:
>
> 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] != INVALI
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
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 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:
>>> - Implementing the APLIC pre-initializati
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,
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 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/scripts/build
> > +++ b/automation/scripts/build
> > @@
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.
>
> Fixes: 5a281883cdc3 ("Hardcode many cpu features for x86/64 -- we know
> 64-bit")
> Sign
On 27.03.2025 11:38, Roger Pau Monné wrote:
> 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
>>>
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 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
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 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 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 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
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 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
1 - 100 of 129 matches
Mail list logo
