From: Xenia Ragiadakou
Provide the user with configuration control over the cpu virtualization support
in Xen by making SVM and VMX options user selectable.
To preserve the current default behavior, both options depend on HVM and
default to Y.
To prevent users from unknowingly disabling virtual
Hi Julien, John,
> Subject: Re: [PATCH v4 1/3] xen/arm: Add imx8q{m,x} platform glue
>
> Hi John,
>
> On 15/04/2024 12:17, John Ernberg wrote:
> > Hi Julien,
> >
> > On 4/15/24 1:03 PM, Julien Grall wrote:
> >>
> >>
> >> On 15/04/2024 11:50, Andrew Cooper wrote:
> >>> On 15/04/2024 11:25 am, Julie
From: Xenia Ragiadakou
VIO_realmode_completion is specific to vmx realmode, so guard the completion
handling code with CONFIG_VMX. Also, guard VIO_realmode_completion itself by
CONFIG_VMX, instead of generic CONFIG_X86.
No functional change intended.
Signed-off-by: Xenia Ragiadakou
Signed-off-
From: Xenia Ragiadakou
To be able to use cpu_has_{svm/vmx}_* macros in common code without enclosing
them inside #ifdef guards when the respective virtualization technology is
not enabled, define corresponding helper routines as false when not applicable.
No functional change intended.
Signed-o
Instead of directly accessing control variables from vmcs macros let
intermediate helper routine vmx_ctrl_has_feature() do it. This way
we can turn all the VMX-related macros off, if building for non VT-d platform,
by tweaking only a single helper's function behaviour.
No functional change intende
From: Xenia Ragiadakou
The symbol svm_stgi_label is AMD-V specific so guard its usage in common code
with CONFIG_SVM.
Since SVM depends on HVM, it can be used alone.
Also, use #ifdef instead of #if.
No functional change intended.
Signed-off-by: Xenia Ragiadakou
Signed-off-by: Sergiy Kibrik
A
From: Xenia Ragiadakou
The functions svm_load_segs() and svm_load_segs_prefetch() are AMD-V specific
so guard their calls in common code with CONFIG_SVM.
Since SVM depends on HVM, it can be used alone.
No functional change intended.
Signed-off-by: Xenia Ragiadakou
Signed-off-by: Sergiy Kibrik
From: Xenia Ragiadakou
The functions vmx_vmcs_enter() and vmx_vmcs_exit() are VT-x specific.
Guard their calls with CONFIG_VMX.
No functional change intended.
Signed-off-by: Xenia Ragiadakou
Signed-off-by: Sergiy Kibrik
---
xen/arch/x86/traps.c | 8 ++--
1 file changed, 2 insertions(+),
Build AMD vPMU when CONFIG_SVM is on, and Intel vPMU when CONFIG_VMX is on
respectively, allowing for a plaftorm-specific build. Also separate
arch_vpmu_ops initializers using these options and static inline stubs.
No functional change intended.
Signed-off-by: Sergiy Kibrik
---
xen/arch/x86/cpu
From: Xenia Ragiadakou
The functions ept_p2m_init() and ept_p2m_uninit() are VT-x specific.
Do build-time checks and skip these functions execution when !VMX.
No functional change intended.
Signed-off-by: Xenia Ragiadakou
Signed-off-by: Sergiy Kibrik
---
xen/arch/x86/mm/p2m-basic.c | 4 ++--
Instead of using generic CONFIG_HVM option switch to a bit more specific
CONFIG_VMX option for altp2m support, as it depends on VMX. Also guard
altp2m routines, so that it can be disabled completely in the build.
Signed-off-by: Sergiy Kibrik
---
xen/arch/x86/include/asm/altp2m.h | 5 -
xen
Move altp2m code from generic p2m.c file to altp2m.c, so that VMX-specific
code is kept separately and can possibly be disabled in the build.
No functional change intended.
Signed-off-by: Sergiy Kibrik
---
xen/arch/x86/mm/altp2m.c | 631 ++
xen/arch/x86/mm/p2
Hi Julien,
> On 15 Apr 2024, at 19:41, Julien Grall wrote:
>
> Hi Luca,
>
> On 09/04/2024 12:45, Luca Fancellu wrote:
>> Currently Xen is not exporting the static shared memory regions
>> to the device tree as /memory node, this commit is fixing this
>> issue.
>> The static shared memory banks
Initialize and bring down altp2m only when it is supported by the platform,
i.e. VMX. The puspose of that is the possiblity to disable VMX support and
exclude its code from the build completely.
Signed-off-by: Sergiy Kibrik
---
xen/arch/x86/mm/p2m-basic.c | 19 +++
1 file changed
Use altp2m index only when it is supported by the platform, i.e. VMX.
The puspose of that is the possiblity to disable VMX support and
exclude its code from the build completely.
Signed-off-by: Sergiy Kibrik
---
xen/arch/x86/hvm/monitor.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
From: Xenia Ragiadakou
Since start_svm() is AMD-V specific while start_vmx() is Intel VT-x specific,
one can be excluded from build completely with CONFIG_SVM and CONFIG_VMX,
respectively.
No functional change intended.
Signed-off-by: Xenia Ragiadakou
Signed-off-by: Sergiy Kibrik
---
xen/arc
From: Xenia Ragiadakou
Introduce two new Kconfig options, SVM and VMX, to allow code
specific to each virtualization technology to be separated and, when not
required, stripped.
CONFIG_SVM will be used to enable virtual machine extensions on platforms that
implement the AMD Virtualization Technol
This series aims to continue what Xenia started a year ago:
https://lore.kernel.org/xen-devel/20230213145751.1047236-1-burzalod...@gmail.com/
Here's an attempt to provide a means to render the cpu virtualization
technology support in Xen configurable.
Currently, irrespectively of the target platf
flight 185623 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185623/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 185287
test-amd64-amd64-qemuu-nested-amd 20 debi
flight 185622 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185622/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-vhd 12 debian-di-installfail REGR. vs. 185281
test-amd64-amd64-x
flight 185624 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185624/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5ba3602e4580d6b65dacf4292a031627f93e1167
baseline version:
ovmf 98f150a954b35cc74bd87
On Mon, 15 Apr 2024, Andrew Cooper wrote:
> RFC. In theory this is a great way to avoid some of the spiketraps involved
> with C being the official representation.
>
> However, this doesn't build. gnttab_transfer has a layout that requires a
> CONFIG_COMPAT if we want to satisfy -Wpadding for bo
On Mon, 15 Apr 2024, Andrew Cooper wrote:
> This subop appears to have been missed from the compat checks.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: George Dunlap
> CC: Jan Beulich
> CC: Stefano Stabellini
> CC: Julien Grall
> ---
> xen/common/compat/grant_table.c | 4
> xen/include/
On Mon, 15 Apr 2024, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
Reviewed-by: Stefano Stabellini
On Mon, 15 Apr 2024, Andrew Cooper wrote:
> * Fix tabs/spaces mismatch for certain rows
> * Insert lines between header files to improve legibility
>
> Signed-off-by: Andrew Cooper
> ---
> CC: George Dunlap
> CC: Jan Beulich
> CC: Stefano Stabellini
> CC: Julien Grall
> ---
> xen/include/x
flight 185617 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185617/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-pvops
flight 185527 xen-4.18-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185527/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-prev
flight 185616 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185616/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-pvops
Hi Luca,
On 09/04/2024 12:45, Luca Fancellu wrote:
Currently Xen is not exporting the static shared memory regions
to the device tree as /memory node, this commit is fixing this
issue.
The static shared memory banks can be part of the memory range
available for the domain, so if they are overla
flight 185603 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185603/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-pvops
flight 185604 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185604/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-pvops
flight 185597 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185597/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-prev
On 15/04/2024 10:56 am, Federico Serafini wrote:
> Mark the whole gzip folder as adopted code and remove the redundant
> deviation of file inflate.
>
> Signed-off-by: Federico Serafini
Acked-by: Andrew Cooper
I hadn't realised that we had a special case like this. Definitely
better to get rid
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Jan Beulich
CC: Stefano Stabellini
CC: Julien Grall
---
xen/include/xlat.lst | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index
This started off as patch 3, and grew somewhat.
Patches 1-3 are simple and hopefully non-controversial.
Patch 4 is an attempt to make the headers less fragile, but came with an
unexpected complication. Details in the patch.
Andrew Cooper (4):
xen/xlat: Sort out whitespace
xen/xlat: Sort str
This subop appears to have been missed from the compat checks.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Jan Beulich
CC: Stefano Stabellini
CC: Julien Grall
---
xen/common/compat/grant_table.c | 4
xen/include/xlat.lst| 1 +
2 files changed, 5 insertions(+)
dif
RFC. In theory this is a great way to avoid some of the spiketraps involved
with C being the official representation.
However, this doesn't build. gnttab_transfer has a layout that requires a
CONFIG_COMPAT if we want to satisfy -Wpadding for both forms of the structure.
Thoughts on whether this
* Fix tabs/spaces mismatch for certain rows
* Insert lines between header files to improve legibility
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Jan Beulich
CC: Stefano Stabellini
CC: Julien Grall
---
xen/include/xlat.lst | 31 +++
1 file changed, 27
flight 185556 xen-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185556/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-prev
flight 185536 xen-4.17-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185536/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-prev
On 15/04/2024 3:14 pm, George Dunlap wrote:
> Hey all,
>
> Some of you may have noticed that xenbis.xenproject.org/xsa/ doesn't
> currently list XSA-456. This has prompted me to rewrite the perl code
> which generates that area of the webpage into golang, which is much
> easier for the current sec
Reporting whether the BHB clearing on entry is done for the different domains
types based on cpu_has_bhb_seq is incorrect, as that variable signals whether
there's a BHB clearing sequence selected, but that alone doesn't imply that
such sequence is used from the PV and/or HVM entry points.
Instead
Hey all,
Some of you may have noticed that xenbis.xenproject.org/xsa/ doesn't
currently list XSA-456. This has prompted me to rewrite the perl code
which generates that area of the webpage into golang, which is much
easier for the current security team to understand and modify. The
draft replace
Le 15/04/2024 à 14:15, Teddy Astie a écrit :
> All hardware that supports VT-d/AMD-Vi that exists also supports cx16 (aside
> specifically crafted virtual machines).
>
> Some IOMMU code paths in Xen consider cases where VT-d/AMD-Vi is supported
> while cx16 isn't, those paths may be bugged and are
On Mon, 15 Apr 2024 13:03:30 +
Michael Kelley wrote:
> From: Petr Tesařík Sent: Monday, April 15, 2024 5:50 AM
> >
> > On Mon, 15 Apr 2024 12:23:22 +
> > Michael Kelley wrote:
> >
> > > From: Petr Tesařík Sent: Monday, April 15, 2024 4:46
> > > AM
> > > >
> > > > Hi Michael,
> >
flight 185595 linux-6.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185595/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-pvops
From: Petr Tesařík Sent: Monday, April 15, 2024 5:50 AM
>
> On Mon, 15 Apr 2024 12:23:22 +
> Michael Kelley wrote:
>
> > From: Petr Tesařík Sent: Monday, April 15, 2024 4:46 AM
> > >
> > > Hi Michael,
> > >
> > > sorry for taking so long to answer. Yes, there was no agreement on the
> > >
On Mon, 15 Apr 2024 12:23:22 +
Michael Kelley wrote:
> From: Petr Tesařík Sent: Monday, April 15, 2024 4:46 AM
> >
> > Hi Michael,
> >
> > sorry for taking so long to answer. Yes, there was no agreement on the
> > removal of the "dir" parameter, but I'm not sure it's because of
> > symmetr
From: Petr Tesařík Sent: Monday, April 15, 2024 4:46 AM
>
> Hi Michael,
>
> sorry for taking so long to answer. Yes, there was no agreement on the
> removal of the "dir" parameter, but I'm not sure it's because of
> symmetry with swiotlb_sync_*(), because the topic was not really
> discussed.
>
All hardware with AMD-Vi has CMPXCHG16 support. Check this at initialisation
time, and remove the effectively-dead logic for the non-cx16 case.
Suggested-by: Andrew Cooper
Signed-off-by: Teddy Astie
---
xen/drivers/passthrough/amd/iommu_map.c | 42 +++--
xen/drivers/passthro
All hardware with VT-d has CMPXCHG16B support. Check this at initialisation
time, and remove the effectively-dead logic for the non-cx16 case.
Suggested-by: Andrew Cooper
Signed-off-by: Teddy Astie
---
xen/drivers/passthrough/vtd/iommu.c | 73 ++---
1 file changed, 25 in
This flag was only used in case cx16 is not available, as those code paths no
longer exist, this flag now does basically nothing.
Signed-off-by: Teddy Astie
---
xen/drivers/passthrough/vtd/iommu.c | 12 +++-
xen/drivers/passthrough/vtd/vtd.h | 5 ++---
2 files changed, 5 insertions(+)
All hardware with AMD-Vi has CMPXCHG16 support. Check this at initialisation
time, and remove the effectively-dead logic for the non-cx16 case.
Suggested-by: Andrew Cooper
Signed-off-by: Teddy Astie
---
xen/drivers/passthrough/amd/iommu_intr.c | 6 ++
1 file changed, 6 insertions(+)
diff
All hardware that supports VT-d/AMD-Vi that exists also supports cx16 (aside
specifically crafted virtual machines).
Some IOMMU code paths in Xen consider cases where VT-d/AMD-Vi is supported
while cx16 isn't, those paths may be bugged and are barely tested, dead code
in practice.
Disable IOMMU i
All hardware with VT-d has CMPXCHG16B support. Check this at initialisation
time, and remove the effectively-dead logic for the non-cx16 case.
Suggested-by: Andrew Cooper
Signed-off-by: Teddy Astie
---
xen/drivers/passthrough/vtd/intremap.c | 70 --
xen/drivers/passthro
Hi John,
On 15/04/2024 12:17, John Ernberg wrote:
Hi Julien,
On 4/15/24 1:03 PM, Julien Grall wrote:
On 15/04/2024 11:50, Andrew Cooper wrote:
On 15/04/2024 11:25 am, Julien Grall wrote:
Hi John,
I saw this patch was committed. I have one question this may require
some adjustment.
On 08/
On Sun, 7 Apr 2024 21:11:41 -0700
mhkelle...@gmail.com wrote:
> From: Michael Kelley
>
> Currently swiotlb_tbl_map_single() takes alloc_align_mask and
> alloc_size arguments to specify an swiotlb allocation that is
> larger than mapping_size. This larger allocation is used solely
> by iommu_dma
flight 185577 linux-5.4 running [real]
http://logs.test-lab.xenproject.org/osstest/logs/185577/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-pvops
Hi Julien,
> On 15 Apr 2024, at 12:08, Julien Grall wrote:
>
> Hi Bertrand,
>
> On 15/04/2024 08:48, Bertrand Marquis wrote:
>> Hi Julien,
>>> On 12 Apr 2024, at 19:01, Julien Grall wrote:
>>>
>>>
>>>
>>> On Fri, 12 Apr 2024 at 11:30, Bertrand Marquis
>>> wrote:
>>> Hi Julien,
>>>
O
flight 185582 linux-linus running [real]
http://logs.test-lab.xenproject.org/osstest/logs/185582/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-pvops
flight 185585 xen-unstable running [real]
http://logs.test-lab.xenproject.org/osstest/logs/185585/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-prev
Hi everyone,
We all have a responsibility and pledge to make this community a welcoming
environment.
As such, I would like to request we keep the Code of Conduct and patch
discussions separate.
Should there be a need for any Code of Conduct complaints/investigations,
this will be treated separatel
Hi Julien,
On 4/15/24 1:03 PM, Julien Grall wrote:
>
>
> On 15/04/2024 11:50, Andrew Cooper wrote:
>> On 15/04/2024 11:25 am, Julien Grall wrote:
>>> Hi John,
>>>
>>> I saw this patch was committed. I have one question this may require
>>> some adjustment.
>>>
>>> On 08/04/2024 17:11, John Ernbe
flight 185590 xen-4.15-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/185590/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-prev
On 15/04/2024 11:50, Andrew Cooper wrote:
On 15/04/2024 11:25 am, Julien Grall wrote:
Hi John,
I saw this patch was committed. I have one question this may require
some adjustment.
On 08/04/2024 17:11, John Ernberg wrote:
---
xen/arch/arm/platforms/Makefile | 1 +
xen/arch/arm/platf
flight 185571 linux-6.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185571/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-pvops
On 15/04/2024 11:25 am, Julien Grall wrote:
> Hi John,
>
> I saw this patch was committed. I have one question this may require
> some adjustment.
>
> On 08/04/2024 17:11, John Ernberg wrote:
>> ---
>> xen/arch/arm/platforms/Makefile | 1 +
>> xen/arch/arm/platforms/imx8qm.c | 139
Hi,
On 08/04/2024 16:03, Vaishnav Achath wrote:
TI K3 devices (J721E, J721S2, AM62X .etc) have the same variant
of UART as OMAP4. Add the compatible used in Linux device tree,
"ti,am654-uart" to the OMAP UART dt_match so that the driver can
be used with these devices. Also, enable the driver for
Hi,
On 10/04/2024 00:26, Stefano Stabellini wrote:
From 28f83c4ec0c0b5c1e7eb2bd8bc5dc3190314a5b7 Mon Sep 17 00:00:00 2001
From: Stefano Stabellini
Date: Tue, 9 Apr 2024 16:19:21 -0700
Subject: [PATCH] public: s/int/int32_t
Straightforward int -> int32_t and unsigned int -> uint32_t replacem
Hi John,
I saw this patch was committed. I have one question this may require
some adjustment.
On 08/04/2024 17:11, John Ernberg wrote:
---
xen/arch/arm/platforms/Makefile | 1 +
xen/arch/arm/platforms/imx8qm.c | 139
2 files changed, 140 insertions(+)
Hi Bertrand,
On 15/04/2024 08:48, Bertrand Marquis wrote:
Hi Julien,
On 12 Apr 2024, at 19:01, Julien Grall wrote:
On Fri, 12 Apr 2024 at 11:30, Bertrand Marquis wrote:
Hi Julien,
On 12 Apr 2024, at 15:53, Julien Grall wrote:
On Thu, 11 Apr 2024 at 18:08, Stefano Stabellini wrote:
flight 185570 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185570/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-pvops
Mark the whole gzip folder as adopted code and remove the redundant
deviation of file inflate.
Signed-off-by: Federico Serafini
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 5 -
docs/misra/exclude-list.json | 2 +-
2 files changed, 1 insertion(+), 6 deletions(-)
flight 185567 xen-4.15-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185567/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-prev
On Mon, Apr 15, 2024 at 10:33:19AM +0200, Roger Pau Monné wrote:
> On Mon, Apr 15, 2024 at 09:15:51AM +0100, Anthony PERARD wrote:
> > On Fri, Apr 12, 2024 at 04:11:21PM +0200, Roger Pau Monne wrote:
> > > The current timeout of 40s seems to be too low for AMD boxes (pinots and
> > > rimavas) in th
On Mon, Apr 15, 2024 at 09:17:08AM +0100, Anthony PERARD wrote:
> buster-backport isn't available on the main mirror anymore.
>
> Signed-off-by: Anthony PERARD
Acked-by: Roger Pau Monné
Please push ASAP.
Thanks, Roger.
On Mon, Apr 15, 2024 at 09:15:51AM +0100, Anthony PERARD wrote:
> On Fri, Apr 12, 2024 at 04:11:21PM +0200, Roger Pau Monne wrote:
> > The current timeout of 40s seems to be too low for AMD boxes (pinots and
> > rimavas) in the lab after XSA-455, see:
>
> There's something else we can tweak if onl
flight 185564 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185564/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-prev
buster-backport isn't available on the main mirror anymore.
Signed-off-by: Anthony PERARD
---
Notes:
I've tested the patch already, so I'll push that soon.
production-config | 2 ++
1 file changed, 2 insertions(+)
diff --git a/production-config b/production-config
index 6345c40c..5b0c640d
On Fri, Apr 12, 2024 at 04:11:21PM +0200, Roger Pau Monne wrote:
> The current timeout of 40s seems to be too low for AMD boxes (pinots and
> rimavas) in the lab after XSA-455, see:
There's something else we can tweak if only some machine need extra
time, it is an host property "TimeoutFactor", wh
flight 185560 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185560/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-pvops
Hi Julien,
> On 12 Apr 2024, at 19:01, Julien Grall wrote:
>
>
>
> On Fri, 12 Apr 2024 at 11:30, Bertrand Marquis
> wrote:
> Hi Julien,
>
> > On 12 Apr 2024, at 15:53, Julien Grall wrote:
> >
> >
> >
> > On Thu, 11 Apr 2024 at 18:08, Stefano Stabellini
> > wrote:
> > On Wed, 10 Apr 20
82 matches
Mail list logo
