On Thu, Jun 13, 2024 at 04:41:00PM +0300, Kirill A. Shutemov wrote:
> It is easy enough to do. See the patch below.
Thanks, will have a look.
> But I am not sure if I can justify it properly. If someone doesn't really
> need 5-level paging, disabling it at compile-time would save ~34K of
>
On Wed, Jun 12, 2024 at 12:24:30PM +0300, Kirill A. Shutemov wrote:
> I will try to deliver it in timely manner.
:-P
> > Yeah, we have a bunch of different pagetable manipulating things, all
> > with their peculiarities and unifying them and having a good set of APIs
> > which everything else
On Tue, Jun 11, 2024 at 06:47:05PM +0300, Kirill A. Shutemov wrote:
> Borislav, given this code deduplication effort is not trivial, maybe we
> can do it as a separate patchset on top of this one?
Sure, as long as it gets done and doesn't get delayed indefinitely by
new and more important
On Fri, Jun 07, 2024 at 06:14:28PM +0300, Kirill A. Shutemov wrote:
> I was able to address this issue by switching cpa_lock to a mutex.
> However, this solution will only work if the callers for set_memory
> interfaces are not called from an atomic context. I need to verify if
> this is
On Thu, May 30, 2024 at 11:37:14PM +, Ashish Kalra wrote:
> - lines = boot_params_ptr->screen_info.orig_video_lines;
> - cols = boot_params_ptr->screen_info.orig_video_cols;
> + if (!(sev_status & MSR_AMD64_SEV_ES_ENABLED)) {
> + lines =
On Wed, Jun 05, 2024 at 03:21:42PM +0300, Kirill A. Shutemov wrote:
> If a page can be accessed via private mapping is determined by the
> presence in Secure EPT. This state persist across kexec.
I just love it how I tickle out details each time I touch this comment
because we three can't write a
On Wed, Jun 05, 2024 at 10:17:22AM +0200, Ard Biesheuvel wrote:
> I'd argue for the opposite: ideally, the difference between the first
> boot and not-the-first-boot should be abstracted away by the
> 'bootloader' side of kexec as much as possible, so that the tricky
> early startup code doesn't
Moving Ard and Dan to To:
On Wed, Jun 05, 2024 at 10:28:18AM +0800, Dave Young wrote:
> Ok, thanks! I think the right way is creating two patches, one to
> remove the __efi_memmap_free,
Yap, that
f0ef6523475f ("efi: Fix efi_memmap_alloc() leaks")
needs revisiting.
So AFAIU, the flow is
On Wed, Jun 05, 2024 at 10:53:44AM +0800, Dave Young wrote:
> It's something good to have but not must for the time being, also no
> idea how to save the status across boot, for EFI boot case probably a
> EFI var can be used;
Yes.
> but how can it be cleared in case of physical boot. Otherwise
On Tue, Jun 04, 2024 at 07:14:00PM +0300, Kirill A. Shutemov wrote:
> /*
>* If tdx_enc_status_changed() fails, it leaves memory
>* in an unknown state. If the memory remains shared,
>* it can result in an
On Tue, Jun 04, 2024 at 07:09:56PM +0800, Dave Young wrote:
> Anyway there is not such a helper for all cases.
But maybe there should be...
This is not the first case where the need arises to be able to say:
if (am I a kexeced kernel)
in code.
Perhaps we should have a global var
On Tue, Jun 04, 2024 at 06:21:27PM +0300, Kirill A. Shutemov wrote:
> What about this?
Yeah, LGTM.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Tue, Jun 04, 2024 at 09:23:58AM +0800, Dave Young wrote:
> kexec_in_progress is only for checking if this is in a reboot (kexec) code
> path.
> But eif_mem_reserve is only called during the boot time so checking
> kexec_in_progress is meaningless here.
> current_kernel_is_booted_via_kexec !=
On Mon, Jun 03, 2024 at 05:24:00PM -0700, H. Peter Anvin wrote:
> Trying one more time; sorry (again) if someone receives this in duplicate.
>
> > > >
> > > > diff --git a/arch/x86/kernel/relocate_kernel_64.S
> > > > b/arch/x86/kernel/relocate_kernel_64.S
> > > > index
On Mon, Jun 03, 2024 at 12:08:48PM -0500, Kalra, Ashish wrote:
> efi_arch_mem_reserve().
Now it only remains for you to explain why...
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
___
kexec mailing list
On Mon, Jun 03, 2024 at 12:05:45PM -0500, Kalra, Ashish wrote:
> Re-sending this, last response got garbled.
And this got linewrapped.
Thunderbird section in Documentation/process/email-clients.rst.
> index f0cc00032751..6f398c59278a 100644
> --- a/arch/x86/platform/efi/quirks.c
> +++
On Mon, Jun 03, 2024 at 11:48:03AM -0500, Kalra, Ashish wrote:
> Yes, something similar as above, as efi_mem_reserve() is used to reserve
> boot service memory and is not necessary for kexec boot.
>
> So, Dave Young (dyo...@redhat.com) had suggested that we skip
> efi_arch_mem_reserve() for kexec
On Mon, Jun 03, 2024 at 09:01:49AM -0500, Kalra, Ashish wrote:
> If we skip efi_arch_mem_reserve() (which should probably be anyway skipped
> for kexec case), then for kexec boot, EFI memmap is memremapped in the same
> virtual address as the first kernel and not the allocated memblock address.
On Thu, May 30, 2024 at 11:36:55PM +, Ashish Kalra wrote:
> From: Ashish Kalra
>
> With SNP guest kexec observe the following efi memmap corruption :
>
> [0.00] efi: EFI v2.7 by EDK II
> [0.00] efi: SMBIOS=0x7e33f000 SMBIOS 3.0=0x7e33d000 ACPI=0x7e57e000
> ACPI
On Tue, May 28, 2024 at 12:55:21PM +0300, Kirill A. Shutemov wrote:
> MADT Multiprocessor Wakeup structure version 1 brings support of CPU
s/of /for /
> 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
>
On Sun, Jun 02, 2024 at 05:23:03PM +0300, Kirill A. Shutemov wrote:
> + /*
> + * The only thing one can do at this point on failure
> + * is panic. It is reasonable to proceed.
It makes even less sense now: panic() means "all stops and
On Fri, May 31, 2024 at 12:34:49PM -0500, Kalra, Ashish wrote:
> SNP guest kexec patches are based on top of this patch-series and SNP guests
> also need this exclusive mem_enc_lock protection, so CC_ATTR_MEM_ENCRYPT
> makes sense to be used here.
Well, for the future, I'd encourage you to always
On Tue, May 28, 2024 at 12:55:14PM +0300, Kirill A. Shutemov wrote:
> +static void tdx_kexec_finish(void)
> +{
> + unsigned long addr, end;
> + long found = 0, shared;
> +
> + lockdep_assert_irqs_disabled();
> +
> + addr = PAGE_OFFSET;
> + end = PAGE_OFFSET + get_max_mapped();
On Wed, May 29, 2024 at 01:33:35PM +0100, Andrew Cooper wrote:
> Seems I've gained a reputation...
Yes you have. You have this weird interest in very deep uarch details
that I can't share. Not at that detail. :-P
> jmp 1f dates back to ye olde 8086, which started the whole trend of the
>
On Wed, May 29, 2024 at 02:17:29PM +0300, Kirill A. Shutemov wrote:
> > That jmp 1f becomes redundant now as it simply jumps 1 line below.
> >
>
> Nothing changed wrt this jump. It dates back to initial kexec
> implementation.
>
> See 5234f5eb04ab ("[PATCH] kexec: x86_64 kexec implementation").
On Tue, May 28, 2024 at 12:55:13PM +0300, Kirill A. Shutemov wrote:
> diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
> index 28ac3cb9b987..6cade48811cc 100644
> --- a/arch/x86/include/asm/x86_init.h
> +++ b/arch/x86/include/asm/x86_init.h
> @@ -149,12 +149,21 @@
5 files changed, 96 insertions(+), 85 deletions(-)
> create mode 100644 arch/x86/kernel/acpi/madt_wakeup.c
Acked-by: Borislav Petkov (AMD)
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Tue, Apr 09, 2024 at 02:30:05PM +0300, Kirill A. Shutemov wrote:
> To prepare for the addition of support for MADT wakeup structure version
"In order to support... "
> 1, it is necessary to provide more appropriate names for the fields in
> the structure.
>
> The field 'mailbox_version'
On Tue, Apr 09, 2024 at 02:30:03PM +0300, Kirill A. Shutemov wrote:
> Subject: Re: [PATCHv10 11/18] x86/mm: Make e820_end_ram_pfn() cover
> E820_TYPE_ACPI ranges
^^^
e820__end_of_ram_pfn()
> e820__end_of_ram_pfn() is used to calculate max_pfn
On Mon, May 06, 2024 at 06:37:19PM +0300, Kirill A. Shutemov wrote:
> "second kernel" is nomenclature kexec folks are using, but okay.
And the "third kernel" is the one which got kexec-ed the second time?
You can make it: "The second, kexec-ed kernel" and then it is perfectly
clear.
> > > + /*
On Mon, May 06, 2024 at 04:22:02PM +0300, Kirill A. Shutemov wrote:
> I do. See comment just above enc_kexec_stop_conversion() call.
If you mean this:
/*
* Call enc_kexec_stop_conversion() while all CPUs are still active and
* interrupts are enabled. This will allow all
On Tue, Apr 09, 2024 at 02:30:02PM +0300, Kirill A. Shutemov wrote:
> TDX guests allocate shared buffers to perform I/O. It is done by
> allocating pages normally from the buddy allocator and converting them
> to shared with set_memory_decrypted().
>
> The second kernel has no idea what memory is
On Sat, Apr 27, 2024 at 08:06:34PM +0300, Kirill A. Shutemov wrote:
> Subject: Re: [PATCHv10.1 09/18] x86/mm: Adding callbacks to prepare encrypted
> memory for kexec
s/Adding/Add/
> AMD SEV and Intel TDX guests allocate shared buffers for performing I/O.
> This is done by allocating pages
On Thu, May 02, 2024 at 03:22:29PM +0200, Borislav Petkov wrote:
> On Tue, Apr 30, 2024 at 05:49:08PM +0300, Kirill A. Shutemov wrote:
> > I assume all of these new labels have to be prefixed with ".L", right?
>
> Oh yes, please.
Here's a fixed version:
---
From: &quo
On Tue, Apr 30, 2024 at 05:49:08PM +0300, Kirill A. Shutemov wrote:
> I assume all of these new labels have to be prefixed with ".L", right?
Oh yes, please.
Thx!
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
___
same-number labels are
just abominable.
Thx.
---
From: "Borislav Petkov (AMD)"
Date: Tue, 30 Apr 2024 15:00:16 +0200
Subject: [PATCH] x86/relocate_kernel: Use named labels for less confusion
That identity_mapped() function was loving that "1" label to the point
of completely
On Mon, Apr 29, 2024 at 06:16:54PM +0300, Kirill A. Shutemov wrote:
> Yes, that's what happens in current upstream.
Let's rewrite that commit message then:
"TDX guests run with MCA enabled (CR4.MCE=1b) from the very start. If
that bit is cleared during CR4 register reprogramming during boot or
On Mon, Apr 29, 2024 at 05:29:23PM +0300, Kirill A. Shutemov wrote:
> Hm. I considered the sentence to be in imperative mood already. I guess I
> don't fully understand what imperative mood is. Will fix.
This:
https://en.wikipedia.org/wiki/Imperative_mood
but basically the sentence is a
On Mon, Apr 29, 2024 at 04:17:38PM +0300, Kirill A. Shutemov wrote:
> As I mentioned above, clearing CR4.MCE triggers #VE. It is quirk of the
> platform.
You mean when identity_mapped() runs as part of a kexec-ed kernel, it
might clear CR4.MCE and that would trigger the #VE?
So, if that is
On Tue, Apr 09, 2024 at 02:29:58PM +0300, 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.
On Tue, Apr 09, 2024 at 06:26:05PM +0300, Kirill A. Shutemov wrote:
> From 6be428e3b1c6fb494b2c48ba6a7c133514a0b2b4 Mon Sep 17 00:00:00 2001
> From: "Kirill A. Shutemov"
> Date: Fri, 10 Feb 2023 12:53:11 +0300
> Subject: [PATCHv10.1 05/18] x86/kexec: Keep CR4.MCE set during kexec for TDX
> guest
On Tue, Apr 09, 2024 at 02:30:01PM +0300, Kirill A. Shutemov wrote:
> diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> index e74d0c4286c1..7a1560d7e62d 100644
> --- a/arch/x86/kernel/crash.c
> +++ b/arch/x86/kernel/crash.c
> @@ -128,6 +128,12 @@ void
On Fri, Apr 26, 2024 at 10:28:41AM -0500, Kalra, Ashish wrote:
> "Chained guest kexec" is when we are in a guest and kexec-ing into a new
> kernel and then this kernel kexecs into another and so on ...
Make sure to explain your terminology:
$ git grep -rE "chained.*kexec"
$
and there's nothing
On Fri, Apr 26, 2024 at 09:47:02AM -0500, Kalra, Ashish wrote:
> I should have mentioned *chained* guest kexec above instead of nested guest
> kexec.
What is a "chained guest kexec" now?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Wed, Apr 24, 2024 at 04:17:09PM -0500, Kalra, Ashish wrote:
> With SNP guest kexec and during nested guest kexec, observe the following
> efi memmap corruption :
Before we delve any deeper here, lemme make sure I understand this
correctly:
* You're in a SNP guest and you're kexec-ing into a
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 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
On Tue, Apr 09, 2024 at 02:29:56PM +0300, Kirill A. Shutemov wrote:
> ACPI MADT doesn't allow to offline CPU after it got woke up.
In all your text: s/woke/woken/g
>
> Currently CPU hotplug is prevented based on the confidential computing
> attribute which is set for Intel TDX. But TDX is not
On Fri, Apr 19, 2024 at 04:31:39PM +0300, Kirill A. Shutemov wrote:
> Yes, it is one-off. I guess we could use READ_ONCE()/WRITE_ONCE() to
> access the variable with the same result. I am not sure why it would be
> better.
Nah, and it is not even the first one-off:
cpu_hotplug_disable/_enable()
On Tue, Apr 09, 2024 at 02:29:53PM +0300, Kirill A. Shutemov wrote:
> diff --git a/arch/x86/kernel/acpi/Makefile b/arch/x86/kernel/acpi/Makefile
> index fc17b3f136fe..8c7329c88a75 100644
> --- a/arch/x86/kernel/acpi/Makefile
> +++ b/arch/x86/kernel/acpi/Makefile
> @@ -1,11 +1,12 @@
> #
On Tue, Apr 09, 2024 at 02:29:55PM +0300, Kirill A. Shutemov wrote:
> +/* Declare CPU offlining not supported */
> +void cpu_hotplug_disable_offlining(void)
> +{
> + cpu_maps_update_begin();
"/*
* The following two APIs (cpu_maps_update_begin/done) must be used when
* attempting to
On Tue, Apr 09, 2024 at 08:42:38PM +, Ashish Kalra wrote:
> From: Ashish Kalra
>
> Add sev_es_enabled() function to detect if SEV-ES
> support is enabled.
And use it exactly once?
Nah, use sev_status directly.
--
Regards/Gruss,
Boris.
On Thu, Aug 03, 2023 at 04:27:41PM +0200, Ard Biesheuvel wrote:
> https://lists.gnu.org/archive/html/grub-devel/2023-08/msg5.html
>
> Coming to your distro any decade now!
Cool. The less 32-bit crap we have to deal with, the better.
Thx.
--
Regards/Gruss,
Boris.
On Thu, Aug 03, 2023 at 01:11:54PM +0200, Ard Biesheuvel wrote:
> Sadly, not only 'old' grubs - GRUB mainline only recently added
> support for booting Linux/x86 via the EFI stub (because I wrote the
> code for them),
haha.
> but it will still fall back to the previous mode for kernels that are
On Wed, Aug 02, 2023 at 04:55:27PM +0200, Ard Biesheuvel wrote:
> ... because now, entering via startup_32 is broken, given that it only
> maps the kernel image itself and relies on the #PF handling for
> everything else it accesses, including firmware tables.
>
> AFAICT this also means that
On Wed, Aug 02, 2023 at 08:40:36AM -0500, Tom Lendacky wrote:
> Short of figuring out how to map page accesses earlier through the
> boot_page_fault IDT routine
And you want to do that because?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Wed, Aug 02, 2023 at 04:22:54PM +0800, Tao Liu wrote:
> Thanks for the patch! I have tested it on the lenovo machine in the
> past few days, no issue found, so the patch tests OK.
Thanks for testing!
Mike, Tom, the below ok this way?
---
From: "Borislav Petkov (AMD)"
Date:
On Thu, Jul 27, 2023 at 07:03:26PM +0800, Tao Liu wrote:
> Hi Borislav,
>
> Sorry for the late response. I spent some time retesting your patch
> against 6.5.0-rc1 and 6.5.0-rc3, and it is OK. So
>
> Reported-and-tested-by: Tao Liu
>
> And will we use this patch as a workaround or will we wait
On Mon, Jul 17, 2023 at 09:53:06PM +0800, Tao Liu wrote:
> ...snip...
> [ 21.360763] nvme0n1: p1 p2 p3
> [ 21.364207] igc :03:00.0: PTM enabled, 4ns granularity
> [ 21.421097] pps pps1: new PPS source ptp1
> [ 21.425396] igc :03:00.0 (unnamed net_device) (uninitialized): PHC
>
On Thu, Jun 01, 2023 at 03:20:44PM +0800, Tao Liu wrote:
> arch/x86/kernel/machine_kexec_64.c | 35 ++
> 1 file changed, 31 insertions(+), 4 deletions(-)
Ok, pls try this totally untested thing.
Thx.
---
diff --git a/arch/x86/boot/compressed/sev.c
On Fri, Jul 07, 2023 at 10:25:15AM -0500, Michael Roth wrote:
> ...
> It would be unfortunate if we finally abandoned this path because of the
> issue being hit here though. I think the patch posted here is the proper
> resolution to the issue being hit, and I'm hoping at this point we've
>
On Fri, Jul 07, 2023 at 10:22:56AM +0200, Joerg Roedel wrote:
> On Fri, Jul 07, 2023 at 12:23:59PM +0800, Baoquan He wrote:
> > I am wondering why we don't detect the cpu type and return early inside
> > sev_enable() if it's Intel cpu.
> >
> > We can't rely on CONFIG_AMD_MEM_ENCRYPT to decide if
On Thu, Jun 01, 2023 at 03:20:44PM +0800, Tao Liu wrote:
> A kexec kernel bootup hang is observed on Intel Atom cpu due to unmapped
s/cpu/CPU/g
> EFI config table.
>
> Currently EFI system table is identity-mapped for the kexec kernel, but EFI
> config table is not mapped explicitly:
Why does
On Thu, Mar 30, 2023 at 11:31:27AM -0400, Steven Rostedt wrote:
> On Thu, 30 Mar 2023 17:18:26 +0200
> Borislav Petkov wrote:
>
> > On Thu, Mar 30, 2023 at 11:15:23AM -0400, Steven Rostedt wrote:
> > > > Make sure that the .text section is not divided in multiple o
On Thu, Mar 30, 2023 at 11:15:23AM -0400, Steven Rostedt wrote:
> > Make sure that the .text section is not divided in multiple overlapping
> > sections. This is not supported by kexec_file.
And?
What is the failure scenario? Why are you fixing it? Why do we care?
This is way too laconic.
--
On Wed, Feb 08, 2023 at 11:21:13AM +0800, RuiRui Yang wrote:
> > There is only one question regarding CPU microcode loading: it
> > seems the microcode is not "updated early" with kexec upon "boot".
You lost me here: when you load a kernel and you have builtin microcode
or have supplied it
On Wed, Jan 11, 2023 at 11:00:37PM -0800, Pawan Gupta wrote:
> > SPEC_CTRL_RRSBA_DIS_S is a disable bit and I presume it needs to stay
> > enabled.
>
> The mitigation is enabled when this bit is set. When set, it prevents RET
> target to be predicted from alternate predictors (BTB). This should
On Mon, Nov 28, 2022 at 07:31:48AM -0800, Breno Leitao wrote:
> Currently x86_spec_ctrl_base is read at boot time, and speculative bits
> are set if configs are enable, such as MSR[SPEC_CTRL_IBRS] is enabled if
> CONFIG_CPU_IBRS_ENTRY is configured. These MSR bits are not cleared if
> the
On Wed, Dec 07, 2022 at 09:57:48PM +0800, Baoquan He wrote:
> I thought we usually need to introduce the kernel config option, then
> add code related to it, so that is a wrong idea.
It depends: sometimes it is prudent to add the code behind an ifdeffery
first but have it not being buildable so
On Wed, Dec 07, 2022 at 08:36:13PM +0800, Baoquan He wrote:
> Below is my last reply to Eric about my thinking on this.
Yes, I saw that.
So think about it: if a CONFIG_ item is not present, what does that mean
for the code which is enclosed around it?
--
Regards/Gruss,
Boris.
On Wed, Nov 16, 2022 at 04:46:43PM -0500, Eric DeVolder wrote:
> When CPU or memory is hot un/plugged, the crash elfcorehdr, which
> describes the CPUs and memory in the system, must also be updated.
>
> A new elfcorehdr is generated from the available CPUs and memory
> into a buffer, and then
On Wed, Nov 16, 2022 at 04:46:39PM -0500, Eric DeVolder wrote:
> +#ifndef arch_map_crash_pages
> +/*
> + * NOTE: The addresses and sizes passed to this routine have
> + * already been fully aligned on page boundaries. There is no
> + * need for massaging the address or size.
> + */
> +static
On Fri, Nov 25, 2022 at 11:26:53AM +0800, Baoquan He wrote:
> This kernel config CRASH_HOTPLUG is added in patch 7, but we have used
> it in the previous patch, not sure if this is acceptable.
Why would it not be acceptable?
--
Regards/Gruss,
Boris.
On Mon, Nov 28, 2022 at 03:02:19PM -0800, Pawan Gupta wrote:
> Yes thats a cleaner approach, except that the late microcode load will
> ruin the MSR:
>
> microcode_reload_late()
> microcode_check()
> get_cpu_cap()
> init_speculation_control()
Microcode late loading ruins a lot of
On Mon, Nov 28, 2022 at 02:03:58PM -0800, Pawan Gupta wrote:
> diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> index 3e3230cccaa7..cfc2ed2661fc 100644
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -66,7 +66,7 @@ static
On Thu, Nov 24, 2022 at 02:46:50AM -0800, Breno Leitao wrote:
> Currently x86_spec_ctrl_base is read at boot time, and speculative bits
> are set if configs are enable, such as MSR[SPEC_CTRL_IBRS] is enabled if
> CONFIG_CPU_IBRS_ENTRY is configured. These MSR bits are not cleared if
> the
tion and secondary CPUs disabled.
> >>
> >> Users want the information collected in this panic notifier though,
> >> so in order to balance the risk/benefit, let's skip the altera panic
> >> notifier if kdump is loaded. While at it, remove a useless header
> &
On Wed, Nov 09, 2022 at 09:48:33AM -0600, Eric DeVolder wrote:
> ...
> which then defaults HOTPLUG_CPU to on and thus this code/ifdef in question.
defconfig can sometimes lag reality. In this case, the majority of
machines have SMP=y because the majority of machines out there are,
well,
On Wed, Nov 02, 2022 at 01:57:14PM -0500, Eric DeVolder wrote:
> But I sense I missing your point?
No no, you're spot on. So moving that into the kernel and making it more
robust is always a good thing.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Wed, Nov 02, 2022 at 11:54:08AM -0500, Eric DeVolder wrote:
> Technically the answer is no; cpu hotplug events are independent of memory
> hotplug events, but both are written into the elfcorehdr, so in reality
> yes... The elfcorehdr contains a single list of Phdrs describing CPUs and
> crash
On Wed, Nov 02, 2022 at 09:55:06AM -0500, Eric DeVolder wrote:
> > "But on a plain simple laptop or workstation which has CPU hotplug,
> > would it make sense for the crash ranges to get updated too when CPUs
> > are offlined?
>
> Yes, it does.
Why?
--
Regards/Gruss,
Boris.
On Tue, Nov 01, 2022 at 10:45:00AM -0500, Eric DeVolder wrote:
> As I'm re-reading that message, I suspect now the preference is to just to
> strike this ifdiffery line in this file and have the code always present?
>
> If the preference is actually for CRASH_HOTPLUG, then let me know.
Well, it
On Mon, Oct 31, 2022 at 03:36:04PM -0400, Eric DeVolder wrote:
> +#if defined(CONFIG_HOTPLUG_CPU) || defined(CONFIG_MEMORY_HOTPLUG)
What happened to that here:
https://lore.kernel.org/r/y1e85gqb3kzlx...@zn.tnic
?
--
Regards/Gruss,
Boris.
On Fri, Oct 28, 2022 at 04:22:54PM -0500, Eric DeVolder wrote:
> /*
> * For the kexec_file_load() syscall path, specify the maximum number of
> * memory regions that the elfcorehdr buffer/segment can accommodate.
> * These regions are obtained via walk_system_ram_res(); eg. the
> * 'System
On Fri, Oct 28, 2022 at 02:26:58PM -0500, Eric DeVolder wrote:
> config CRASH_MAX_MEMORY_RANGES
> depends on CRASH_DUMP && KEXEC_FILE && MEMORY_HOTPLUG
> int
> default 8192
> help
> For the kexec_file_load path, specify the maximum number of
> memory regions, eg. as
On Fri, Oct 28, 2022 at 10:29:45AM -0500, Eric DeVolder wrote:
> So it is with this in mind that I suggest we stay with the statically sized
> elfcorehdr buffer.
>
> If that can be agreed upon, then it is "just a matter" of picking a useful
> elfcorehdr size. Currently that size is derived from
On Thu, Oct 27, 2022 at 02:24:11PM -0500, Eric DeVolder wrote:
> Be aware, in reality, that if the system was fully populated, it would not
> actually consume all 8192 phdrs. Rather /proc/iomem would essentially show a
> large contiguous address space which would require just a single phdr.
Then
On Wed, Oct 12, 2022 at 11:20:59AM -0500, Eric DeVolder wrote:
> I once had CONFIG_CRASH_HOTPLUG, but you disagreed.
>
> https://lore.kernel.org/lkml/ylgot+ludql+g%2...@zn.tnic/
>
> From there I simply went with
>
> #if defined(CONFIG_HOTPLUG_CPU) || defined(CONFIG_MEMORY_HOTPLUG)
>
> which
On Thu, Oct 13, 2022 at 10:57:28AM +0800, Baoquan He wrote:
> The concern to range number mainly is on Virt guest systems.
And why would virt emulate 1K hotpluggable DIMM slots and not emulate a
real machine?
> On baremetal system, basically only very high end server support
> memory hotplug. I
On Wed, Oct 12, 2022 at 03:19:19PM -0500, Eric DeVolder wrote:
> We run here QEMU with the ability for 1024 DIMM slots.
QEMU, haha.
What is the highest count of DIMM slots which are hotpluggable on a
real, *physical* system today? Are you saying you can have 1K DIMM slots
on a board?
I hardly
On Sat, Oct 08, 2022 at 10:35:14AM +0800, Baoquan He wrote:
> Memory hptlug is not limited by a certin or a max number of memory
> regions, but limited by how large of the linear mapping range which
> physical can be mapped into.
Memory hotplug is not limited by some abstract range but by the
On Fri, Sep 30, 2022 at 12:11:26PM -0500, Eric DeVolder wrote:
> There is of course a way to enumerate the memory regions in use on the
> machine, that is not what this code needs. In order to compute the maximum
> buffer size needed (this buffer size is computed once), the count of the
> maximum
On Fri, Sep 30, 2022 at 10:36:49AM -0500, Eric DeVolder wrote:
> > Your help text talks about System RAM entries in /proc/iomem which means
> > that those entries are present somewhere in the kernel and you can read
> > them out and do the proper calculations dynamically instead of doing the
> >
On Wed, Sep 28, 2022 at 06:07:24PM +0200, Borislav Petkov wrote:
> #if defined(CONFIG_HOTPLUG_CPU) || defined(CONFIG_MEMORY_HOTPLUG)
> /* Ensure elfcorehdr segment large enough for hotplug changes */
> @@ -407,9 +408,8 @@ int crash_load_segments(struct kimage *image)
>
On Tue, Sep 13, 2022 at 02:12:31PM -0500, Eric DeVolder wrote:
> This topic was discussed previously https://lkml.org/lkml/2022/3/3/372.
Please do not use lkml.org to refer to lkml messages. We have a
perfectly fine archival system at lore.kernel.org. You simply do
https://lore.kernel.org/r/
On Fri, Aug 12, 2022 at 01:14:38PM -0400, Stefan Berger wrote:
> Yes, so this series can be tested by krobot.
You mean Intel's 0day robot?
I believe that thing has by now enough logic to figure out which branch
to base patches ontop. Or maybe there's some magic incantation to tell
it which base
ew kernel.
>
> Signed-off-by: Jonathan McDowell
> Signed-off-by: Borislav Petkov
> Reviewed-by: Mimi Zohar # IMA function definitions
> Link: https://lore.kernel.org/r/YmKyvlF3my1yWTvK@noodles-fedora-PC23Y6EG
Is there any particular reason to keep sending a patch which is
On Wed, Jun 29, 2022 at 09:52:50AM +, Jonathan McDowell wrote:
> Below is on top of what was in tip; I can roll a v7 if preferred but
> I think seeing the fix on its own is clearer.
Yes, and you don't have to base it on top because, as I've said, I've
zapped your other patch there.
Once IMA
On Tue, Apr 19, 2022 at 04:58:47PM -0500, Eric DeVolder wrote:
> So in taking this concept and looking at, in particular, patch 4/8
> "crash: add generic infrastructure for crash hotplug support", I'm not
> exactly sure how to apply this technique.
So I took your patch 4 and maimed into what I
1 - 100 of 601 matches
Mail list logo
