Hi Jason & Michael,
Kindly ping... Any progress for the efa .shutdown implementing? Thanks
in advance!
Thanks,
Tao Liu
On Wed, Apr 3, 2024 at 11:44 PM Jason Gunthorpe wrote:
>
> On Mon, Apr 01, 2024 at 04:23:32PM +0300, Margolin, Michael wrote:
> > Jason
> >
> > Thanks for your response,
On Tue, 23 Apr 2024 09:54:35 +0200 Thomas Weißschuh wrote:
> The series was split from my larger series sysctl-const series [0].
> It only focusses on the proc_handlers but is an important step to be
> able to move all static definitions of ctl_table into .rodata.
Split this per subsystem,
Hello Boris,
On 4/24/2024 9:48 AM, Borislav Petkov wrote:
On Mon, Apr 15, 2024 at 11:22:58PM +, Ashish Kalra wrote:
From: Ashish Kalra
For kexec use case, need to use and stick to the EFI memmap passed
from the first kernel via boot-params/setup data, hence,
skip efi_arch_mem_reserve()
Ard Biesheuvel writes:
> From: Ard Biesheuvel
>
> The kexec purgatory is built like a kernel module, i.e., a partially
> linked ELF object where each section is allocated and placed
> individually, and all relocations need to be fixed up, even place
> relative ones.
>
> This makes sense for
On Wed, 24 Apr 2024 at 22:04, Eric W. Biederman wrote:
>
> Ard Biesheuvel writes:
>
> > From: Ard Biesheuvel
> >
> > The kexec purgatory is built like a kernel module, i.e., a partially
> > linked ELF object where each section is allocated and placed
> > individually, and all relocations need
On Wed, Apr 24, 2024 at 1:53 PM Ard Biesheuvel wrote:
>
> Hi Brian,
>
> Thanks for taking a look.
>
> On Wed, 24 Apr 2024 at 19:39, Brian Gerst wrote:
> >
> > On Wed, Apr 24, 2024 at 12:06 PM Ard Biesheuvel wrote:
> > >
> > > From: Ard Biesheuvel
> > >
> > > The purgatory is almost entirely
On Wed, Apr 24, 2024 at 05:53:12PM +0200, Ard Biesheuvel wrote:
> From: Ard Biesheuvel
>
> The x86 purgatory, which does little more than verify a SHA-256 hash of
> the loaded segments, currently uses three different stacks:
> - one in .bss that is used to call the purgatory C code
> - one in
Hi Brian,
Thanks for taking a look.
On Wed, 24 Apr 2024 at 19:39, Brian Gerst wrote:
>
> On Wed, Apr 24, 2024 at 12:06 PM Ard Biesheuvel wrote:
> >
> > From: Ard Biesheuvel
> >
> > The purgatory is almost entirely position independent, without any need
> > for any relocation processing at
On Wed, Apr 24, 2024 at 12:06 PM Ard Biesheuvel wrote:
>
> From: Ard Biesheuvel
>
> The purgatory is almost entirely position independent, without any need
> for any relocation processing at load time except for the reference to
> the GDT in the entry code. Generate this reference at runtime
From: Ard Biesheuvel
Remove the handling of purgatories that are allocated, loaded and
relocated as individual ELF sections, which requires a lot of
post-processing on the part of the kexec loader. This has been
superseded by the use of fully linked PIE executables, which do not
require such
From: Ard Biesheuvel
Use a single symbol reference and offset addressing to load the contents
of the register file from memory, instead of using a symbol reference
for each, which results in larger code and more ELF overhead. While at
it, rename the individual labels with an .L prefix so they
From: Ard Biesheuvel
Now that the generic support is in place, switch to a fully linked PIE
ELF executable for the purgatory, so that it can be loaded as a single,
fully relocated image. This allows a lot of ugly post-processing logic
to simply be dropped.
Signed-off-by: Ard Biesheuvel
---
From: Ard Biesheuvel
The purgatory ELF object is typically a partially linked object, which
puts the burden on the kexec loader to lay out the executable in memory,
and this involves (among other things) deciding the placement of the
sections in memory, and fixing up all relocations (relative
From: Ard Biesheuvel
The x86 purgatory, which does little more than verify a SHA-256 hash of
the loaded segments, currently uses three different stacks:
- one in .bss that is used to call the purgatory C code
- one in .rodata that is only used to switch to an updated code segment
descriptor in
From: Ard Biesheuvel
The purgatory is a completely separate ELF executable carried inside the
kernel as an opaque binary blob. This means that function entry padding
and the associated ELF metadata are not exposed to the branch tracking
and code patching machinery, and can there be dropped from
From: Ard Biesheuvel
Data segment selectors are ignored in long mode so there is no point in
programming them. So clear them instead. This only leaves the code
segment entry in the GDT, which can be moved up a slot now that the
second slot is no longer used as the GDT descriptor.
Signed-off-by:
From: Ard Biesheuvel
The kexec purgatory is built like a kernel module, i.e., a partially
linked ELF object where each section is allocated and placed
individually, and all relocations need to be fixed up, even place
relative ones.
This makes sense for kernel modules, which share the address
From: Ard Biesheuvel
The purgatory is almost entirely position independent, without any need
for any relocation processing at load time except for the reference to
the GDT in the entry code. Generate this reference at runtime instead,
to remove the last R_X86_64_64 relocation from this code.
From: Ard Biesheuvel
The x86 purgatory switches to a new GDT twice, and the first time, it
doesn't even bother to switch to the new code segment. Given that data
segment selectors are ignored in long mode, and the fact that the GDT is
reprogrammed again after returning from purgatory(), the
On Wed, Apr 24, 2024 at 07:40:26AM -0700, Dave Hansen wrote:
> On 4/24/24 07:35, Kirill A. Shutemov wrote:
> >> Also, does this need to go to stable although it is kinda big for
> >> stable. If stable, do we need a smaller fix first which is backportable?
> > Correct me, if I am wrong, but I
On Mon, Apr 15, 2024 at 11:22:58PM +, Ashish Kalra wrote:
> From: Ashish Kalra
>
> For kexec use case, need to use and stick to the EFI memmap passed
> from the first kernel via boot-params/setup data, hence,
> skip efi_arch_mem_reserve() during kexec.
Please use this or similar scheme when
On 4/24/24 07:35, Kirill A. Shutemov wrote:
>> Also, does this need to go to stable although it is kinda big for
>> stable. If stable, do we need a smaller fix first which is backportable?
> Correct me, if I am wrong, but I believe TDX guest is the only user of
> ACPI MADT wake up method. At least
On Wed, Apr 24, 2024 at 03:50:52PM +0200, Borislav Petkov wrote:
> On Wed, Apr 24, 2024 at 11:38:42AM +0300, Kirill A. Shutemov wrote:
> > It was wrong from beginning. If ACPI MADT wake up method is used on the
> > platform, we cannot handle offline, regardless if it is TDX or not.
>
> Sounds to
On Wed, Apr 24, 2024 at 11:38:42AM +0300, Kirill A. Shutemov wrote:
> It was wrong from beginning. If ACPI MADT wake up method is used on the
> platform, we cannot handle offline, regardless if it is TDX or not.
Sounds to me like this fact should be a prominent part of the commit
message and
From: Haiqing Bai
When "CONFIG_ARM_LPAE" is enabled,3 level page table
is used by MMU, the "SECTION_SIZE" is defined with
(1 << 21), but 'add_buffer_phys_virt()' hardcode this
to (1 << 20).
Suggested-By: fredrik.markst...@gmail.com
Signed-off-by: Haiqing Bai
Signed-off-by: Alexander Kanavin
On Mon, Apr 22, 2024 at 04:49:27PM +0200, Krzysztof Kozlowski wrote:
> On 22/04/2024 16:27, Konrad Dybcio wrote:
> >
> >
> > On 3/28/24 16:44, Joel Granados wrote:
> >> What?
> >> These commits remove the sentinel element (last empty element) from the
> >> sysctl arrays of all the files under
On Mon, Apr 22, 2024 at 04:27:47PM +0200, Konrad Dybcio wrote:
>
>
> On 3/28/24 16:44, Joel Granados wrote:
> > What?
> > These commits remove the sentinel element (last empty element) from the
> > sysctl arrays of all the files under the "kernel/" directory that use a
> > sysctl array for
On Tue, Apr 23, 2024 at 06:02:58PM +0200, Borislav Petkov wrote:
> >
> > Currently CPU hotplug is prevented based on the confidential computing
> > attribute which is set for Intel TDX. But TDX is not the only possible
> > user of the wake up method.
> >
> > Disable CPU offlining on ACPI MADT
On Mon, Apr 22, 2024 at 05:07:59PM +0200, Krzysztof Kozlowski wrote:
> On 22/04/2024 16:57, Konstantin Ryabitsev wrote:
> > On Mon, Apr 22, 2024 at 04:49:27PM +0200, Krzysztof Kozlowski wrote:
> These commits remove the sentinel element (last empty element) from
> the
> sysctl
On Mon, Apr 22, 2024 at 04:27:47PM +0200, Konrad Dybcio wrote:
>
>
> On 3/28/24 16:44, Joel Granados wrote:
> > What?
> > These commits remove the sentinel element (last empty element) from the
> > sysctl arrays of all the files under the "kernel/" directory that use a
> > sysctl array for
30 matches
Mail list logo
