* Re: [RFC PATCH] Documentation/arm64: describe the kernel's expectations of 'memory'
[not found] <20210517103319.5356-1-james.morse@arm.com>
@ 2021-05-17 11:27 ` Jonathan Cameron
2021-05-17 11:55 ` Ard Biesheuvel
0 siblings, 1 reply; 5+ messages in thread
From: Jonathan Cameron @ 2021-05-17 11:27 UTC (permalink / raw)
To: James Morse; +Cc: linux-arm-kernel, Catalin Marinas, Will Deacon, linux-cxl
On Mon, 17 May 2021 11:33:19 +0100
James Morse <james.morse@arm.com> wrote:
> Standards such as CXL allow memory on PCIe devices to be made
> available to the operating system for use as regular memory.
>
> Document linux's expectations around the behaviour of memory as the
> implementations of these new standards may need special treatment in
> the OS, firmware or bootloader.
>
> Signed-off-by: James Morse <james.morse@arm.com>
Hi James,
+CC linux-cxl to pick up a few more interesting people who might loose
this in the wash of linux-arm-kernel
Good to see this description as there has been some confusion on this
point. This basically looks like what I'd expect to see. Just a few
comments around firmware description towards the end.
> ---
> Documentation/arm64/memory.rst | 31 +++++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
> diff --git a/Documentation/arm64/memory.rst b/Documentation/arm64/memory.rst
> index 901cd094f4ec..951802aee55f 100644
> --- a/Documentation/arm64/memory.rst
> +++ b/Documentation/arm64/memory.rst
> @@ -167,3 +167,34 @@ from a 52-bit space by enabling the following kernel config options:
>
> Note that this option is only intended for debugging applications
> and should not be used in production.
> +
> +On device memory used as regular memory
> +---------------------------------------
> +Standards such as CXL allow memory on PCIe device to be made
> +available to the operating system for use as regular memory.
> +
> +If memory is added to the UEFI memory map or DT, or discovered via ACPI's SRAT,
> +linux expects it to function in the same way as the bulk DRAM. This section
Linux
> +terms this 'regular memory'.
> +
> +The kernel may use any attributes to map this memory, e.g. Device-nGnRnE or
> +Normal Writeback-Cacheable. The kernel may not be in control of the attributes
> +used, e.g. if the memory is used by a KVM guest.
> +The kernel will perform cache maintenance to resolve mismatched attributes,
> +e.g. invalidating clean stale lines after writing new data when the MMU is
> +disabled.
> +
> +The memory may be used by any instruction supported by the CPUs.
> +e.g. Even when the v8.1 LSE atomic instructions are supported, the v8.0
> +exclusives are still used for the futex code, and conditional waits, and still
> +used by existing user-space binaries. When the CPUs support features such as
> +MTE, all regular memory must support MTE tags.
> +
> +On device memory that does not function in the same way as regular memory must
> +not be added to the UEFI memory map or DT, or be discovered via ACPI's SRAT.
> +
> +On arm64, the kernel does not rewrite the UEFI memory map when memory is added
> +or removed. On device memory that is present at boot, but must be removed later
Might be worth giving an example of why memory 'must be removed'? I'm not sure
what you are getting at there. Specific purpose memory?
> +should be discovered via ACPI's SRAT to ensure it is not used for non-movable
> +structures.
Not sure I follow this part. It could be of type EFI_MEMORY_SP.
It should be in SRAT as well, but the EFI type should be sufficient to avoid
problems.
"The SPM attribute serves as a hint to the OS to avoid allocating this memory
for core OS data or code that can not be relocated."
Now I'm not sure the kernel is handling EFI_MEMORY_SP fully yet... If
we need to exclude this approach for now, then this text should perhaps
call it out explicitly.
> +e.g. the kernel text, page tables or the GIC ITS Pending Table.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC PATCH] Documentation/arm64: describe the kernel's expectations of 'memory'
2021-05-17 11:27 ` [RFC PATCH] Documentation/arm64: describe the kernel's expectations of 'memory' Jonathan Cameron
@ 2021-05-17 11:55 ` Ard Biesheuvel
2021-05-17 12:17 ` Jonathan Cameron
0 siblings, 1 reply; 5+ messages in thread
From: Ard Biesheuvel @ 2021-05-17 11:55 UTC (permalink / raw)
To: Jonathan Cameron
Cc: James Morse, Linux ARM, Catalin Marinas, Will Deacon, linux-cxl
On Mon, 17 May 2021 at 13:30, Jonathan Cameron
<Jonathan.Cameron@huawei.com> wrote:
>
> On Mon, 17 May 2021 11:33:19 +0100
> James Morse <james.morse@arm.com> wrote:
>
> > Standards such as CXL allow memory on PCIe devices to be made
> > available to the operating system for use as regular memory.
> >
> > Document linux's expectations around the behaviour of memory as the
> > implementations of these new standards may need special treatment in
> > the OS, firmware or bootloader.
> >
> > Signed-off-by: James Morse <james.morse@arm.com>
>
> Hi James,
>
> +CC linux-cxl to pick up a few more interesting people who might loose
> this in the wash of linux-arm-kernel
>
> Good to see this description as there has been some confusion on this
> point. This basically looks like what I'd expect to see. Just a few
> comments around firmware description towards the end.
>
> > ---
> > Documentation/arm64/memory.rst | 31 +++++++++++++++++++++++++++++++
> > 1 file changed, 31 insertions(+)
> >
> > diff --git a/Documentation/arm64/memory.rst b/Documentation/arm64/memory.rst
> > index 901cd094f4ec..951802aee55f 100644
> > --- a/Documentation/arm64/memory.rst
> > +++ b/Documentation/arm64/memory.rst
> > @@ -167,3 +167,34 @@ from a 52-bit space by enabling the following kernel config options:
> >
> > Note that this option is only intended for debugging applications
> > and should not be used in production.
> > +
> > +On device memory used as regular memory
> > +---------------------------------------
> > +Standards such as CXL allow memory on PCIe device to be made
> > +available to the operating system for use as regular memory.
> > +
> > +If memory is added to the UEFI memory map or DT, or discovered via ACPI's SRAT,
> > +linux expects it to function in the same way as the bulk DRAM. This section
>
> Linux
>
> > +terms this 'regular memory'.
> > +
> > +The kernel may use any attributes to map this memory, e.g. Device-nGnRnE or
> > +Normal Writeback-Cacheable. The kernel may not be in control of the attributes
> > +used, e.g. if the memory is used by a KVM guest.
> > +The kernel will perform cache maintenance to resolve mismatched attributes,
> > +e.g. invalidating clean stale lines after writing new data when the MMU is
> > +disabled.
> > +
> > +The memory may be used by any instruction supported by the CPUs.
> > +e.g. Even when the v8.1 LSE atomic instructions are supported, the v8.0
> > +exclusives are still used for the futex code, and conditional waits, and still
> > +used by existing user-space binaries. When the CPUs support features such as
> > +MTE, all regular memory must support MTE tags.
> > +
> > +On device memory that does not function in the same way as regular memory must
> > +not be added to the UEFI memory map or DT, or be discovered via ACPI's SRAT.
> > +
> > +On arm64, the kernel does not rewrite the UEFI memory map when memory is added
> > +or removed. On device memory that is present at boot, but must be removed later
>
> Might be worth giving an example of why memory 'must be removed'? I'm not sure
> what you are getting at there. Specific purpose memory?
>
> > +should be discovered via ACPI's SRAT to ensure it is not used for non-movable
> > +structures.
>
> Not sure I follow this part. It could be of type EFI_MEMORY_SP.
EFI_MEMORY_SP is an attribute, not a type.
> It should be in SRAT as well, but the EFI type should be sufficient to avoid
> problems.
> "The SPM attribute serves as a hint to the OS to avoid allocating this memory
> for core OS data or code that can not be relocated."
>
> Now I'm not sure the kernel is handling EFI_MEMORY_SP fully yet... If
> we need to exclude this approach for now, then this text should perhaps
> call it out explicitly.
>
The problem with EFI_MEMORY_SP is that it is not a type, but an
attribute, which gives a hint to the OS about the nature of the
memory, which the OS is free to ignore.
The UEFI memory map is not only consumed by the OS, but by any driver
or OS loader that executes in the EFI boot environment, e.g., GPU
drivers or shim/grub bootloaders. If these are not enlightened and
understand what EFI_MEMORY_SP means, they may (and are entitled to)
treat this EFI_MEMORY_SP as if it were regular memory. If GRUB loads
the kernel into EFI_MEMORY_SP memory, it had better behave like
regular memory or things will fall apart.
This means that EFI_MEMORY_SP is really only suitable to describe
aspects of the memory range that can be happily ignored. MTE or
atomics capability must be described in a different way.
> > +e.g. the kernel text, page tables or the GIC ITS Pending Table.
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC PATCH] Documentation/arm64: describe the kernel's expectations of 'memory'
2021-05-17 11:55 ` Ard Biesheuvel
@ 2021-05-17 12:17 ` Jonathan Cameron
2021-05-17 12:25 ` Ard Biesheuvel
0 siblings, 1 reply; 5+ messages in thread
From: Jonathan Cameron @ 2021-05-17 12:17 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: James Morse, Linux ARM, Catalin Marinas, Will Deacon, linux-cxl
On Mon, 17 May 2021 13:55:16 +0200
Ard Biesheuvel <ardb@kernel.org> wrote:
> On Mon, 17 May 2021 at 13:30, Jonathan Cameron
> <Jonathan.Cameron@huawei.com> wrote:
> >
> > On Mon, 17 May 2021 11:33:19 +0100
> > James Morse <james.morse@arm.com> wrote:
> >
> > > Standards such as CXL allow memory on PCIe devices to be made
> > > available to the operating system for use as regular memory.
> > >
> > > Document linux's expectations around the behaviour of memory as the
> > > implementations of these new standards may need special treatment in
> > > the OS, firmware or bootloader.
> > >
> > > Signed-off-by: James Morse <james.morse@arm.com>
> >
> > Hi James,
> >
> > +CC linux-cxl to pick up a few more interesting people who might loose
> > this in the wash of linux-arm-kernel
> >
> > Good to see this description as there has been some confusion on this
> > point. This basically looks like what I'd expect to see. Just a few
> > comments around firmware description towards the end.
> >
> > > ---
> > > Documentation/arm64/memory.rst | 31 +++++++++++++++++++++++++++++++
> > > 1 file changed, 31 insertions(+)
> > >
> > > diff --git a/Documentation/arm64/memory.rst b/Documentation/arm64/memory.rst
> > > index 901cd094f4ec..951802aee55f 100644
> > > --- a/Documentation/arm64/memory.rst
> > > +++ b/Documentation/arm64/memory.rst
> > > @@ -167,3 +167,34 @@ from a 52-bit space by enabling the following kernel config options:
> > >
> > > Note that this option is only intended for debugging applications
> > > and should not be used in production.
> > > +
> > > +On device memory used as regular memory
> > > +---------------------------------------
> > > +Standards such as CXL allow memory on PCIe device to be made
> > > +available to the operating system for use as regular memory.
> > > +
> > > +If memory is added to the UEFI memory map or DT, or discovered via ACPI's SRAT,
> > > +linux expects it to function in the same way as the bulk DRAM. This section
> >
> > Linux
> >
> > > +terms this 'regular memory'.
> > > +
> > > +The kernel may use any attributes to map this memory, e.g. Device-nGnRnE or
> > > +Normal Writeback-Cacheable. The kernel may not be in control of the attributes
> > > +used, e.g. if the memory is used by a KVM guest.
> > > +The kernel will perform cache maintenance to resolve mismatched attributes,
> > > +e.g. invalidating clean stale lines after writing new data when the MMU is
> > > +disabled.
> > > +
> > > +The memory may be used by any instruction supported by the CPUs.
> > > +e.g. Even when the v8.1 LSE atomic instructions are supported, the v8.0
> > > +exclusives are still used for the futex code, and conditional waits, and still
> > > +used by existing user-space binaries. When the CPUs support features such as
> > > +MTE, all regular memory must support MTE tags.
> > > +
> > > +On device memory that does not function in the same way as regular memory must
> > > +not be added to the UEFI memory map or DT, or be discovered via ACPI's SRAT.
> > > +
> > > +On arm64, the kernel does not rewrite the UEFI memory map when memory is added
> > > +or removed. On device memory that is present at boot, but must be removed later
> >
> > Might be worth giving an example of why memory 'must be removed'? I'm not sure
> > what you are getting at there. Specific purpose memory?
> >
> > > +should be discovered via ACPI's SRAT to ensure it is not used for non-movable
> > > +structures.
> >
> > Not sure I follow this part. It could be of type EFI_MEMORY_SP.
>
> EFI_MEMORY_SP is an attribute, not a type.
Good point.
>
> > It should be in SRAT as well, but the EFI type should be sufficient to avoid
> > problems.
> > "The SPM attribute serves as a hint to the OS to avoid allocating this memory
> > for core OS data or code that can not be relocated."
> >
> > Now I'm not sure the kernel is handling EFI_MEMORY_SP fully yet... If
> > we need to exclude this approach for now, then this text should perhaps
> > call it out explicitly.
> >
>
> The problem with EFI_MEMORY_SP is that it is not a type, but an
> attribute, which gives a hint to the OS about the nature of the
> memory, which the OS is free to ignore.
IIRC the way around that is to use the reserved type + EFI_MEMORY_SP.
An unware bootloader or OS will then not use it and hence we are safe.
An aware driver can then decide it is safe to "hotplug" said memory.
>
> The UEFI memory map is not only consumed by the OS, but by any driver
> or OS loader that executes in the EFI boot environment, e.g., GPU
> drivers or shim/grub bootloaders. If these are not enlightened and
> understand what EFI_MEMORY_SP means, they may (and are entitled to)
> treat this EFI_MEMORY_SP as if it were regular memory. If GRUB loads
> the kernel into EFI_MEMORY_SP memory, it had better behave like
> regular memory or things will fall apart.
Two separate issues here. The 'broken' one where _SP or indeed
hotplug flag is no use, and the one where it is 'must be removed later'
and we just don't want to put unmovable allocations in it.
>
> This means that EFI_MEMORY_SP is really only suitable to describe
> aspects of the memory range that can be happily ignored. MTE or
> atomics capability must be described in a different way.
>
That's indeed the intent. These are just hints and indeed not suitable for
the cases where things are broken (MTE / Atomics). In those you
should not be claiming it is normal memory at all. SRAT doesn't help
you with that though.
The hotplug flag is SRAT is also only a hint. OS doesn't have
to take any notice or support it nor does any boot loader. Things
will 'work' with the exception of hot-remove. If you definitely don't
want your memory to be used by the OS for normal purposes, then
don't present it in a form where it might be.
Jonathan
>
>
> > > +e.g. the kernel text, page tables or the GIC ITS Pending Table.
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC PATCH] Documentation/arm64: describe the kernel's expectations of 'memory'
2021-05-17 12:17 ` Jonathan Cameron
@ 2021-05-17 12:25 ` Ard Biesheuvel
2021-06-04 17:57 ` James Morse
0 siblings, 1 reply; 5+ messages in thread
From: Ard Biesheuvel @ 2021-05-17 12:25 UTC (permalink / raw)
To: Jonathan Cameron
Cc: James Morse, Linux ARM, Catalin Marinas, Will Deacon, linux-cxl
On Mon, 17 May 2021 at 14:19, Jonathan Cameron
<Jonathan.Cameron@huawei.com> wrote:
>
> On Mon, 17 May 2021 13:55:16 +0200
> Ard Biesheuvel <ardb@kernel.org> wrote:
>
> > On Mon, 17 May 2021 at 13:30, Jonathan Cameron
> > <Jonathan.Cameron@huawei.com> wrote:
> > >
> > > On Mon, 17 May 2021 11:33:19 +0100
> > > James Morse <james.morse@arm.com> wrote:
> > >
> > > > Standards such as CXL allow memory on PCIe devices to be made
> > > > available to the operating system for use as regular memory.
> > > >
> > > > Document linux's expectations around the behaviour of memory as the
> > > > implementations of these new standards may need special treatment in
> > > > the OS, firmware or bootloader.
> > > >
> > > > Signed-off-by: James Morse <james.morse@arm.com>
> > >
> > > Hi James,
> > >
> > > +CC linux-cxl to pick up a few more interesting people who might loose
> > > this in the wash of linux-arm-kernel
> > >
> > > Good to see this description as there has been some confusion on this
> > > point. This basically looks like what I'd expect to see. Just a few
> > > comments around firmware description towards the end.
> > >
> > > > ---
> > > > Documentation/arm64/memory.rst | 31 +++++++++++++++++++++++++++++++
> > > > 1 file changed, 31 insertions(+)
> > > >
> > > > diff --git a/Documentation/arm64/memory.rst b/Documentation/arm64/memory.rst
> > > > index 901cd094f4ec..951802aee55f 100644
> > > > --- a/Documentation/arm64/memory.rst
> > > > +++ b/Documentation/arm64/memory.rst
> > > > @@ -167,3 +167,34 @@ from a 52-bit space by enabling the following kernel config options:
> > > >
> > > > Note that this option is only intended for debugging applications
> > > > and should not be used in production.
> > > > +
> > > > +On device memory used as regular memory
> > > > +---------------------------------------
> > > > +Standards such as CXL allow memory on PCIe device to be made
> > > > +available to the operating system for use as regular memory.
> > > > +
> > > > +If memory is added to the UEFI memory map or DT, or discovered via ACPI's SRAT,
> > > > +linux expects it to function in the same way as the bulk DRAM. This section
> > >
> > > Linux
> > >
> > > > +terms this 'regular memory'.
> > > > +
> > > > +The kernel may use any attributes to map this memory, e.g. Device-nGnRnE or
> > > > +Normal Writeback-Cacheable. The kernel may not be in control of the attributes
> > > > +used, e.g. if the memory is used by a KVM guest.
> > > > +The kernel will perform cache maintenance to resolve mismatched attributes,
> > > > +e.g. invalidating clean stale lines after writing new data when the MMU is
> > > > +disabled.
> > > > +
> > > > +The memory may be used by any instruction supported by the CPUs.
> > > > +e.g. Even when the v8.1 LSE atomic instructions are supported, the v8.0
> > > > +exclusives are still used for the futex code, and conditional waits, and still
> > > > +used by existing user-space binaries. When the CPUs support features such as
> > > > +MTE, all regular memory must support MTE tags.
> > > > +
> > > > +On device memory that does not function in the same way as regular memory must
> > > > +not be added to the UEFI memory map or DT, or be discovered via ACPI's SRAT.
> > > > +
> > > > +On arm64, the kernel does not rewrite the UEFI memory map when memory is added
> > > > +or removed. On device memory that is present at boot, but must be removed later
> > >
> > > Might be worth giving an example of why memory 'must be removed'? I'm not sure
> > > what you are getting at there. Specific purpose memory?
> > >
> > > > +should be discovered via ACPI's SRAT to ensure it is not used for non-movable
> > > > +structures.
> > >
> > > Not sure I follow this part. It could be of type EFI_MEMORY_SP.
> >
> > EFI_MEMORY_SP is an attribute, not a type.
>
> Good point.
>
> >
> > > It should be in SRAT as well, but the EFI type should be sufficient to avoid
> > > problems.
> > > "The SPM attribute serves as a hint to the OS to avoid allocating this memory
> > > for core OS data or code that can not be relocated."
> > >
> > > Now I'm not sure the kernel is handling EFI_MEMORY_SP fully yet... If
> > > we need to exclude this approach for now, then this text should perhaps
> > > call it out explicitly.
> > >
> >
> > The problem with EFI_MEMORY_SP is that it is not a type, but an
> > attribute, which gives a hint to the OS about the nature of the
> > memory, which the OS is free to ignore.
>
> IIRC the way around that is to use the reserved type + EFI_MEMORY_SP.
> An unware bootloader or OS will then not use it and hence we are safe.
> An aware driver can then decide it is safe to "hotplug" said memory.
>
True, but then, what good does it do to describe this memory in the
UEFI memory map in the first place?
> >
> > The UEFI memory map is not only consumed by the OS, but by any driver
> > or OS loader that executes in the EFI boot environment, e.g., GPU
> > drivers or shim/grub bootloaders. If these are not enlightened and
> > understand what EFI_MEMORY_SP means, they may (and are entitled to)
> > treat this EFI_MEMORY_SP as if it were regular memory. If GRUB loads
> > the kernel into EFI_MEMORY_SP memory, it had better behave like
> > regular memory or things will fall apart.
>
> Two separate issues here. The 'broken' one where _SP or indeed
> hotplug flag is no use, and the one where it is 'must be removed later'
> and we just don't want to put unmovable allocations in it.
>
I am not sure I follow the 'must be removed' thing. Why is that needed?
> >
> > This means that EFI_MEMORY_SP is really only suitable to describe
> > aspects of the memory range that can be happily ignored. MTE or
> > atomics capability must be described in a different way.
> >
>
> That's indeed the intent. These are just hints and indeed not suitable for
> the cases where things are broken (MTE / Atomics). In those you
> should not be claiming it is normal memory at all. SRAT doesn't help
> you with that though.
>
> The hotplug flag is SRAT is also only a hint. OS doesn't have
> to take any notice or support it nor does any boot loader. Things
> will 'work' with the exception of hot-remove. If you definitely don't
> want your memory to be used by the OS for normal purposes, then
> don't present it in a form where it might be.
>
Agreed
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC PATCH] Documentation/arm64: describe the kernel's expectations of 'memory'
2021-05-17 12:25 ` Ard Biesheuvel
@ 2021-06-04 17:57 ` James Morse
0 siblings, 0 replies; 5+ messages in thread
From: James Morse @ 2021-06-04 17:57 UTC (permalink / raw)
To: Ard Biesheuvel, Jonathan Cameron
Cc: Linux ARM, Catalin Marinas, Will Deacon, linux-cxl
Hi Jonathan, Ard,
On 17/05/2021 13:25, Ard Biesheuvel wrote:
> On Mon, 17 May 2021 at 14:19, Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote:
>> On Mon, 17 May 2021 13:55:16 +0200 Ard Biesheuvel <ardb@kernel.org> wrote:
>>> On Mon, 17 May 2021 at 13:30, Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote:
>>>> On Mon, 17 May 2021 11:33:19 +0100 James Morse <james.morse@arm.com> wrote:>>>>> Document linux's expectations around the behaviour of memory as the
>>>>> +On arm64, the kernel does not rewrite the UEFI memory map when memory is added
>>>>> +or removed. On device memory that is present at boot, but must be removed later
>>>>
>>>> Might be worth giving an example of why memory 'must be removed'? I'm not sure
>>>> what you are getting at there.
[...]
>> Two separate issues here. The 'broken' one where _SP or indeed
>> hotplug flag is no use, and the one where it is 'must be removed later'
>> and we just don't want to put unmovable allocations in it.
> I am not sure I follow the 'must be removed' thing. Why is that needed?
This phrase was to cover people who want to remove memory that was present at boot... but
they didn't want it to be. I think dedicating it to VMs is the popular use case, (and, er,
bypassing all the OSes memory management...).
If its in the UEFI memory map, the kernel expects it can't be removed. It might be in use
by something, and even if its not - we don't want to rewrite the UEFI
tables/tree/lists/maps to remove it, and we certainly can't do that in a future proof manner.
It might not be relevant to CXL, but its one of the pain points of hotplug memory.
I'm not sure I can come up with a terse example:
| e.g. a memory carve-out that must be also be respected by a future OS loaded via kexec()
?
Thanks,
James
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-06-04 17:57 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20210517103319.5356-1-james.morse@arm.com>
2021-05-17 11:27 ` [RFC PATCH] Documentation/arm64: describe the kernel's expectations of 'memory' Jonathan Cameron
2021-05-17 11:55 ` Ard Biesheuvel
2021-05-17 12:17 ` Jonathan Cameron
2021-05-17 12:25 ` Ard Biesheuvel
2021-06-04 17:57 ` James Morse
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).