> On 24-Feb-2024, at 12:33 AM, Aditya Gupta wrote:
>
> Below error was noticed when running makedumpfile on linux-next kernel
> crash (linux-next tag next-20240121):
>
>...
>Checking for memory holes : [100.0 %] | readpage_elf: Attempt to read
> non-existent page at 0xc.
On 2/12/24 02:44, Kirill A. Shutemov wrote:
> Despite the name, E820_TYPE_ACPI covers not only ACPI data, but also EFI
> tables and might be required by kernel to function properly.
Lovely. You learn something new every day.
Reviewed-by: Dave Hansen
On 2/12/24 02:44, Kirill A. Shutemov wrote:
> +static void tdx_kexec_stop_conversion(bool crash)
> +{
> + /* Stop new private<->shared conversions */
> + conversion_allowed = false;
> +
> + /*
> + * Make sure conversion_allowed is cleared before checking
> + *
On 2/12/24 02:44, Kirill A. Shutemov wrote:
> The kernel will convert all shared memory back to private during kexec.
> The direct mapping page tables will provide information on which memory
> is shared.
>
> It is extremely important to convert all shared memory. If a page is
> missed, it will
Below error was noticed when running makedumpfile on linux-next kernel
crash (linux-next tag next-20240121):
...
Checking for memory holes : [100.0 %] | readpage_elf: Attempt to read
non-existent page at 0xc.
[ 17.551718] kdump.sh[404]: readmem: type_addr: 0,
On 2/23/24 10:45, Dave Hansen wrote:
> Always filling out the level allows using lookup_address() to
> iterate over kernel page tables.
This doesn't parse very well. How about this instead:
Always filling out the level allows using lookup_address() to
precisely skip
On 2/12/24 02:44, Kirill A. Shutemov wrote:
> lookup_address() only returns correct page table level for the entry if
> the entry is not none.
Currently, lookup_address() returns two things:
1. A "pte_t" (which might be a p[g4um]d_t)
2. The 'level' of the page tables where the "pte_t" was
On Fri, Feb 23, 2024 at 06:20:27PM +, Andrew Cooper wrote:
> On 23/02/2024 5:54 pm, Eric Biggers wrote:
> > On Fri, Feb 23, 2024 at 04:42:11PM +, Andrew Cooper wrote:
> >> Yes, and I agree. We're not looking to try and force this in with
> >> underhand tactics.
> >>
> >> But a blind "nack
On 2/12/24 02:44, Kirill A. Shutemov wrote:
> TDX is going to have more than one reason to fail
> enc_status_change_prepare().
>
> Change the callback to return errno instead of assuming -EIO;
> enc_status_change_finish() changed too to keep the interface symmetric.
Good riddance to the bools.
On 23/02/2024 5:54 pm, Eric Biggers wrote:
> On Fri, Feb 23, 2024 at 04:42:11PM +, Andrew Cooper wrote:
>> Yes, and I agree. We're not looking to try and force this in with
>> underhand tactics.
>>
>> But a blind "nack to any SHA-1" is similarly damaging in the opposite
>> direction.
>>
>
On Fri, Feb 23, 2024 at 04:42:11PM +, Andrew Cooper wrote:
>
> Yes, and I agree. We're not looking to try and force this in with
> underhand tactics.
>
> But a blind "nack to any SHA-1" is similarly damaging in the opposite
> direction.
>
Well, reviewers have said they'd prefer that SHA-1
On 23/02/2024 9:27 am, Ard Biesheuvel wrote:
> On Thu, 22 Feb 2024 at 13:30, Andrew Cooper wrote:
>> On 22/02/2024 9:34 am, Ard Biesheuvel wrote:
>>> On Thu, 22 Feb 2024 at 04:05, Andrew Cooper
>>> wrote:
On 15/02/2024 8:17 am, Ard Biesheuvel wrote:
> On Wed, 14 Feb 2024 at 23:31, Ross
Hi,
On Wed, Jan 17 2024, Alexander Graf wrote:
> When we finish populating our memory, we don't want to lose the scratch
> region as memory we can use for useful data. Do do that, we mark it as
> CMA memory. That means that any allocation within it only happens with
> movable memory which we can
On Mon, Feb 12 2024 at 12:44, Kirill A. Shutemov wrote:
> acpi_mp_wake_mailbox_paddr and acpi_mp_wake_mailbox initialized once
> during ACPI MADT init and never changed.
>
> Signed-off-by: Kirill A. Shutemov
> Acked-by: Kai Huang
Reviewed-by: Thomas Gleixner
On Mon, Feb 12 2024 at 12:44, Kirill A. Shutemov wrote:
> In order to prepare for the expansion of support for the ACPI MADT
> wakeup method, move the relevant code into a separate file.
>
> Introduce a new configuration option to clearly indicate dependencies
> without the use of ifdefs.
>
>
On Mon, Feb 12 2024 at 12:44, Kirill A. Shutemov wrote:
> MADT Multiprocessor Wakeup structure version 1 brings support of CPU
> offlining: BIOS provides a reset vector where the CPU has to jump to
> for offlining itself. The new TEST mailbox command can be used to test
> whether the CPU offlined
On Mon, Feb 12 2024 at 12:44, Kirill A. Shutemov wrote:
> ACPI MADT doesn't allow to offline a CPU after it was onlined. This
> limits kexec: the second kernel won't be able to use more than one CPU.
>
> To prevent a kexec kernel from onlining secondary CPUs invalidate the
> mailbox address in the
On Mon, Feb 12 2024 at 12:44, Kirill A. Shutemov wrote:
> If the helper is defined, it is called instead of halt() to stop the CPU
> at the end of stop_this_cpu() and on crash CPU shutdown.
>
> ACPI MADT will use it to hand over the CPU to BIOS in order to be able
> to wake it up again after
On Mon, Feb 12 2024 at 12:44, Kirill A. Shutemov wrote:
> To prepare for the addition of support for MADT wakeup structure version
> 1, it is necessary to provide more appropriate names for the fields in
> the structure.
>
> The field 'mailbox_version' renamed as 'version'. This field signifies
>
On Thu, 22 Feb 2024 at 14:58, Daniel P. Smith
wrote:
>
> On 2/15/24 03:40, Ard Biesheuvel wrote:
> > On Wed, 14 Feb 2024 at 23:32, Ross Philipson
> > wrote:
> >>
> >> From: "Daniel P. Smith"
> >>
> >> The Secure Launch platform module is a late init module. During the
> >> init call, the TPM
On Thu, 22 Feb 2024 at 13:30, Andrew Cooper wrote:
>
> On 22/02/2024 9:34 am, Ard Biesheuvel wrote:
> > On Thu, 22 Feb 2024 at 04:05, Andrew Cooper
> > wrote:
> >> On 15/02/2024 8:17 am, Ard Biesheuvel wrote:
> >>> On Wed, 14 Feb 2024 at 23:31, Ross Philipson
> >>> wrote:
> From: "Daniel
Currently makedumpfile depends on reading the 'cur_cpu_spec' kernel
symbol to get the current MMU type on PowerPC64.
The disadvantage with this approach was that it depends on bit '0x40'
('MMU_FTR_TYPE_RADIX') being set in 'cur_cpu_spec->mmu_features',
which implies kernel developers have to be
On Fri, Feb 23, 2024 at 03:54:12PM +0800, Baoquan He wrote:
> Add maintainer Kazu to CC.
Thanks, I missed him, will resend this patch with him in CC.
Thanks,
Aditya Gupta
>
> On 02/23/24 at 11:23am, Aditya Gupta wrote:
> > Currently makedumpfile depends on reading the 'cur_cpu_spec' kernel
> >
23 matches
Mail list logo
