On 19.02.2024 16:14, Nicola Vetrini wrote:
> The cache clearing and invalidation helpers in x86 and Arm didn't
> comply with MISRA C Rule 17.7: "The value returned by a function
> having non-void return type shall be used". On Arm they
> were always returning 0, while some in x86 returned
On 19.02.2024 21:43, Stefano Stabellini wrote:
> On Mon, 19 Feb 2024, Federico Serafini wrote:
>> On 15/02/24 11:32, Jan Beulich wrote:
>>> The important difference is: Here we're told that there was a use of
>>> __put_user_bad, which is easy to grep for, and thus see how the
>>> supplied function
On 19/2/24 19:16, Marek Marczykowski-Górecki wrote:
Introduce global xen_is_stubdomain variable when qemu is running inside
a stubdomain instead of dom0. This will be relevant for subsequent
patches, as few things like accessing PCI config space need to be done
differently.
Signed-off-by: Marek
flight 184705 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184705/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184699
On Mon, Feb 19, 2024 at 12:13:18PM +0100, Marek Marczykowski-Górecki wrote:
> On Mon, Feb 19, 2024 at 09:57:49AM +0100, Jan Beulich wrote:
> > On 18.02.2024 02:34, Marek Marczykowski-Górecki wrote:
> > > @@ -1170,6 +1177,11 @@ static const struct ns16550_config __initconst
> > > uart_config[] =
>
Hi,
On 14/02/2024 13:52, Carlo Nonato wrote:
On Wed, Feb 14, 2024 at 11:14 AM Michal Orzel wrote:
diff --git a/xen/arch/arm/include/asm/processor.h
b/xen/arch/arm/include/asm/processor.h
index 8e02410465..336933ee62 100644
--- a/xen/arch/arm/include/asm/processor.h
+++
On Mon, Feb 19, 2024 at 07:16:06PM +0100, Marek Marczykowski-Górecki wrote:
> From: Frédéric Pierret (fepitre)
This shouldn't be here, it's my patch.
> When running in a stubdomain, the config space access via sysfs needs to
> use BDF as seen inside stubdomain (connected via xen-pcifront),
Hi Jan,
Title: I would add 'gnttab:' to clarify which subsystem you are modifying.
On 05/02/2024 11:03, Jan Beulich wrote:
Along the line with observations in the context of XSA-448, besides
"op" no field is relevant when the range to be flushed is empty, much
like e.g. the pointers passed to
flight 184703 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184703/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-amd 14 guest-start fail REGR. vs. 184699
build-arm64-pvops
Hi Jan,
On 05/02/2024 11:03, Jan Beulich wrote:
Along the line with observations in the context of XSA-448, no field in
struct gnttab_copy_ptr is relevant when no data is to be copied, much
like e.g. the pointers passed to memcpy() are irrelevant (and would
never be "validated") when the passed
On Mon, 19 Feb 2024, Federico Serafini wrote:
> On 15/02/24 11:32, Jan Beulich wrote:
> > The important difference is: Here we're told that there was a use of
> > __put_user_bad, which is easy to grep for, and thus see how the
> > supplied function / file / line(?) relate to the ultimate problem.
Hi Oleksii,
On 16/02/2024 12:39, Oleksii Kurochko wrote:
Arm, PPC and RISC-V introduce the same things in asm/device.h, so
generic device.h was introduced.
Arm's device.h was taken as a base with the following changes:
- #ifdef ACPI related things.
- Rename #ifdef guards.
- Add SPDX tag.
Hi Oleksii,
On 15/02/2024 16:54, Oleksii wrote:
On 14/02/2024 09:32, Oleksii wrote:
On Tue, 2024-02-13 at 18:09 +, Julien Grall wrote:
+#ifdef CONFIG_HAS_PASSTHROUGH
+ struct iommu_fwspec *iommu_fwspec; /* per-device IOMMU
instance data */
+#endif
+};
+
+typedef struct device
Hi,
On 16/02/2024 12:39, Oleksii Kurochko wrote:
The current patch is a follow-up to the patch titled:
xen/asm-generic: introduce generic device.h
Also, a prerequisite for this patch is, without which a compilation
error will occur:
xen/arm: switch Arm to use asm-generic/device.h
The
Hi Jan,
On 19/02/2024 11:26, Jan Beulich wrote:
On 16.02.2024 13:39, Oleksii Kurochko wrote:
The current patch is a follow-up to the patch titled:
xen/asm-generic: introduce generic device.h
Also, a prerequisite for this patch is, without which a compilation
error will occur:
Hi Michal,
On 19/02/2024 15:43, Michal Orzel wrote:
On 19/02/2024 15:45, Ayan Kumar Halder wrote:
On 06/02/2024 19:05, Julien Grall wrote:
Hi Ayan,
Hi Julien/Michal,
On 31/01/2024 12:10, Ayan Kumar Halder wrote:
From: Michal Orzel
Currently, if user enables HVC_DCC config option in
From: Frédéric Pierret (fepitre)
When running in a stubdomain, the config space access via sysfs needs to
use BDF as seen inside stubdomain (connected via xen-pcifront), which is
different from the real BDF. For other purposes (hypercall parameters
etc), the real BDF needs to be used.
Get the
Introduce global xen_is_stubdomain variable when qemu is running inside
a stubdomain instead of dom0. This will be relevant for subsequent
patches, as few things like accessing PCI config space need to be done
differently.
Signed-off-by: Marek Marczykowski-Górecki
---
For XSM changes,
Ack-by: Daniel P. Smith
V/r,
Daniel P. Smith
Apertus Solutions, LLC
On 2/14/24 04:47, Frediano Ziglio wrote:
Make clear they are not changed in the functions.
Signed-off-by: Frediano Ziglio
Reviewed-by: Jan Beulich
--
v2:
- fixed typo in commit message.
---
On 06.02.2024 02:20, George Dunlap wrote:
> --- /dev/null
> +++ b/docs/designs/nested-svm-cpu-features.md
> @@ -0,0 +1,110 @@
> +# Nested SVM (AMD) CPUID requirements
> +
> +The first step in making nested SVM production-ready is to make sure
> +that all features are implemented and well-tested.
On 06.02.2024 02:20, George Dunlap wrote:
> --- a/xen/arch/x86/include/asm/hvm/hvm.h
> +++ b/xen/arch/x86/include/asm/hvm/hvm.h
> @@ -86,20 +86,19 @@ struct hvm_vcpu_nonreg_state {
> struct hvm_function_table {
> const char *name;
>
> -/* Support Hardware-Assisted Paging? */
> -
On 06.02.2024 02:20, George Dunlap wrote:
> Changeset ef3e8db8068 ("x86/hvm: Corrections and improvements to
> unhandled vmexit logging") introduced a printk to the default path of
> the switch statement in nestedsvm_check_intercepts(), complaining of
> an unknown exit reason.
>
> Unfortunately,
Hi Ayan,
On 19/02/2024 15:45, Ayan Kumar Halder wrote:
>
> On 06/02/2024 19:05, Julien Grall wrote:
>> Hi Ayan,
> Hi Julien/Michal,
>>
>> On 31/01/2024 12:10, Ayan Kumar Halder wrote:
>>> From: Michal Orzel
>>>
>>> Currently, if user enables HVC_DCC config option in Linux, it invokes
>>>
On Mon, Feb 19, 2024 at 06:01:54PM +0800, George Dunlap wrote:
>
> Looking at the *non*-4.18 downloads, nearly all of them have user
> agents that make it clear they're part of automated build systems:
> user agents like curl and wget, but also "Go-http-client", "libfetch",
On 19.02.2024 16:20, Oleksii wrote:
> On Mon, 2024-02-19 at 15:12 +0100, Jan Beulich wrote:
>> On 19.02.2024 15:00, Oleksii wrote:
>>> On Sun, 2024-02-18 at 19:00 +, Julien Grall wrote:
On 05/02/2024 15:32, Oleksii Kurochko wrote:
> --- /dev/null
> +++
On 06.02.2024 02:20, George Dunlap wrote:
> --- a/xen/arch/x86/include/asm/hvm/svm/svm.h
> +++ b/xen/arch/x86/include/asm/hvm/svm/svm.h
> @@ -38,7 +38,10 @@ extern u32 svm_feature_flags;
> #define SVM_FEATURE_SSS 19 /* NPT Supervisor Shadow Stacks */
> #define SVM_FEATURE_SPEC_CTRL
On 06.02.2024 02:20, George Dunlap wrote:
> For now, just disable the functionality entirely until we can
> implement it properly:
>
> - Don't set TSCRATEMSR in the host CPUID policy
This goes too far: This way you would (in principle) also affect guests
with nesting disabled. According to the
On Mon, 2024-02-19 at 15:12 +0100, Jan Beulich wrote:
> On 19.02.2024 15:00, Oleksii wrote:
> > On Sun, 2024-02-18 at 19:00 +, Julien Grall wrote:
> > > On 05/02/2024 15:32, Oleksii Kurochko wrote:
> > > > --- /dev/null
> > > > +++ b/xen/arch/riscv/include/asm/cmpxchg.h
> > > > @@ -0,0 +1,237
The cache clearing and invalidation helpers in x86 and Arm didn't
comply with MISRA C Rule 17.7: "The value returned by a function
having non-void return type shall be used". On Arm they
were always returning 0, while some in x86 returned -EOPNOTSUPP
and in common/grant_table the return value is
On 19.02.2024 15:59, Federico Serafini wrote:
> On 19/02/24 14:43, Jan Beulich wrote:
>> On 19.02.2024 14:24, Federico Serafini wrote:
>>> Update ECLAIR configuration to consider safe switch clauses ending
>>> with __{get,put}_user_bad().
>>>
>>> Update docs/misra/deviations.rst accordingly.
>>>
On 19.02.2024 15:29, Oleksii wrote:
> On Mon, 2024-02-19 at 12:22 +0100, Jan Beulich wrote:
>> On 15.02.2024 14:41, Oleksii wrote:
>>> As I mentioned above with 4-byte alignment and then reading and
>>> working
>>> with 8-byte then crossing a word or double-word boundary shouldn't
>>> be
>>> an
On 19/02/24 14:43, Jan Beulich wrote:
On 19.02.2024 14:24, Federico Serafini wrote:
Update ECLAIR configuration to consider safe switch clauses ending
with __{get,put}_user_bad().
Update docs/misra/deviations.rst accordingly.
Signed-off-by: Federico Serafini
As mentioned I'm not happy with
On 06/02/2024 19:05, Julien Grall wrote:
Hi Ayan,
Hi Julien/Michal,
On 31/01/2024 12:10, Ayan Kumar Halder wrote:
From: Michal Orzel
Currently, if user enables HVC_DCC config option in Linux, it invokes
access
to debug data transfer registers (i.e. DBGDTRTX_EL0 on arm64,
DBGDTRTXINT on
Hi Julien,
On Sun, 2024-02-18 at 18:22 +, Julien Grall wrote:
> Hi,
>
> On 05/02/2024 15:32, Oleksii Kurochko wrote:
> > Signed-off-by: Oleksii Kurochko
> > Acked-by: Jan Beulich
> > --
> > Changes in V4:
> > - add Acked-by: Jan Beulich
> > - s/BUG()/BUG_ON("unimplemented")
> >
On 06.02.2024 02:20, George Dunlap wrote:
> @@ -144,7 +144,7 @@ static bool __init hap_supported(struct
> hvm_function_table *fns)
>
> if ( !opt_hap_enabled )
> {
> -fns->hap_supported = 0;
> +fns->caps.hap = 0;
As you touch such, would you mind switching to
Hi Julien,
On Sun, 2024-02-18 at 19:22 +, Julien Grall wrote:
> Hi,
>
> On 05/02/2024 15:32, Oleksii Kurochko wrote:
> > From: Bobby Eshleman
> >
> > Additionally, this patch introduces macros in fence.h,
> > which are utilized in atomic.h.
> >
> >
On Sun, 2024-02-18 at 19:07 +, Julien Grall wrote:
>
> > +/*
> > + * Unordered I/O memory access primitives. These are even more
> > relaxed than
> > + * the relaxed versions, as they don't even order accesses between
> > successive
> > + * operations to the I/O regions.
> > + */
> >
flight 184701 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184701/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On Mon, 2024-02-19 at 12:22 +0100, Jan Beulich wrote:
> On 15.02.2024 14:41, Oleksii wrote:
> > > > + : "=r" (ret), "+A" (*ptr) \
> > > > + : "r" (new) \
> > > > + : "memory" ); \
> > > > +})
> > > > +
> > > > +#define emulate_xchg_1_2(ptr, new, ret, release_barrier,
> > > >
Hi Oleksii,
On 19/02/2024 14:00, Oleksii wrote:
On Sun, 2024-02-18 at 19:00 +, Julien Grall wrote:
On 05/02/2024 15:32, Oleksii Kurochko wrote:
The header was taken from Linux kernl 6.4.0-rc1.
Addionally, were updated:
* add emulation of {cmp}xchg for 1/2 byte types
This explaination
flight 184700 linux-linus real [real]
flight 184702 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184700/
http://logs.test-lab.xenproject.org/osstest/logs/184702/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 2/19/24 08:12, Jan Beulich wrote:
> On 19.02.2024 13:47, Stewart Hildebrand wrote:
>> On 2/19/24 07:10, Jan Beulich wrote:
>>> On 19.02.2024 12:47, Stewart Hildebrand wrote:
@@ -895,6 +891,15 @@ int vpci_msix_arch_print(const struct vpci_msix *msix)
{
unsigned int i;
On 19.02.2024 15:00, Oleksii wrote:
> On Sun, 2024-02-18 at 19:00 +, Julien Grall wrote:
>> On 05/02/2024 15:32, Oleksii Kurochko wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/riscv/include/asm/cmpxchg.h
>>> @@ -0,0 +1,237 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>> +/* Copyright (C)
On 06.02.2024 02:20, George Dunlap wrote:
> The "effective type" of the cpu_has_svm_feature macro is effectively
> an unsigned log with one bit set (or not); at least one place someone
> felt compelled to do a !! to make sure that they got a boolean out of
> it.
>
> Ideally the whole of this
On Sun, 2024-02-18 at 19:00 +, Julien Grall wrote:
>
>
> On 05/02/2024 15:32, Oleksii Kurochko wrote:
> > The header was taken from Linux kernl 6.4.0-rc1.
> >
> > Addionally, were updated:
> > * add emulation of {cmp}xchg for 1/2 byte types
>
> This explaination is a little bit light.
In xen-9pfsd fill_data() va_end() needs to be called before returning.
Coverity Id CID 1592145
Fixes: bcec59cf7ff4 ("tools/xen-9pfsd: add 9pfs version request support")
Signed-off-by: Juergen Gross
---
tools/9pfsd/io.c | 29 -
1 file changed, 16 insertions(+), 13
On 19.02.2024 14:24, Federico Serafini wrote:
> Update ECLAIR configuration to consider safe switch clauses ending
> with __{get,put}_user_bad().
>
> Update docs/misra/deviations.rst accordingly.
>
> Signed-off-by: Federico Serafini
As mentioned I'm not happy with this, not the least because
On 06.02.2024 02:20, George Dunlap wrote:
> hvm_function_table is an internal structure; rather than manually
> |-ing and &-ing bits, just make it a boolean bitfield and let the
> compiler do all the work. This makes everything easier to read, and
> presumably allows the compiler more flexibility
Update ECLAIR configuration to consider safe switch clauses ending
with __{get,put}_user_bad().
Update docs/misra/deviations.rst accordingly.
Signed-off-by: Federico Serafini
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 4
docs/misra/deviations.rst| 6
On 19.02.2024 13:47, Stewart Hildebrand wrote:
> On 2/19/24 07:10, Jan Beulich wrote:
>> On 19.02.2024 12:47, Stewart Hildebrand wrote:
>>> @@ -895,6 +891,15 @@ int vpci_msix_arch_print(const struct vpci_msix *msix)
>>> {
>>> unsigned int i;
>>>
>>> +/*
>>> + * Assert that
On 2024/2/18 17:04, Kees Cook wrote:
On Sun, Feb 18, 2024 at 08:47:03AM +0100, Greg KH wrote:
On Sun, Feb 18, 2024 at 03:35:01PM +0800, Guixiong Wei wrote:
From: Guixiong Wei
Restrict non-privileged user access to /sys/kernel/notes to
avoid security attack.
The non-privileged users have
On 2/19/24 07:10, Jan Beulich wrote:
> On 19.02.2024 12:47, Stewart Hildebrand wrote:
>> @@ -895,6 +891,15 @@ int vpci_msix_arch_print(const struct vpci_msix *msix)
>> {
>> unsigned int i;
>>
>> +/*
>> + * Assert that d->pdev_list doesn't change.
>> ASSERT_PDEV_LIST_IS_READ_LOCKED
On 19.02.2024 12:59, Oleksii wrote:
> Hi Julien,
>
> On Sun, 2024-02-18 at 18:30 +, Julien Grall wrote:
>> Hi Oleksii,
>>
>> Title: Typo s/introdure/introduce/
>>
>> On 05/02/2024 15:32, Oleksii Kurochko wrote:
>>> The header is similar between Arm, PPC, and RISC-V,
>>> so it has been moved
On 19.02.2024 12:47, Stewart Hildebrand wrote:
> @@ -895,6 +891,15 @@ int vpci_msix_arch_print(const struct vpci_msix *msix)
> {
> unsigned int i;
>
> +/*
> + * Assert that d->pdev_list doesn't change.
> ASSERT_PDEV_LIST_IS_READ_LOCKED
> + * is not suitable here because it may
Hi Julien,
On Sun, 2024-02-18 at 18:30 +, Julien Grall wrote:
> Hi Oleksii,
>
> Title: Typo s/introdure/introduce/
>
> On 05/02/2024 15:32, Oleksii Kurochko wrote:
> > The header is similar between Arm, PPC, and RISC-V,
> > so it has been moved to asm-generic.
>
> I am not 100% convinced
On Thu, 31 Aug 2023 at 11:32, Ayan Kumar Halder wrote:
> On 31/08/2023 11:03, Peter Maydell wrote:
> > On Thu, 31 Aug 2023 at 10:53, Alex Bennée wrote:
> >> Peter Maydell writes:
> >>> On Thu, 31 Aug 2023 at 01:57, Stefano Stabellini
> >>> wrote:
> As Xen is gaining R52 and R82 support,
From: Oleksandr Andrushchenko
Use the per-domain PCI read/write lock to protect the presence of the
pci device vpci field. This lock can be used (and in a few cases is used
right away) so that vpci removal can be performed while holding the lock
in write mode. Previously such removal could race
On many entries we push 8-bytes zero and exception constants are
small so we can just write a single byte saving 3 bytes for
instruction.
With ENDBR64 this reduces the size of many entry points from 32 to
16 bytes (due to alignment).
The push and the mov are overlapping stores either way.
On 16.02.2024 13:39, Oleksii Kurochko wrote:
> The current patch is a follow-up to the patch titled:
> xen/asm-generic: introduce generic device.h
> Also, a prerequisite for this patch is, without which a compilation
> error will occur:
> xen/arm: switch Arm to use asm-generic/device.h
>
On 15.02.2024 14:41, Oleksii wrote:
>>> + : "=r" (ret), "+A" (*ptr) \
>>> + : "r" (new) \
>>> + : "memory" ); \
>>> +})
>>> +
>>> +#define emulate_xchg_1_2(ptr, new, ret, release_barrier,
>>> acquire_barrier) \
>>> +({ \
>>> + uint32_t *ptr_32b_aligned = (uint32_t
On Mon, Feb 19, 2024 at 09:57:49AM +0100, Jan Beulich wrote:
> On 18.02.2024 02:34, Marek Marczykowski-Górecki wrote:
> > @@ -1170,6 +1177,11 @@ static const struct ns16550_config __initconst
> > uart_config[] =
> > .dev_id = 0x7adc,
> > .param = param_intel_lpss
> > },
> >
On 19.02.2024 11:31, Roger Pau Monné wrote:
> On Mon, Feb 19, 2024 at 06:01:54PM +0800, George Dunlap wrote:
>> One of the questions we had with respect to changing our release
>> practice (for instance, making the process more light-weight so that
>> we could do a point release after every XSA)
On Mon, Feb 19, 2024 at 06:01:54PM +0800, George Dunlap wrote:
> Hey all,
>
> One of the questions we had with respect to changing our release
> practice (for instance, making the process more light-weight so that
> we could do a point release after every XSA) was, "How many people are
> actually
flight 184699 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184699/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 184693
On 16.02.2024 11:50, Frediano Ziglio wrote:
> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -22,6 +22,14 @@
> #endif
> .endm
>
> +.macro BUILD_BUG_ON condstr cond:vararg
> +.if \cond
> +.error "Condition \condstr not satisfied"
Maybe
On 15.02.2024 17:46, Roger Pau Monne wrote:
> The feature is defined in the tertiary exec control, and is available starting
> from Sapphire Rapids and Alder Lake CPUs.
>
> When enabled, two extra VMCS fields are used: SPEC_CTRL mask and shadow. Bits
> set in mask are not allowed to be toggled
On 18.02.2024 02:34, Marek Marczykowski-Górecki wrote:
> @@ -1170,6 +1177,11 @@ static const struct ns16550_config __initconst
> uart_config[] =
> .dev_id = 0x7adc,
> .param = param_intel_lpss
> },
> +{
> +.vendor_id = PCI_VENDOR_ID_ASIX,
> +.dev_id =
On 19.02.2024 06:07, George Dunlap wrote:
> On Wed, Feb 14, 2024 at 7:42 PM Roger Pau Monne wrote:
>>
>> It's not obvious from the function itself whether the incremented value will
>> be
>> stored in the parameter, or returned to the caller. That has leads to bugs
>> in
>> the past as callers
On Fri, Feb 16, 2024 at 09:41:19AM -0500, Stewart Hildebrand wrote:
> On 2/16/24 06:44, Roger Pau Monné wrote:
> > On Thu, Feb 15, 2024 at 03:30:00PM -0500, Stewart Hildebrand wrote:
> >> From: Oleksandr Andrushchenko
> >>
> >> Use the per-domain PCI read/write lock to protect the presence of the
On 16.02.2024 10:11, Roger Pau Monné wrote:
> On Wed, Feb 14, 2024 at 11:15:51AM +0100, Jan Beulich wrote:
>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -407,9 +407,15 @@ void __init early_cpu_init(bool verbose)
>> paddr_bits -= (ebx >> 6) & 0x3f;
>>
On 16.02.2024 11:51, Roger Pau Monné wrote:
> On Fri, Feb 16, 2024 at 11:04:46AM +0100, Jan Beulich wrote:
>> On 15.02.2024 18:23, Roger Pau Monné wrote:
>>> On Thu, Feb 15, 2024 at 05:22:00PM +0100, Jan Beulich wrote:
On 15.02.2024 17:08, Roger Pau Monné wrote:
> On Thu, Feb 15, 2024 at
On 15/02/24 11:32, Jan Beulich wrote:
The important difference is: Here we're told that there was a use of
__put_user_bad, which is easy to grep for, and thus see how the
supplied function / file / line(?) relate to the ultimate problem.
I'm afraid I'm meanwhile confused enough by the various
On 16.02.2024 12:03, Oleksii wrote:
>>
>>> + } free;
>>> + } u;
>>> +
>>> + union {
>>> + /* Page is in use, but not as a shadow. */
>>
>> I'm also pretty sure I asked before what shadow this comment alludes
>> to.
> I missed your request about 'shadow' before.
>
> The comment
On 16.02.2024 12:16, Oleksii wrote:
> On Thu, 2024-02-15 at 17:43 +0100, Jan Beulich wrote:
>> On 15.02.2024 17:38, Oleksii wrote:
>>> On Tue, 2024-02-13 at 14:33 +0100, Jan Beulich wrote:
On 05.02.2024 16:32, Oleksii Kurochko wrote:
> + depends on LLD_VERSION >= 15 || LD_VERSION >=
74 matches
Mail list logo
