have single ABI for MMU and MMU-less systems anyway. And we
can avoid conflict with MAP_HUGE_SHIFT this way.
P.S. MAP_UNINITIALIZED itself looks very broken to me. I probably need dig
mailing list on why it was allowed.
But that's other topic.
--
Kirill A. Shutemov
___
On Mon, Sep 14, 2015 at 10:19:19PM -0700, Josh Triplett wrote:
> On Tue, Sep 15, 2015 at 03:23:58AM +0300, Kirill A. Shutemov wrote:
> > On Mon, Sep 14, 2015 at 03:50:38PM -0700, Palmer Dabbelt wrote:
> > > This used to be hidden behind CONFIG_MMAP_ALLOW_UNINITIALIZED, so
> &
;Part 2" of 5-level paging changes[1] would
help you?
Making the code work with both and
would make it even uglier. Not sure if it
makes sense to address it on its own if second part fixes the situation.
[1]
http://lkml.kernel.org/r/20170317185515.8636-1-kirill.shute...
On Mon, Jan 08, 2018 at 08:46:53PM +0300, Kirill A. Shutemov wrote:
> On Mon, Jan 08, 2018 at 04:04:44PM +, Ingo Molnar wrote:
> >
> > hi Kirill,
> >
> > As Mike reported it below, your 5-level paging related upstream commit
> > 83e3c4
On Wed, Jan 10, 2018 at 03:08:04AM +, Dave Young wrote:
> On Tue, Jan 09, 2018 at 12:05:52PM +0300, Kirill A. Shutemov wrote:
> > On Tue, Jan 09, 2018 at 03:24:40PM +0800, Dave Young wrote:
> > > On 01/09/18 at 01:41pm, Baoquan He wrote:
> > > > On 01/09/1
, either change all array uses or just introduce
> the macro and start to use it from now on if we have similar array
> symbols.
Do you need some action on my side or will you folks take care about this?
--
Kirill A. Shutemov
___
kexec mailin
On Sat, Jan 13, 2018 at 11:48:38AM +0100, Ingo Molnar wrote:
>
> * Kirill A. Shutemov <kirill.shute...@linux.intel.com> wrote:
>
> > Depending on configuration mem_section can now be an array or a pointer
> > to an array allocated dynamically. In most case
ng, if enabled
*/
movl$X86_CR4_PAE, %eax
+#ifdef CONFIG_X86_5LEVEL
+ orl $X86_CR4_LA57, %eax
+#endif
movq %rax, %cr4
jmp 1f
--
Kirill A. Shutemov
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
situation correctly for both cases.
Signed-off-by: Kirill A. Shutemov <kirill.shute...@linux.intel.com>
Fixes: 83e3c48729d9 ("mm/sparsemem: Allocate mem_section at runtime for
CONFIG_SPARSEMEM_EXTREME=y")
Cc: sta...@vger.kernel.org
Acked-by: Baoquan He <b...@redhat.com&g
patch
fixed?
--
Kirill A. Shutemov
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
On Thu, Aug 30, 2018 at 02:12:02PM +, Baoquan He wrote:
> On 08/30/18 at 04:58pm, Kirill A. Shutemov wrote:
> > On Wed, Aug 29, 2018 at 10:16:21PM +0800, Baoquan He wrote:
> > > This was suggested by Kirill several months ago, I worked out several
> > > patch
ot entirely sure that 64TiB is the limit here. Technically, 4-level
paging allows to address 256TiB in 1-to-1 mapping. We just don't have
machines with that wide physical address space (which don't support
5-level paging too).
What is your reasoning about 64TiB limit?
--
Kirill A. Shutemov
reservation is done during the 1st kernel bootup, there's
> no way to detect the paging mode of kdump kernel at that time.
>
> Hence change the upper limmit of crashkernel reservation to 64TB
s/limmit/limit/
--
Kirill A. Shutemov
___
kex
On Thu, Aug 30, 2018 at 10:57:51PM +0800, Baoquan He wrote:
> On 08/30/18 at 05:27pm, Kirill A. Shutemov wrote:
> > On Thu, Aug 30, 2018 at 02:12:02PM +, Baoquan He wrote:
> > > On 08/30/18 at 04:58pm, Kirill A. Shutemov wrote:
> > > > On Wed, Aug 29, 2018 at 10:1
mpression code, but not on
kexec caller side.
XLF_5LEVEL indicates that kernel decompression code can deal with
switching between paging modes and it's safe to jump there in 5-level
paging mode.
As an alternative we can change kexec to switch to 4-level paging mode
before starting the new kernel. Not sure how hard it will be.
--
Kirill A. Shutemov
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
t; So resend this patchset.
Changes look good to me:
Acked-by: Kirill A. Shutemov
--
Kirill A. Shutemov
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
On Wed, Aug 11, 2021 at 10:52:55AM -0500, Tom Lendacky wrote:
> On 8/11/21 7:19 AM, Kirill A. Shutemov wrote:
> > On Tue, Aug 10, 2021 at 02:48:54PM -0500, Tom Lendacky wrote:
> >> On 8/10/21 1:45 PM, Kuppuswamy, Sathyanarayanan wrote:
> >>>
> >>>
&g
ared/unencrypted
> area, though? Or since it is shared, there's actually nothing you need to
> do (the bss decrpyted section exists even if CONFIG_AMD_MEM_ENCRYPT is not
> configured)?
AFAICS, only kvmclock uses __bss_decrypted. We don't enable kvmclock in
TDX at the moment. It may change in the future.
--
Kirill A. Shutemov
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
On Tue, Sep 21, 2021 at 11:27:17PM +0200, Borislav Petkov wrote:
> On Wed, Sep 22, 2021 at 12:20:59AM +0300, Kirill A. Shutemov wrote:
> > I still believe calling cc_platform_has() from __startup_64() is totally
> > broken as it lacks proper wrapping while accessing global varia
rypt_identity.c
@@ -288,7 +288,7 @@ void __init sme_encrypt_kernel(struct boot_params *bp)
unsigned long pgtable_area_len;
unsigned long decrypted_base;
- if (!cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT))
+ if (1 || !cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT))
On Tue, Sep 21, 2021 at 04:43:59PM -0500, Tom Lendacky wrote:
> On 9/21/21 4:34 PM, Kirill A. Shutemov wrote:
> > On Tue, Sep 21, 2021 at 11:27:17PM +0200, Borislav Petkov wrote:
> > > On Wed, Sep 22, 2021 at 12:20:59AM +0300, Kirill A. Shutemov wrote:
> > >
have a special version of
the helper). Note that only AMD requires these cc_platform_has() to return
true.
--
Kirill A. Shutemov
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
On Wed, Sep 22, 2021 at 08:40:43AM -0500, Tom Lendacky wrote:
> On 9/21/21 4:58 PM, Kirill A. Shutemov wrote:
> > On Tue, Sep 21, 2021 at 04:43:59PM -0500, Tom Lendacky wrote:
> > > On 9/21/21 4:34 PM, Kirill A. Shutemov wrote:
> > > > On Tue, Sep 21, 2021 at 11:
On Wed, Sep 22, 2021 at 09:52:07PM +0200, Borislav Petkov wrote:
> On Wed, Sep 22, 2021 at 05:30:15PM +0300, Kirill A. Shutemov wrote:
> > Not fine, but waiting to blowup with random build environment change.
>
> Why is it not fine?
>
> Are you suspecting that the co
On Thu, Sep 23, 2021 at 08:21:03PM +0200, Borislav Petkov wrote:
> On Thu, Sep 23, 2021 at 12:05:58AM +0300, Kirill A. Shutemov wrote:
> > Unless we find other way to guarantee RIP-relative access, we must use
> > fixup_pointer() to access any global variables.
>
> Yah, I've
at
this point.
--
Kiryl Shutsemau / Kirill A. Shutemov
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
gt;
> Plug a few gaps where RAM is exposed without checking if it is
> unaccepted memory.
Thanks for catching this. Looks good to me.
Reviewed-by: Kirill A. Shutemov
--
Kiryl Shutsemau / Kirill A. Shutemov
___
kexec mailing l
On Mon, Sep 11, 2023 at 11:50:31AM +0200, David Hildenbrand wrote:
> On 11.09.23 11:27, Kirill A. Shutemov wrote:
> > On Mon, Sep 11, 2023 at 10:42:51AM +0200, David Hildenbrand wrote:
> > > On 11.09.23 10:41, Kirill A. Shutemov wrote:
> > > > On Mon, Sep 11, 2
On Mon, Sep 11, 2023 at 10:42:51AM +0200, David Hildenbrand wrote:
> On 11.09.23 10:41, Kirill A. Shutemov wrote:
> > On Mon, Sep 11, 2023 at 10:03:36AM +0200, David Hildenbrand wrote:
> > > On 06.09.23 09:39, Adrian Hunter wrote:
> > > > Support for unaccepted me
e, but generally,
yes, the information is available to the target kernel via EFI
configuration table.
--
Kiryl Shutsemau / Kirill A. Shutemov
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
am not sure I
saw all users. Some of them could silently handled with pagefault handler
in some setups. And it is hard to catch new users during code review.
Also I'm not sure why do we need pagefault handler there. Looks like it
just masking problems. I think everything has to be mapped e
On Mon, Sep 11, 2023 at 10:33:01AM -0500, Tom Lendacky wrote:
> On 9/11/23 09:57, Kirill A. Shutemov wrote:
> > On Mon, Sep 11, 2023 at 10:56:36PM +0800, Dave Young wrote:
> > > > early console in extract_kernel
> > > > input_data: 0x00807eb433a8
>
On Mon, Sep 11, 2023 at 05:57:07PM +0300, Kirill A. Shutemov wrote:
> On Mon, Sep 11, 2023 at 10:56:36PM +0800, Dave Young wrote:
> > > early console in extract_kernel
> > > input_data: 0x00807eb433a8
> > > input_len: 0x00d26271
> > > outp
this really worth patching?
Is it better to let TD die silently? I don't think so.
--
Kiryl Shutsemau / Kirill A. Shutemov
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
configurations.
Signed-off-by: Kirill A. Shutemov
Reported-by: Aaron Lu
Fixes: 34bbb0009f3b ("x86/boot/compressed: Enable 5-level paging during
decompression stage")
---
arch/x86/include/asm/boot.h | 27 ---
1 file changed, 12 insertions(+), 15 deletions(-)
On Thu, Sep 14, 2023 at 08:51:50AM -0700, Dave Hansen wrote:
> On 9/14/23 05:30, Kirill A. Shutemov wrote:
> > +/*
> > + * Total number of page table kernel_add_identity_map() can allocate,
> > + * including page tables consumed by startup_32().
> > + */
> > +# def
can be simplified
by using a single value for all kernel configurations.
Signed-off-by: Kirill A. Shutemov
Reported-by: Aaron Lu
Fixes: 34bbb0009f3b ("x86/boot/compressed: Enable 5-level paging during
decompression stage")
---
arch/x86/boot/compressed/ident_map_64.c | 8 +
arch/x
On Tue, Oct 24, 2023 at 06:59:58AM -0700, Kuppuswamy Sathyanarayanan wrote:
>
>
> On 10/20/2023 8:12 AM, Kirill A. Shutemov wrote:
> > ACPI MADT doesn't allow to offline CPU after it got woke up. It limits
> > kexec: the second kernel won't be able to use more than
On Sun, Oct 29, 2023 at 06:31:36PM +0100, Thomas Gleixner wrote:
> On Fri, Oct 20 2023 at 18:12, 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
On Sat, Oct 28, 2023 at 04:12:10PM +0200, Thomas Gleixner wrote:
> On Fri, Oct 20 2023 at 18:12, Kirill A. Shutemov wrote:
>
> Subject: cpu/hotplug: ...
>
> > ACPI MADT doesn't allow to offline CPU after it got woke up.
>
> ACPI MADT is a table ...
>
> This is
On Thu, Sep 21, 2023 at 11:54:15AM +0200, Linux regression tracking (Thorsten
Leemhuis) wrote:
> On 13.09.23 16:24, Kirill A. Shutemov wrote:
> > On Mon, Sep 11, 2023 at 05:57:07PM +0300, Kirill A. Shutemov wrote:
> >> On Mon, Sep 11, 2023 at 10:56:36PM +0800, Dave Young w
On Mon, Oct 09, 2023 at 07:49:35AM +0800, Baoquan He wrote:
> On 10/05/23 at 04:13pm, Kirill A. Shutemov wrote:
> > The patchset adds bits and pieces to get kexec (and crashkernel) work on
> > TDX guest.
> >
> > They bring kexec support to the point when
On Fri, Oct 06, 2023 at 11:33:47AM -0700, Kuppuswamy Sathyanarayanan wrote:
> Hi Kirill,
>
> On 10/5/2023 6:13 AM, Kirill A. Shutemov wrote:
> > In order to prepare for the expansion of support for the ACPI MADT
> > wakeup method, the relevant code has been moved into a sep
On Sun, Oct 08, 2023 at 04:35:27PM +0800, Baoquan He wrote:
> On 10/05/23 at 04:13pm, 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
On Fri, Oct 06, 2023 at 07:58:03AM -0700, Sean Christopherson wrote:
> On Thu, Oct 05, 2023, Kirill A. Shutemov wrote:
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index 7368d254d01f..b5acf9fb4c70 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/K
TDX guests are not allowed to clear CR4.MCE. Attempt to clear it leads
to #VE.
Use alternatives to keep the flag during kexec for TDX guests.
The change doesn't affect non-TDX environments.
Signed-off-by: Kirill A. Shutemov
---
arch/x86/kernel/relocate_kernel_64.S | 5 +
1 file changed, 5
private mapping is fatal. It leads to
unrecoverable TD exit.
On TD shutdown (also covers kexec), walk direct mapping and convert all
shared memory back to private. It makes all RAM private again and target
kernel may use it normally.
Signed-off-by: Kirill A. Shutemov
---
arch/x86/Kconfig
it.
Keep track of the number of shared pages. This will allow for
cross-checking against the shared information in the direct mapping and
reporting if the shared bit is lost.
Include a debugfs interface that allows for the check to be performed at
any point.
Signed-off-by: Kirill A. Shutemov
---
arch
numeration.
Signed-off-by: Kirill A. Shutemov
---
arch/x86/coco/core.c | 1 -
arch/x86/kernel/acpi/madt_wakeup.c | 4
include/linux/cc_platform.h| 10 --
kernel/cpu.c | 2 +-
4 files changed, 5 insertions(+), 12 deletions(-)
diff --git a/arc
spec.
Booting the target kernel with signle CPU is enough to cover the most
common case for kexec -- kdump.
Signed-off-by: Kirill A. Shutemov
---
arch/x86/kernel/acpi/madt_wakeup.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/x86/kernel/acpi/madt_wakeup.c
b/arch/x86
guest. TDX
guest uses E820_TYPE_ACPI to store the unaccepted memory bitmap and pass
it between the kernels on kexec.
Signed-off-by: Kirill A. Shutemov
---
arch/x86/kernel/e820.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820
The function cpu_hotplug_not_supported() can be called to indicate that
CPU hotplug should be disabled. It does not prevent the initial bring up
of the CPU, but it stops subsequent offlining.
This function is intended to replace CC_ATTR_HOTPLUG_DISABLED.
Signed-off-by: Kirill A. Shutemov
offlining according to the approved ACPI
spec change poposal[1]. It unlocks kexec with all CPUs visible in the target
kernel.
Please review. I would be glad for any feedback.
[1] https://lore.kernel.org/all/13356251.uLZWGnKmhe@kreacher
Kirill A. Shutemov (13):
x86/acpi: Extract ACPI MADT wakeup
.
Signed-off-by: Kirill A. Shutemov
---
arch/x86/include/asm/reboot.h | 4 ++--
arch/x86/kernel/reboot.c | 4 ++--
arch/x86/kvm/Kconfig | 5 +
3 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/reboot.h b/arch/x86/include/asm/reboot.h
index
by implementing
custom cpu_die, play_dead and stop_other_cpus SMP operations.
CPU offlining makes possible to hand over secondary CPUs over kexec, not
limiting the target kernel with single CPU.
The change conforms to the approved ACPI spec change proposal. See the
Link.
Signed-off-by: Kirill
: 0x8110687c (kvmclock_disable+0x1c/0x30)
kvmclock enabling is gated by CLOCKSOURCE and CLOCKSOURCE2 KVM paravirt
features.
Do not disable kvmclock if it was not enumerated or disabled by user
from kernel command line.
Signed-off-by: Kirill A. Shutemov
Fixes: c02027b5742b ("x86/kvm: Disable kvm
by
one PGD entry in 5-level paging mode.
Signed-off-by: Kirill A. Shutemov
Reviewed-by: Rick Edgecombe
---
arch/x86/include/asm/pgtable_types.h | 1 +
arch/x86/mm/pat/set_memory.c | 8
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm
-by: Kirill A. Shutemov
---
arch/x86/Kconfig | 7 +++
arch/x86/include/asm/acpi.h| 5 ++
arch/x86/kernel/acpi/Makefile | 11 ++--
arch/x86/kernel/acpi/boot.c| 86 +-
arch/x86/kernel/acpi/madt_wakeup.c | 80
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.
Signed-off-by: Kirill A. Shutemov
---
arch/x86/coco/tdx/tdx.c | 20
Bypass unmapping for crash scenario. Unmapping
> > +* requires sleepable context, but in crash case kernel
> > +* hits the code path with interrupts disabled.
>
> In case of SNP we will need to temporarily enable interrupts during this
>
On Thu, Oct 05, 2023 at 05:01:23PM -0500, Kalra, Ashish wrote:
> On 10/5/2023 4:28 PM, Kirill A. Shutemov wrote:
> > On Thu, Oct 05, 2023 at 01:41:38PM -0500, Kalra, Ashish wrote:
> > > > +static void unshare_all_memory(bool unmap)
> > > > +{
> &
On Fri, Oct 20, 2023 at 12:21:11PM +0300, Kirill A. Shutemov wrote:
> On Fri, Oct 06, 2023 at 02:24:11PM -0500, Kalra, Ashish wrote:
> >
> > On 10/5/2023 5:28 PM, Kirill A. Shutemov wrote:
> > > On Thu, Oct 05, 2023 at 05:01:23PM -0500, Kalra, Ashish wrote:
> > &g
On Fri, Oct 06, 2023 at 02:24:11PM -0500, Kalra, Ashish wrote:
>
> On 10/5/2023 5:28 PM, Kirill A. Shutemov wrote:
> > On Thu, Oct 05, 2023 at 05:01:23PM -0500, Kalra, Ashish wrote:
> > > On 10/5/2023 4:28 PM, Kirill A. Shutemov wrote:
> > > > On Thu, Oct 05
confusion.
Signed-off-by: Kirill A. Shutemov
---
arch/x86/kernel/acpi/madt_wakeup.c | 4 ++--
include/acpi/actbl2.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/acpi/madt_wakeup.c
b/arch/x86/kernel/acpi/madt_wakeup.c
index 9bbe829737e7
-off-by: Kirill A. Shutemov
Link: https://lore.kernel.org/all/13356251.uLZWGnKmhe@kreacher
---
arch/x86/kernel/acpi/Makefile | 2 +-
arch/x86/kernel/acpi/boot.c| 2 +
arch/x86/kernel/acpi/madt.S| 24
arch/x86/kernel/acpi/madt_wakeup.c | 197
by
one PGD entry in 5-level paging mode.
Signed-off-by: Kirill A. Shutemov
Reviewed-by: Rick Edgecombe
---
arch/x86/include/asm/pgtable_types.h | 1 +
arch/x86/mm/pat/set_memory.c | 8
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm
guest. TDX
guest uses E820_TYPE_ACPI to store the unaccepted memory bitmap and pass
it between the kernels on kexec.
Signed-off-by: Kirill A. Shutemov
---
arch/x86/kernel/e820.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820
private mapping is fatal. It leads to
unrecoverable TD exit.
On kexec walk direct mapping and convert all shared memory back to
private. It makes all RAM private again and second kernel may use it
normally.
Signed-off-by: Kirill A. Shutemov
---
arch/x86/coco/tdx/kexec.c | 0
arch/x86
to indicate
that CPU offlining should be disabled.
This function is going to replace CC_ATTR_HOTPLUG_DISABLED for ACPI
MADT.
Signed-off-by: Kirill A. Shutemov
---
include/linux/cpu.h | 2 ++
kernel/cpu.c| 13 -
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git
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.
There have been no functional changes.
Signed-off-by: Kirill
kernel with signle CPU is enough to cover the most
common case for kexec -- kdump.
Signed-off-by: Kirill A. Shutemov
---
arch/x86/kernel/acpi/madt_wakeup.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/x86/kernel/acpi/madt_wakeup.c
b/arch/x86/kernel/acpi
TDX guests are not allowed to clear CR4.MCE. Attempt to clear it leads
to #VE.
Use alternatives to keep the flag during kexec for TDX guests.
The change doesn't affect non-TDX-guest environments.
Signed-off-by: Kirill A. Shutemov
Reviewed-by: Kai Huang
---
arch/x86/kernel/relocate_kernel_64
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.
Signed-off-by: Kirill A. Shutemov
---
arch/x86/coco/tdx/tdx.c | 20
() to implement acpi_mp_play_dead();
- cond_resched() in tdx_shared_memory_show();
- s/target kernel/second kernel/;
- Update commit messages and comments;
[1] https://lore.kernel.org/all/13356251.uLZWGnKmhe@kreacher
Kirill A. Shutemov (13):
x86/acpi: Extract ACPI MADT wakeup code into a separate
it.
Keep track of the number of shared pages. This will allow for
cross-checking against the shared information in the direct mapping and
reporting if the shared bit is lost.
Include a debugfs interface that allows for the check to be performed at
any point.
Signed-off-by: Kirill A. Shutemov
---
arch
-by: Kirill A. Shutemov
---
arch/x86/coco/core.c | 1 -
arch/x86/kernel/acpi/madt_wakeup.c | 3 +++
include/linux/cc_platform.h| 10 --
kernel/cpu.c | 3 +--
4 files changed, 4 insertions(+), 13 deletions(-)
diff --git a/arch/x86/coco/core.c b/arch
: 0x8110687c (kvmclock_disable+0x1c/0x30)
kvmclock enabling is gated by CLOCKSOURCE and CLOCKSOURCE2 KVM paravirt
features.
Do not disable kvmclock if it was not enabled.
Signed-off-by: Kirill A. Shutemov
Fixes: c02027b5742b ("x86/kvm: Disable kvmclock on all CPUs on shutdown")
Cc: Paolo B
On Tue, Oct 10, 2023 at 06:35:59AM -0700, Kuppuswamy Sathyanarayanan wrote:
>
>
> On 10/5/2023 6:13 AM, Kirill A. Shutemov wrote:
> > The function cpu_hotplug_not_supported() can be called to indicate that
> > CPU hotplug should be disabled. It does not prevent
On Tue, Oct 10, 2023 at 06:53:27AM -0700, Kuppuswamy Sathyanarayanan wrote:
>
>
> On 10/5/2023 6:13 AM, Kirill A. Shutemov wrote:
> > kvm_guest_cpu_offline() tries to disable kvmclock regardless if it is
> > present in the VM. It leads to write to a MSR that
On Fri, Oct 06, 2023 at 07:36:54AM -0700, Sean Christopherson wrote:
> +Paolo
>
> Please use get_maintainers...
Will do, sorry.
> On Thu, Oct 05, 2023, Kirill A. Shutemov wrote:
> > kvm_guest_cpu_offline() tries to disable kvmclock regardless if it is
> > present in t
On Fri, Jun 24, 2022 at 05:00:05AM +0300, Kirill A. Shutemov wrote:
> > If there is some deep and fundamental why this can not be supported
> > then it probably makes sense to put some code in the arch_kexec_load
> > hook that verifies that deep and fundamental reason is pr
On Tue, Jun 28, 2022 at 05:10:56PM -0700, Dave Hansen wrote:
> On 6/28/22 16:51, Kirill A. Shutemov wrote:
> > On Fri, Jun 24, 2022 at 05:00:05AM +0300, Kirill A. Shutemov wrote:
> >>> If there is some deep and fundamental why this can not be supported
> >>> th
On Thu, Jun 23, 2022 at 04:48:59PM -0500, Eric W. Biederman wrote:
> Dave Hansen writes:
>
> > ... adding kexec folks
> >
> > On 6/14/22 05:02, Kirill A. Shutemov wrote:
> >> On kexec, the target kernel has to know what memory has been accepted.
> >
On Sat, Mar 25, 2023 at 09:25:36AM -0700, Dave Hansen wrote:
> On 3/25/23 09:01, Kirill A. Shutemov wrote:
> > The last item is tricky. TDX guests use ACPI MADT MPWK to bring up
> > secondary CPUs. The mechanism doesn't allow to put a CPU back offline if
> > it has wok
-kirill.shute...@linux.intel.com
Signed-off-by: Kirill A. Shutemov
---
arch/x86/include/asm/kexec.h | 3 +++
arch/x86/kernel/machine_kexec_64.c | 10 ++
include/linux/kexec.h | 7 +++
kernel/kexec.c | 4
kernel/kexec_file.c| 4
On Thu, Feb 16, 2023 at 01:49:39AM +, Edgecombe, Rick P wrote:
> On Tue, 2023-02-14 at 02:48 +0300, Kirill A. Shutemov wrote:
> > TDX guests are not allowed to clear CR4.MCE. Attempt to clear it
> > leads
> > to #VE.
> >
> > Preserve the flag during kexe
On Thu, Feb 16, 2023 at 09:50:32AM -0800, Dave Hansen wrote:
> On 2/13/23 15:48, Kirill A. Shutemov wrote:
> > The patch brings basic enabling of kexec in TDX guests.
> >
> > By "basic enabling" I mean, kexec in the guests with a single CPU.
> > TDX guests use
On Wed, Feb 22, 2023 at 10:26:22AM +, David Woodhouse wrote:
> On Tue, 2023-02-14 at 02:48 +0300, Kirill A. Shutemov wrote:
> > The patch brings basic enabling of kexec in TDX guests.
> >
> > By "basic enabling" I mean, kexec in the guests with a single CPU.
&g
On Fri, Feb 24, 2023 at 07:22:18AM -0800, Dave Hansen wrote:
> On 2/24/23 06:30, Kirill A. Shutemov wrote:
> > Ideally, it has to be addressed on BIOS level: it has to provide a way to
> > offline CPUs, putting it back to pre-wakeup state.
>
> Is there anything stopping
On Mon, Mar 27, 2023 at 09:35:54AM +0800, Baoquan He wrote:
> On 03/26/23 at 10:01am, Dave Hansen wrote:
> > On 3/25/23 12:25, Kirill A. Shutemov wrote:
> > > On Sat, Mar 25, 2023 at 09:25:36AM -0700, Dave Hansen wrote:
> > >> On 3/25/23 09:01, Kirill A. Shutemo
IDT/TSS
and/or not having a safe stack to service the event.
I tend to agree with him, but maybe I miss bigger picture.
Based on that I adjusted the patch to only affect TDX guests:
>From edbef5f1e6c31929ae1249c58b29c38f86e676c0 Mon Sep 17 00:00:00 2001
From: "Kirill A. Shutemov&q
TDX guests are not allowed to clear CR4.MCE. Attempt to clear it leads
to #VE.
Preserve the flag during kexec.
Signed-off-by: Kirill A. Shutemov
---
arch/x86/kernel/relocate_kernel_64.S | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/relocate_kernel_64
t it might take time.
Kirill A. Shutemov (2):
x86/kexec: Preserve CR4.MCE during kexec
x86/tdx: Convert shared memory back to private on kexec
arch/x86/coco/tdx/Makefile | 1 +
arch/x86/coco/tdx/kexec.c| 82
arch/x86/include/asm/tdx.h
allocate from the memory the first kernel made
shared.
For crash investigation, it might be useful to access data in the shared
buffers.
Signed-off-by: Kirill A. Shutemov
---
arch/x86/coco/tdx/Makefile | 1 +
arch/x86/coco/tdx/kexec.c | 82 ++
arch/x86
> + E820_TYPE_ACPI))
> set_pmd_init(pmd, __pmd(0), init);
> continue;
Why do you single out phys_pmd_init()? I think it has to be addressed for
all page table levels as we do for E820_TYPE_RAM and E820_TYPE_RESERVED_KERN.
--
pud and pmd either when the entry is marked
+ * large or when the present bit is not set. Otherwise it returns NULL.
*/
pte_t *lookup_address(unsigned long address, unsigned int *level)
{
--
Kiryl Shutsemau / Kirill A. Shutemov
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
> > *
> > - * Note: We return pud and pmd either when the entry is marked large
> > - * or when the present bit is not set. Otherwise we would return a
> > - * pointer to a nonexisting mapping.
> > + * Note: the function returns p4d, pud and pmd either when the entry
viewed-by: Baoquan He
Thanks!
>From 23b7f9856a3d6b91c702def1e03872a60ae07d0e Mon Sep 17 00:00:00 2001
From: "Kirill A. Shutemov"
Date: Mon, 19 Feb 2024 11:58:19 +0200
Subject: [PATCH] ACPI: tables: Print MULTIPROC_WAKEUP when MADT is parse
When MADT is parsed, print MULTIPROC_WAKEU
On Mon, Feb 19, 2024 at 01:12:32PM +0800, Baoquan He wrote:
> On 02/12/24 at 12:44pm, Kirill A. Shutemov wrote:
> > lookup_address() only returns correct page table level for the entry if
> > the entry is not none.
> >
> > Make the helper to always return correct 'lev
ve addressed all your feedback, but this gave me pause. Looks like none
of kernel_ident_mapping_init() users frees memory on failure.
Is it okay to get this part as is and I will follow up with patchset that
fixes memory handling for all kernel_ident_mapping_init() users?
--
Kiryl Shutsemau
1 - 100 of 224 matches
Mail list logo
