On Mon, Sep 1, 2025 at 8:02 PM Mykola Kvach wrote:
>
> Hi Jan,
>
> On Mon, Sep 1, 2025 at 5:29 PM Jan Beulich wrote:
> >
> > On 31.08.2025 00:10, Mykola Kvach wrote:
> > > --- a/xen/arch/ppc/stubs.c
> > > +++ b/xen/arch/ppc/stubs.c
> > > @@ -224,6 +224,11 @@ void arch_domain_creation_finished(str
On 02.09.2025 00:27, dmuk...@xen.org wrote:
> On Mon, Sep 01, 2025 at 10:14:04AM +0200, Jan Beulich wrote:
>> On 29.08.2025 21:27, Stefano Stabellini wrote:
>>> On Thu, 28 Aug 2025, dmuk...@xen.org wrote:
--- /dev/null
+++ b/xen/common/emul/vuart/vuart.c
@@ -0,0 +1,156 @@
+/* SP
Hi everyone,
This is the first commit in the second part of the patch series that
cannot exist without part 1. All previous commits are independent and
do not depend on part 1.
On Tue, Sep 2, 2025 at 1:10 AM Mykola Kvach wrote:
>
> From: Mirela Simonovic
>
> Trigger Xen suspend when the hardwar
From: Mykola Kvach
Add suspend/resume handling for GICv3 eSPI registers.
Signed-off-by: Mykola Kvach
---
Note: The main eSPI patch series is still under review.
This commit is intended to be applied after the main eSPI series:
[PATCH v5 00/12] Introduce eSPI support
https://patchew.org/Xen/cov
From: Mykola Kvach
If we call disable_nonboot_cpus on ARM64 with system_state set
to SYS_STATE_suspend, the following assertion will be triggered:
```
(XEN) [ 25.582712] Disabling non-boot CPUs ...
(XEN) [ 25.587032] Assertion '!in_irq() && (local_irq_is_enabled() ||
num_online_cpus() <= 1)
On Mon, Sep 01, 2025 at 11:47:59PM +0200, Marek Szyprowski wrote:
> I would like to give those patches a try in linux-next, but in meantime
> I tested it on my test farm and found a regression in dma_map_resource()
> handling. Namely the dma_map_resource() is no longer possible with size
> not a
On Fri, Aug 29, 2025 at 03:06:27PM -0700, Stefano Stabellini wrote:
> On Thu, 7 Aug 2025, dm...@proton.me wrote:
> > From: Denis Mukhin
> >
> > Introduce domain_console for grouping data structures used for integrating
> > domain's diagnostic console with Xen's console driver.
> >
> > Group all
FIO MMIO patches.
I waited a bit with a hope to get a comment from Robin. It looks that
there is no other alternative for the phys addr in the struct page
removal process.
I would like to give those patches a try in linux-next, but in meantime
I tested it on my test farm and found a regressi
On 01/09/2025 4:41 pm, Jan Beulich wrote:
> On 01.09.2025 17:33, Andrew Cooper wrote:
>> On 01/09/2025 10:28 am, Jan Beulich wrote:
>>> On 28.08.2025 17:03, Andrew Cooper wrote:
@@ -908,7 +909,29 @@ static void __init noreturn reinit_bsp_stack(void)
if ( cpu_has_xen_shstk )
Hi Volodymyr,
Thank you for your review and RB.
Unfortunately, the code contains an error related to offset calculation
for GICD_IROUTERnE, which was observed by Oleksandr. I will fix it in
V6, along with the formatting issues you discovered. I apologize for that.
On 29.08.25 23:12, Volodymyr B
This patch adds the basic framework for ARM SCI mediator. SCI is System
Control Interface, which is designed to redirect requests from the Domains
to ARM specific Firmware (for example SCMI). This will allow the devices,
passed-through to the different Domains, to access to the System resources
(su
Hello Oleksandr,
Thank you for your review and your good qestion.
On 01.09.25 15:38, Oleksandr Tyshchenko wrote:
>
>
> On 29.08.25 19:06, Leonid Komarianskyi wrote:
>
>
> Hello Leonid
>
>> Implemented support for GICv3.1 extended SPI registers for vGICv3,
>> allowing the emulation of eSPI-sp
Ever since it's introduction in commit 192df6f9122d ("x86: allow HVM guests to
use hypercalls to bring up vCPUs"), %cs.g/limit has been handled differently
to all other segments.
The hypercall takes full 32bit, and hvm_set_segment_register() fixes up all
segments .g to match the limit being 2^20 o
Hello Oleksandr,
Thank you for your review.
On 31.08.25 18:58, Oleksandr Tyshchenko wrote:
>
>
> On 29.08.25 23:45, Volodymyr Babchuk wrote:
>
> Hello Leonid, Volodymyr
>
>>
>> Hi Leonid,
>>
>> Leonid Komarianskyi writes:
>>
>>> This change introduces resource management in the VGIC to handl
On Mon, Sep 01, 2025 at 03:33:54PM +, Gerald Elder-Vass wrote:
> The existing Verify functionality of the Shim lock protocol is
> deprecated and will be removed, instead we must use the LoadImage
> interface to perform the verification.
But IIUC shim lock protocol isn't removed yet, and some p
On Mon, Sep 1, 2025 at 8:02 PM Mykola Kvach wrote:
>
> Hi Jan,
>
> On Mon, Sep 1, 2025 at 5:29 PM Jan Beulich wrote:
> >
> > On 31.08.2025 00:10, Mykola Kvach wrote:
> > > --- a/xen/arch/ppc/stubs.c
> > > +++ b/xen/arch/ppc/stubs.c
> > > @@ -224,6 +224,11 @@ void arch_domain_creation_finished(str
Hi Jan,
On Mon, Sep 1, 2025 at 5:29 PM Jan Beulich wrote:
>
> On 31.08.2025 00:10, Mykola Kvach wrote:
> > --- a/xen/arch/ppc/stubs.c
> > +++ b/xen/arch/ppc/stubs.c
> > @@ -224,6 +224,11 @@ void arch_domain_creation_finished(struct domain *d)
> > BUG_ON("unimplemented");
> > }
> >
> > +int
The Renesas R-Car Gen4 platform requires the GICv3 driver,
including support for the Interrupt Translation Service (ITS).
Without explicitly selecting GICV3, it was possible to create a
configuration with RCAR4=y and GICV3=n, leading to a build failure
due to unmet dependencies.
GICv3 driver (GIC
Hi,
On 01/09/2025 15:42, Leonid Komarianskyi wrote:
Taking into account that with CONFIG_GICV3_ESPI=n we should never have
"irq" in eSPI range, do you really need this #ifdef? I think that
ASSERT_UNREACHABLE in espi_to_desc() is sufficient guard.
Also, IRQ line number belongs to eSPI range rega
Hi Leonid,
On 29/08/2025 17:06, Leonid Komarianskyi wrote:
Currently, Xen does not support eSPI interrupts, leading
to a data abort when such interrupts are defined in the DTS.
This patch introduces a separate array to initialize up to
1024 interrupt descriptors in the eSPI range and adds the
n
On 29.08.2025 11:58, Teddy Astie wrote:
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -11,6 +11,7 @@ The format is based on [Keep a
> Changelog](https://keepachangelog.com/en/1.0.0/)
> - For x86, GCC 5.1 and Binutils 2.25, or Clang/LLVM 11
> - For ARM32 and ARM64, GCC 5.1 and Binutils 2.2
On 01/09/2025 10:23 am, Jan Beulich wrote:
> On 28.08.2025 17:03, Andrew Cooper wrote:
>> FRED and IDT differ by a Supervisor Token on the base of the shstk. This
>> means that the value they load into MSR_PL0_SSP differs by 8.
>>
>> s3_resume() in particular has logic which is otherwise invariant
On 29.08.2025 15:32, Teddy Astie wrote:
> Le 28/08/2025 à 14:30, Jan Beulich a écrit :
>> On 21.08.2025 17:25, Teddy Astie wrote:
>>> @@ -686,10 +691,31 @@ static int domain_construct_memmap(libxl__gc *gc,
>>> /* We always own at least one lowmem entry. */
>>> unsigned int e820_entries
Hi Leonid,
On 28/08/2025 17:17, Leonid Komarianskyi wrote:
On 28.08.25 15:00, Julien Grall wrote:
Hi Leonid,
On 27/08/2025 19:24, Leonid Komarianskyi wrote:
Currently, many common functions perform the same operations to calculate
GIC register addresses. This patch consolidates the similar co
On 28.08.2025 17:04, Andrew Cooper wrote:
> ERETU, unlike IRET, requires the sticky-1 bit (bit 2) be set, and reserved
> bits to be clear. Notably this means that dom0_construct() must set
> X86_EFLAGS_MBS it in order for a PV dom0 to start.
>
> Adjust arch_set_info_guest*() and hypercall_iret()
On 01/09/2025 10:46 am, Jan Beulich wrote:
> On 28.08.2025 17:03, Andrew Cooper wrote:
>> FRED provides %cr2 in the the stack frame, avoiding the need to read %cr2
>> manually.
>>
>> Rename do_page_fault() to handle_PF(), and update it to take cr2, still named
>> addr for consistency.
>>
>> Introdu
Hello Oleksandr and Volodymyr,
Thank you for your comments.
On 31.08.25 17:08, Oleksandr Tyshchenko wrote:
>
>
> On 29.08.25 22:45, Volodymyr Babchuk wrote:
>>
>> Hi Leonid,
>
> Hello Leonid
>
>>
>> Leonid Komarianskyi writes:
>>
>>> Currently, Xen does not support eSPI interrupts, leading
>
On 01.09.2025 16:31, Andrew Cooper wrote:
> On 01/09/2025 3:26 pm, Jan Beulich wrote:
>> Hmm, okay, it is of course in principle possible that one flavor is screwed
>> while the other isn't.
>>
>> Acked-by: Jan Beulich
>
> Thanks, but I now have both R-by and A-by you on this patch. Which
> woul
On 29.08.2025 16:13, Teddy Astie wrote:
> Le 28/08/2025 à 15:05, Jan Beulich a écrit :
>> On 26.06.2025 16:01, Teddy Astie wrote:
>>> Is it possible to have multiples vCPUs of a same domain simultaneously
>>> scheduled on top of a single pCPU ? If so, it would need a special
>>> consideration for t
Inroducing V7 patch series on top of the Xen version 4.20-rc2
which includes implementation of the SCI SCMI SMC single-agent support.
This patch series is the first chunk of the
"xen/arm: scmi: introduce SCI SCMI SMC multi-agent support" which can
be found at [0]
SCMI-multiagent support will b
From: Grygorii Strashko
The introduced SCI (System Control Interface) subsystem provides unified
interface to integrate in Xen SCI drivers which adds support for ARM
firmware (EL3, SCP) based software interfaces (like SCMI) that are used in
system management. The SCI subsystem allows to add drive
On 01/09/2025 3:26 pm, Jan Beulich wrote:
> On 01.09.2025 16:21, Andrew Cooper wrote:
>> On 27/08/2025 8:52 am, Jan Beulich wrote:
>>> On 26.08.2025 19:41, Andrew Cooper wrote:
--- a/xen/common/bitops.c
+++ b/xen/common/bitops.c
@@ -97,14 +97,14 @@ static void __init test_for_each_se
Currently Xen lacks a defined largest number of security IDs it can potentially
use. The number of SIDs are naturally limited by number of security contexts
provided by a given security policy, i.e. how many combination of user, role
and type there can be, and is dependant on the policy being used.
On 01.09.2025 16:21, Andrew Cooper wrote:
> On 27/08/2025 8:52 am, Jan Beulich wrote:
>> On 26.08.2025 19:41, Andrew Cooper wrote:
>>> --- a/xen/common/bitops.c
>>> +++ b/xen/common/bitops.c
>>> @@ -97,14 +97,14 @@ static void __init test_for_each_set_bit(void)
>>> if ( ui != ui_res )
>>>
On 27/08/2025 8:52 am, Jan Beulich wrote:
> On 26.08.2025 19:41, Andrew Cooper wrote:
>> --- a/xen/common/bitops.c
>> +++ b/xen/common/bitops.c
>> @@ -97,14 +97,14 @@ static void __init test_for_each_set_bit(void)
>> if ( ui != ui_res )
>> panic("for_each_set_bit(uint) expected %#x, g
On 29.08.2025 11:58, Teddy Astie wrote:
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -34,6 +34,7 @@ The format is based on [Keep a
> Changelog](https://keepachangelog.com/en/1.0.0/)
> - Support in hvmloader for new SMBIOS tables: 7 (Cache Info), 8 (Port
> Connector), 9 (System Slots),
On 01.09.2025 15:27, Andrew Cooper wrote:
> On 01/09/2025 1:57 pm, Jan Beulich wrote:
>> On 28.08.2025 17:04, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/traps.c
>>> +++ b/xen/arch/x86/traps.c
>>> @@ -2265,9 +2265,83 @@ void asmlinkage check_ist_exit(const struct
>>> cpu_user_regs *regs, bool ist_
From: Grygorii Strashko
Add documentation section for Simple Arm SCMI over SMC calls forwarding
driver (EL3).
Signed-off-by: Grygorii Strashko
Signed-off-by: Oleksii Moisieiev
---
Changes in v7:
- fixed typos
Changes in v6:
- add link to the scmi bindings used in the doc
- remove mentions ab
From: Grygorii Strashko
The commit 3e322bef8bc0 ("xen/arm: firmware: Add SCMI over SMC calls
handling layer") introduces simple driver which forwards SCMI over SMC
calls from hwdom/dom0 to EL3 firmware (TF-A) with a single SCMI OSPM agent
support. While it is working gracefully for hwdom/dom0 use
Hi Michal,
On 01/09/2025 14:17, Orzel, Michal wrote:
On 01/09/2025 14:31, Ayan Kumar Halder wrote:
Xen gives a panic if certain nodes are not present in the device tree. In order
to prevent this panic, scripts/dt_sanity.py is written so that it checks if the
node/s are present. If the node/s a
On 28.08.2025 17:04, Andrew Cooper wrote:
> Under FRED, entry_from_pv() handles everything, even system calls. This means
> more of our logic is written in C now, rather than assembly.
>
> In order to facilitate this, introduce pv_inject_callback(), which reuses
> struct trap_bounce infrastructur
On 8/29/25 11:58 AM, Teddy Astie wrote:
xen_domain_handle_t is defined as a opaque 16-bytes blob, but is
commonly used by toolstack and guest as a big-endian encoded and
formatted UUID (alike RFC 9562).
Clarify the definition of the type to ensure the guest and toolstack
interprets this value c
On 01/09/2025 14:31, Ayan Kumar Halder wrote:
> Xen gives a panic if certain nodes are not present in the device tree. In
> order
> to prevent this panic, scripts/dt_sanity.py is written so that it checks if
> the
> node/s are present. If the node/s are not present, the script gives an error.
On 28.08.2025 17:03, Andrew Cooper wrote:
> @@ -20,6 +22,9 @@ unsigned int __ro_after_init ler_msr;
> static bool __initdata opt_ler;
> boolean_param("ler", opt_ler);
>
> +int8_t __ro_after_init opt_fred = 0;
Can't this be __initdata now that we have ...
> @@ -299,6 +304,37 @@ void __init tra
On 28.08.2025 17:04, Andrew Cooper wrote:
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -2345,6 +2345,113 @@ void asmlinkage entry_from_pv(struct cpu_user_regs
> *regs)
> fatal_trap(regs, false);
> }
>
> +void nocall eretu_error_dom_crash(void);
> +
> +/*
> + * Classify an
On 28.08.2025 17:04, Andrew Cooper wrote:
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -2265,9 +2265,83 @@ void asmlinkage check_ist_exit(const struct
> cpu_user_regs *regs, bool ist_exit)
>
> void asmlinkage entry_from_pv(struct cpu_user_regs *regs)
> {
> +struct fred_in
On 29.08.25 10:56, Mark Syms wrote:
Previously this said it would only happen on barrier writes. Except
the documentation blocks for
* feature-flush-cache
* feature-discard
Also say that they can return this error.
Signed-off-by: Mark Syms
Reviewed-by: Juergen Gross
Juergen
OpenPGP_
On 28.08.2025 17:04, Andrew Cooper wrote:
> When FRED is active, hardware automatically swaps GS when changing privilege,
> and the SWAPGS instruction is disallowed.
>
> For native OSes using GS as the thread local pointer this is a massive
> improvement on the pre-FRED architecture, but under Xen
On 01/09/2025 13:19, Jan Beulich wrote:
> On 01.09.2025 12:43, Michal Orzel wrote:
>> Commit e3ed540f2e9f was meant to make AMD_SVM dependent on AMD and
>> INTEL_VMX on INTEL. Such dependency should be done using 'depends on'
>> and not 'if' next to prompt that deals only with the visibility of
On 28.08.2025 17:04, Andrew Cooper wrote:
> It is no longer used.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
On 28.08.2025 17:04, Andrew Cooper wrote:
> It's soon going to be needed in a second location.
>
> Right now it's misleading saying that nothing else would be cleared. It's
> missing the more important point that SYSCALLs are treated like all other
> interrupts and exceptions, and undergo normal
On 01.09.2025 13:25, Orzel, Michal wrote:
>
>
> On 01/09/2025 13:19, Jan Beulich wrote:
>> On 01.09.2025 12:43, Michal Orzel wrote:
>>> Commit e3ed540f2e9f was meant to make AMD_SVM dependent on AMD and
>>> INTEL_VMX on INTEL. Such dependency should be done using 'depends on'
>>> and not 'if' nex
On 28.08.2025 17:04, Andrew Cooper wrote:
> Right now we have two IRET instructions that can fault for guest reasons, and
> the pre exception table gives handle_exception as the fixup for both.
>
> Instead, we can have compat_restore_all_guest() use restore_all_guest()'s IRET
> which gives us just
On 01/09/2025 9:33 am, Jan Beulich wrote:
> On 29.08.2025 18:17, Andrew Cooper wrote:
>> This is a port of Linux commit 517234446c1a ("x86/apic: Get rid of
>> get_physical_broadcast()") to Xen. Thomas Gleixner notes:
>>
>> There is no point for this function. The only case where this is used is
On 28.08.2025 17:04, Andrew Cooper wrote:
> This is really a rearrangement to make adding FRED support easier.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Roger Pau Monné
>
> v2:
> * New
>
> There is a marginal code size improvement:
>
> add/r
On 01.09.2025 12:43, Michal Orzel wrote:
> Commit e3ed540f2e9f was meant to make AMD_SVM dependent on AMD and
> INTEL_VMX on INTEL. Such dependency should be done using 'depends on'
> and not 'if' next to prompt that deals only with the visibility of the
> given Kconfig option. This makes it imposs
On 01.09.2025 13:03, Andrew Cooper wrote:
> On 01/09/2025 9:33 am, Jan Beulich wrote:
>> On 29.08.2025 18:17, Andrew Cooper wrote:
>>> This is a port of Linux commit 517234446c1a ("x86/apic: Get rid of
>>> get_physical_broadcast()") to Xen. Thomas Gleixner notes:
>>>
>>> There is no point for th
On Fri, Aug 29, 2025 at 09:56:27AM +0100, Mark Syms wrote:
> Previously this said it would only happen on barrier writes. Except
> the documentation blocks for
> * feature-flush-cache
> * feature-discard
I cannot parse what "documentation blocks" means in this context. I
would maybe write this
On 01/09/2025 12:02 pm, Jan Beulich wrote:
> On 01.09.2025 12:31, Andrew Cooper wrote:
>> On 01/09/2025 9:56 am, Jan Beulich wrote:
>>> With the processing done linearly (rather than recursively), checking
>>> whether any of the features was previously seen is wrong: That would
>>> e.g. trigger for
On 01/09/2025 11:26, Dmytro Prokopchuk1 wrote:
> Fix an issue in the 'fail:' cleanup path of the 'assign_shared_memory()'
> function where the use of an unsigned long 'i' with the condition
> '--i >= 0' caused an infinite loop. Update the loop to use 'i--',
> ensuring correct loop termination.
>
On 28.08.2025 17:04, Andrew Cooper wrote:
> With the shadow stack and exception handling adjustements in place, we can now
> activate FRED when appropriate. Note that opt_fred is still disabled by
> default.
>
> Introduce init_fred() to set up all the MSRs relevant for FRED. FRED uses
> MSR_STAR
Commit e3ed540f2e9f was meant to make AMD_SVM dependent on AMD and
INTEL_VMX on INTEL. Such dependency should be done using 'depends on'
and not 'if' next to prompt that deals only with the visibility of the
given Kconfig option. This makes it impossible to e.g. disable INTEL_VMX
when INTEL is disa
On 28.08.2025 17:03, Andrew Cooper wrote:
> Under FRED, there's one entrypoint from Ring 3, and one from Ring 0.
>
> FRED gives us a good stack (even for SYSCALL/SYSENTER), and a unified event
> frame on the stack, meaing that all software needs to do is spill the GPRs
> with a line of PUSHes. In
On 29.08.2025 18:17, Andrew Cooper wrote:
> It is not obvious at first glance, but this is dead logic.
>
> On Intel, xAPIC (which is what modern_apic() is really checking for) predates
> 64bit support, while the Family 0xf check on AMD is the K8 processor.
>
> Simply drop the logic, rather than t
Fix an issue in the 'fail:' cleanup path of the 'assign_shared_memory()'
function where the use of an unsigned long 'i' with the condition
'--i >= 0' caused an infinite loop. Update the loop to use 'i--',
ensuring correct loop termination.
This change adheres to MISRA C Rule 14.3: "Controlling exp
On 28.08.2025 17:03, Andrew Cooper wrote:
> FRED doesn't use Supervisor Shadow Stack tokens. Skip setting them up.
>
> Signed-off-by: Andrew Cooper
In principle
Reviewed-by: Jan Beulich
However, ...
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -1920,10 +1920,6 @@ void asmli
On 28.08.2025 17:03, Andrew Cooper wrote:
> FRED and IDT differ by a Supervisor Token on the base of the shstk. This
> means that switch_stack_and_jump() needs to discard one extra word when FRED
> is active.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
However, I'd much prefer i
With the processing done linearly (rather than recursively), checking
whether any of the features was previously seen is wrong: That would
e.g. trigger for this simple set of dependencies
X: [A, B]
A: [C]
B: [C]
(observed in reality when making AMX-AVX512 dependent upon both
AMX-TILE
On 28.08.2025 17:03, Andrew Cooper wrote:
> @@ -908,7 +909,29 @@ static void __init noreturn reinit_bsp_stack(void)
> if ( cpu_has_xen_shstk )
> {
> wrmsrl(MSR_S_CET, xen_msr_s_cet_value());
> -asm volatile ("setssbsy" ::: "memory");
> +
> +/*
> + * IDT an
On 29/08/2025 17:42, Oleksandr Tyshchenko wrote:
>
>
> On 28.08.25 19:40, Oleksii Moisieiev wrote:
>
>
> Hello Oleksii
>
> the patch lgtm, just some comments
>
>> From: Grygorii Strashko
>>
>> The introduced SCI (System Control Interface) subsystem provides unified
>> interface to integrate in X
On 29.08.2025 21:29, Andrew Cooper wrote:
> Jan reports the following exception when using the cycle debugging:
>
> Feature IBRSB, seen [IBRSB, STIBP, INTEL_PSFD, EIBRS, IPRED_CTRL,
> RRSBA_CTRL, RRSBA, BHI_CTRL], to_process [SSBD]
> Traceback (most recent call last):
> File "/local/xen.g
On 29.08.2025 21:27, Stefano Stabellini wrote:
> On Thu, 28 Aug 2025, dmuk...@xen.org wrote:
>> --- /dev/null
>> +++ b/xen/common/emul/vuart/vuart.c
>> @@ -0,0 +1,156 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +/*
>> + * UART emulator framework.
>> + *
>> + * Copyright 2025 Ford Motor Co
On 01.09.2025 05:21, Penny, Zheng wrote:
> [Public]
>
>> -Original Message-
>> From: Jan Beulich
>> Sent: Friday, August 29, 2025 2:12 PM
>> To: Penny, Zheng
>> Cc: Huang, Ray ; Andrew Cooper
>> ; Roger Pau Monné ;
>> Anthony PERARD ; Orzel, Michal
>> ; Julien Grall ; Stefano Stabellini
On 30.08.2025 17:23, Sergiy Kibrik wrote:
> 29.08.25 14:44, Jan Beulich:
>> On 29.08.2025 13:33, Sergiy Kibrik wrote:
>>> 25.08.25 15:00, Jan Beulich:
On 22.08.2025 11:51, Sergiy Kibrik wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
I wonder whether we wouldn't
74 matches
Mail list logo
