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
On Mon, Apr 18, 2022 at 05:03:39PM -0500, Eric DeVolder wrote:
> I've examined the code with this thought in mind, and I'm not exactly sure how
> this code should be restructured for !HOTPLUG stubs. I'd very much appreciate
> an example in order to facilitate accommodating the request!
For
On Wed, Apr 13, 2022 at 12:42:31PM -0400, Eric DeVolder wrote:
> CRASH_HOTPLUG is to enable cpu and memory hotplug support of crash.
What for?
Why don't you put all that new code you're adding under an
MEMORY_HOTPLUG ifdef? It seems you would need to do that when memory
hotplug is enabled,
On Wed, Apr 13, 2022 at 10:47:49AM +0800, Baoquan He wrote:
> Since it's also MM related, so ping you and x86 maintainers to see who
> can help pick them.
I'd leave that decision to akpm. :-)
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
to see:
https://lore.kernel.org/r/Ycs3kpZD/vpoo...@zn.tnic
yet you still don't get it.
So let me make myself clear: in its current form, this is not really an
improvement so for all x86 changes:
NAKed-by: Borislav Petkov
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about
On Wed, Dec 29, 2021 at 11:04:21PM +0800, Leizhen (ThunderTown) wrote:
> Chen Zhou and I tried to share the code because of a suggestion. After so many
> attempts, it doesn't seem to fit to make generic. Or maybe I haven't figured
> out a good solution yet.
Well, you learned a very important
On Wed, Dec 29, 2021 at 06:38:43PM +0800, Dave Young wrote:
> I appreciate you further explanation below to describe the situation.
> I do not see how can I tell this to *all* submitters,
You don't have to - that was hypothetical. :-)
I'm typing this on a public mailing list with the hope that
On Wed, Dec 29, 2021 at 03:45:12PM +0800, Dave Young wrote:
> BTW, I would suggest to wait for reviewers to response (eg. one week at
> least, or more due to the holidays) before updating another version
>
> Do not worry to miss the 5.17. I would say take it easy if it will
> miss then let's
On Wed, Dec 29, 2021 at 03:27:48PM +0800, Dave Young wrote:
> So I think you can unify the parse_crashkernel* in x86 first with just
> one function. And leave the further improvements to later work. But
> let's see how Boris think about this.
Well, I think this all unnecessary work. Why?
If the
On Tue, Dec 28, 2021 at 09:26:01PM +0800, Zhen Lei wrote:
> Use parse_crashkernel_high_low() to bring the parsing of
> "crashkernel=X,high" and the parsing of "crashkernel=Y,low" together, they
> are strongly dependent, make code logic clear and more readable.
>
On Wed, Dec 22, 2021 at 09:08:05PM +0800, Zhen Lei wrote:
> From: Chen Zhou
>
> We will make the functions reserve_crashkernel() as generic, the
> xen_pv_domain() check in reserve_crashkernel() is relevant only to
> x86,
Why is that so? Is Xen-PV x86-only?
> the same as insert_resource() in
On Wed, Dec 22, 2021 at 09:08:04PM +0800, Zhen Lei wrote:
> From: Chen Zhou
>
> We want to make function reserve_crashkernel[_low](), which is implemented
^^
Please use passive voice in your commit message: no "we" or "I", etc,
and describe your changes in imperative mood.
Also, pls read
On Fri, Dec 17, 2021 at 10:51:04AM +0800, Leizhen (ThunderTown) wrote:
> [KNL, X86-64], This doc is for X86-64, not for X86-32
reserve_crashkernel() runs on both.
> If there is no such restriction, we can make CRASH_ADDR_LOW_MAX equal
> to (1ULL << 32) minus 1 on X86_32.
Again, the 4G limit
On Thu, Dec 16, 2021 at 10:11:15PM +0800, Baoquan He wrote:
> As for the code refactoring, it can be done in another patchset.
Well, I said "future work" before having seen where this patchset is
going. So no, in that case, the usual kernel development process is:
cleanups/fixes first - new
On Thu, Dec 16, 2021 at 09:15:18PM +0800, Leizhen (ThunderTown) wrote:
> I agree with you. This makes the code look clear. I will do it, try to
> post v18 next Monday.
Don't rush it: take your time, do it nice and clean, make sure each
patch does one logical thing only so that there are no bugs
On Thu, Dec 16, 2021 at 08:08:30PM +0800, Leizhen (ThunderTown) wrote:
> If the memory of 'crash_base' is successfully allocated at (1), because the
> last
> parameter CRASH_ADDR_LOW_MAX is the upper bound, so we can sure that
> "crash_base < CRASH_ADDR_LOW_MAX". So that,
On Fri, Dec 10, 2021 at 02:55:28PM +0800, Zhen Lei wrote:
> + * reserve_crashkernel() - reserves memory for crash kernel
> + *
> + * This function reserves memory area given in "crashkernel=" kernel command
> + * line parameter. The memory reserved is used by dump capture kernel when
> + * primary
On Thu, Dec 16, 2021 at 10:46:12AM +0800, Leizhen (ThunderTown) wrote:
> The original value (1ULL << 32) is inaccurate
I keep asking *why*?
> and it enlarged the CRASH_ADDR_LOW upper limit.
$ git grep -E "CRASH_ADDR_LOW\W"
$
I have no clue what you mean here.
> This is because when the memory
On Thu, Dec 16, 2021 at 09:10:40AM +0800, Baoquan He wrote:
> reserve_crashkernel_low() always return 0 on x86_32, so the not equivalent
> transformation for x86_32 doesn't matter, I think.
That is, of course, very obvious... not!
Why is that function parsing crashkernel=XM, and
On Fri, Dec 10, 2021 at 02:55:26PM +0800, Zhen Lei wrote:
> @@ -518,7 +519,7 @@ static void __init reserve_crashkernel(void)
> }
> }
>
> - if (crash_base >= (1ULL << 32) && reserve_crashkernel_low()) {
> + if (crash_base >= CRASH_ADDR_LOW_MAX &&
On Fri, Dec 10, 2021 at 02:55:25PM +0800, Zhen Lei wrote:
> From: Chen Zhou
>
> The lower bounds of crash kernel reservation and crash kernel low
> reservation are different, use the consistent value CRASH_ALIGN.
A big WHY is missing here to explain why the lower bound of the
allocation range
On Tue, Dec 14, 2021 at 05:56:57PM +0800, Baoquan He wrote:
> Ah, OK, I see the new paragraph from you added in below commit.
That is supposed to make it absolutely clear and explicit. There are
other hints as to what a subsequent SOB means in that document already.
Just the next section says:
On Tue, Dec 14, 2021 at 04:54:40PM +0800, Baoquan He wrote:
> If you didn't contribute change, Signed-off-by should be taken off.
The second SOB is correct here. I'll let you figure it out what it
means.
Hint: Documentation/process/submitting-patches.rst
--
Regards/Gruss,
Boris.
> Subject: Re: [PATCH v17 01/10] x86: kdump: replace the hard-coded alignment
> with macro CRASH_ALIGN
>From Documentation/process/maintainer-tip.rst:
"Patch subject
^
The tip tree preferred format for patch subject prefixes is
'subsys/component:', e.g. 'x86/apic:',
On Mon, Dec 13, 2021 at 08:37:48AM -0600, john.p.donne...@oracle.com wrote:
> After 2 years, and 17 versions, can we now get this series promoted into a
> build ?
For example:
$ ./scripts/get_maintainer.pl -f Documentation/admin-guide/kdump/kdump.rst
Baoquan He (maintainer:KDUMP)
Vivek Goyal
On Tue, Dec 07, 2021 at 11:16:31AM +0800, Baoquan He wrote:
> > This low 1M lock down is needed because AMD SME encrypts memory making
> > the old backup region mechanims impossible when switching into kdump
> > kernel. And Intel engineer mentioned their TDX (Trusted domain extensions)
> > which
On Mon, Sep 13, 2021 at 05:56:00PM +0200, Joerg Roedel wrote:
> diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h
> index 134a7c9d91b6..cd14b6e10f12 100644
> --- a/arch/x86/include/asm/sev.h
> +++ b/arch/x86/include/asm/sev.h
> @@ -81,12 +81,19 @@ static __always_inline void
On Mon, Sep 13, 2021 at 05:55:59PM +0200, Joerg Roedel wrote:
> From: Joerg Roedel
>
> GHCB protocol version 2 adds the MSR-based AP-reset-hold VMGEXIT which
> does not need a GHCB. Use that to park APs in 16-bit protected mode on
> the AP Jump Table.
>
> Signed-off-by: Joerg Roedel
> ---
>
1 - 100 of 574 matches
Mail list logo
