On Mon, 2023-10-23 at 18:31 +0300, kirill.shute...@linux.intel.com wrote:
> On Mon, Oct 23, 2023 at 09:30:59AM +0000, Huang, Kai wrote:
> > IMHO it's a little bit odd to have two mechanisms in place, even in this
> > middle
> > state patch. Is it better
> > + .text
> > + .align PAGE_SIZE
> > +SYM_FUNC_START(asm_acpi_mp_play_dead)
> > + /* Load address of reset vector into RCX to jump when kernel is ready */
> > + movqacpi_mp_reset_vector_paddr(%rip), %rcx
> > +
> > + /* Turn off global entries. Following CR3 write will flush them.
> /* Physical address of the Multiprocessor Wakeup Structure mailbox */
> @@ -74,6 +75,9 @@ int __init acpi_parse_mp_wake(union acpi_subtable_headers
> *header,
>
> acpi_mp_wake_mailbox_paddr = mp_wake->base_address;
>
> + /* Disable CPU onlining/offlining */
> +
On Thu, 2023-10-05 at 16:13 +0300, Kirill A. Shutemov wrote:
> 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.
Nit: non-TDX-guest environments.
> +#ifdef CONFIG_DEBUG_FS
> +static int tdx_shared_memory_show(struct seq_file *m, void *p)
> +{
> + unsigned long addr, end;
> + unsigned long found = 0;
> +
> + addr = PAGE_OFFSET;
> + end = PAGE_OFFSET + get_max_mapped();
> +
> + while (addr < end) {
> +
On Thu, 2023-10-05 at 16:14 +0300, Kirill A. Shutemov wrote:
> struct acpi_madt_multiproc_wakeup {
> struct acpi_subtable_header header;
> - u16 mailbox_version;
> + u16 version;
> u32 reserved; /* reserved - must be zero */
> - u64 base_address;
> + u64
> --- /dev/null
> +++ b/arch/x86/kernel/acpi/madt.S
> @@ -0,0 +1,28 @@
> +#include
> +#include
> +#include
> +#include
> +
> + .text
> + .align PAGE_SIZE
> +SYM_FUNC_START(asm_acpi_mp_play_dead)
> + /* Load address of reset vector into RCX to jump when kernel is ready */
> +
On Tue, 2023-10-10 at 10:24 +, Huang, Kai wrote:
> > /* Physical address of the Multiprocessor Wakeup Structure mailbox */
> > @@ -74,6 +75,9 @@ int __init acpi_parse_mp_wake(union acpi_subtable_headers
> > *header,
> >
> >
> > acpi_mp_wake_m
On Thu, 2023-10-05 at 16:14 +0300, Kirill A. Shutemov wrote:
> ACPI MADT doesn't allow to offline CPU after it got woke up. It limits
> kexec: target kernel won't be able to use more than one CPU.
>
> Zero out mailbox address in the ACPI MADT wakeup structure to indicate
> that the mailbox is not
On Fri, 2023-10-20 at 18:12 +0300, Kirill A. Shutemov wrote:
> ACPI MADT doesn't allow to offline CPU after it got woke up.
>
> Currently offlining hotplug 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
On Thu, 2023-10-05 at 16:13 +0300, 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 separate file.
> A new configuration option has been introduced to clearly indicate
> dependencies without the
On Fri, 2023-10-20 at 18:12 +0300, 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 one CPU.
>
> Now acpi_mp_wake_mailbox_paddr already has the mailbox address.
> The acpi_wakeup_cpu() will
On Fri, 2023-10-20 at 18:12 +0300, 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
> --- /dev/null
> +++ b/arch/x86/kernel/acpi/madt.S
I think the name 'madt.S' is too generic. How about something be more specific
such as madt_reset.S, or madt_playdead.S, etc?
> @@ -0,0 +1,24 @@
> +#include
> +#include
> +#include
> +#include
> +
> + .text
> + .align PAGE_SIZE
>
> +void tdx_kexec_prepare(bool crash)
> +{
> + /*
> + * Crash kernel may want to see data in the shared buffers.
> + * Do not revert them to private on kexec of crash kernel.
> + */
> + if (crash)
> + return;
> +
> + /*
> + * Walk direct mapping and
On Fri, 2023-12-22 at 14:19 +0300, kirill.shute...@linux.intel.com wrote:
> On Tue, Dec 05, 2023 at 11:36:55PM +0000, Huang, Kai wrote:
> >
> > > +
> > > +static void acpi_mp_stop_other_cpus(int wait)
> > > +{
> > >
> > > @@ -835,6 +835,13 @@ void __noreturn stop_this_cpu(void *dummy)
> > >*/
> > > cpumask_clear_cpu(cpu, _stop_mask);
> > >
> > > +#ifdef CONFIG_SMP
> > > + if (smp_ops.stop_this_cpu) {
> > > + smp_ops.stop_this_cpu();
> > > + unreachable();
> > > + }
> > > +#endif
> >
On Mon, 2023-12-25 at 11:05 +0300, 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, 2024-01-08 at 03:13 +, Huang, Kai wrote:
> On Sat, 2023-12-23 at 02:52 +0300, Kirill A. Shutemov wrote:
> > The helper complements kernel_ident_mapping_init(): it frees the
> > identity mapping that was previously allocated. It will be used in the
> > error pat
On Sat, 2023-12-23 at 02:52 +0300, Kirill A. Shutemov wrote:
> The helper complements kernel_ident_mapping_init(): it frees the
> identity mapping that was previously allocated. It will be used in the
> error path to free a partially allocated mapping or if the mapping is no
> longer needed.
>
>
On Mon, 2024-01-08 at 13:17 +0300, kirill.shute...@linux.intel.com wrote:
> On Mon, Jan 08, 2024 at 03:30:21AM +0000, Huang, Kai wrote:
> > On Mon, 2024-01-08 at 03:13 +0000, Huang, Kai wrote:
> > > On Sat, 2023-12-23 at 02:52 +0300, Kirill A. Shutemov wrote:
> > &g
> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> index 171d86fe71ef..602b5d3982ff 100644
> --- a/arch/x86/kernel/acpi/boot.c
> +++ b/arch/x86/kernel/acpi/boot.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@
> +
> +static void acpi_mp_stop_other_cpus(int wait)
> +{
> + smp_shutdown_nonboot_cpus(smp_processor_id());
> +}
Is this and ...
+ smp_ops.stop_other_cpus = acpi_mp_stop_other_cpus;
... this below still needed?
I think the current native_stop_other_cpus() should just work given
On Tue, 2023-12-05 at 03:45 +0300, Kirill A. Shutemov wrote:
> 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
On Tue, 2023-11-21 at 12:58 +0300, kirill.shute...@linux.intel.com wrote:
> On Tue, Nov 21, 2023 at 03:46:41AM +0000, Huang, Kai wrote:
> >
> > >
> > > +static atomic_t conversions_in_progress;
> > > +static bool conversion_allowed = true;
> > &
>
> > > +
> > > int __init acpi_parse_mp_wake(union acpi_subtable_headers *header,
> > > const unsigned long end)
> > > {
> > > struct acpi_madt_multiproc_wakeup *mp_wake;
> > >
> > > mp_wake = (struct acpi_madt_multiproc_wakeup *)header;
> > > - if
> > Runtime disabling kexec looks better than at cmpile time, esp for
> > distros. While from above patch, making using of kexec_load_disabled
> > to achive the runtime disabling may not be so good. Because we have a
> > front door to enable it through:
> >
> > /proc/sys/kernel/kexec_load_disabled
On Wed, 2024-01-24 at 14:55 +0200, 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 Wed, 2024-01-24 at 14:55 +0200, Kirill A. Shutemov wrote:
> The helper complements kernel_ident_mapping_init(): it frees the
> identity mapping that was previously allocated. It will be used in the
> error path to free a partially allocated mapping or if the mapping is no
> longer needed.
>
>
On Wed, 2024-01-24 at 14:55 +0200, 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
> Hi Kirill,
>
> I have a very basic question: is there a reason why this series does not
> revert
> commit cb8eb06d50fc, "x86/virt/tdx: Disable TDX host support when kexec is
> enabled"?
>
Hi Paolo,
(Sorry I am replying using Outlook)
This series is for TDX guest, but not TDX host.
For TDX
On Wed, 2023-11-15 at 15:00 +0300, Kirill A. Shutemov wrote:
> The ACPI MADT mailbox wakeup method doesn't allow to offline CPU after
> it got woke up.
>
> Currently offlining hotplug is prevented based on the confidential
> computing attribute which is set for Intel TDX. But TDX is not
> the
>
> +static atomic_t conversions_in_progress;
> +static bool conversion_allowed = true;
>
[...]
> /* Used while preparing memory map entries for second kernel */
> struct crash_memmap_data {
> @@ -107,6 +108,9 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
>
>
> +static atomic_long_t nr_shared;
> +
> +static inline bool pte_decrypted(pte_t pte)
> +{
> + return cc_mkdec(pte_val(pte)) == pte_val(pte);
> +}
> +
> /* Called from __tdx_hypercall() for unrecoverable failure */
> noinstr void __noreturn __tdx_hypercall_failed(void)
> {
> @@ -820,6
On Wed, 2023-11-15 at 15:00 +0300, 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
> ---
> arch/x86/kernel/acpi/madt_wakeup.c | 4 ++--
> 1 file changed, 2
On Wed, 2023-11-15 at 15:00 +0300, 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 29/02/2024 4:22 am, Kirill A. Shutemov wrote:
On Wed, Feb 28, 2024 at 11:08:38AM +1300, Huang, Kai wrote:
On 28/02/2024 10:24 am, Kirill A. Shutemov wrote:
When MADT is parsed, print MULTIPROC_WAKEUP information:
ACPI: MP Wakeup (version[1], mailbox[0x7fffd000], reset[0x7fffe068
On 28/02/2024 10:24 am, Kirill A. Shutemov wrote:
When MADT is parsed, print MULTIPROC_WAKEUP information:
ACPI: MP Wakeup (version[1], mailbox[0x7fffd000], reset[0x7fffe068])
This debug information will be very helpful during bring up.
Signed-off-by: Kirill A. Shutemov
Reviewed-by:
On 28/02/2024 10:24 am, 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.
Signed-off-by: Kirill A.
+/* Stop new private<->shared conversions */
+static void tdx_kexec_stop_conversion(bool crash)
+{
+ /*
+* Crash kernel reaches here with interrupts disabled: can't wait for
+* conversions to finish.
+*
+* If race happened, just report and proceed.
+
On 28/02/2024 10:24 am, Kirill A. Shutemov wrote:
AMD SEV and Intel TDX guests allocate shared buffers for performing I/O.
This is done by allocating pages normally from the buddy allocator and
then converting them to shared using set_memory_decrypted().
On kexec, the second kernel is
On 28/02/2024 10:24 am, 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
Hi Dave,
Some nitpicking in changelog:
On 5/03/2024 2:32 pm, Dave Young wrote:
crashkernel reservation failed on a Thinkpad t440s laptop recently,
',' -> '.' to make it as a standalone sentence.
Actually the memblock reservation succeeded, but later insert_resource()
failed.
Test step:
On 3/04/2024 4:42 am, Kirill A. Shutemov wrote:
On Fri, Mar 29, 2024 at 06:48:21PM +0200, Kirill A. Shutemov wrote:
On Fri, Mar 29, 2024 at 11:21:32PM +0800, Xiaoyao Li wrote:
On 3/25/2024 6:38 PM, Kirill A. Shutemov wrote:
TDX guests are not allowed to clear CR4.MCE. Attempt to clear it
On 25/03/2024 11:39 pm, Kirill A. Shutemov wrote:
AMD SEV and Intel TDX guests allocate shared buffers for performing I/O.
This is done by allocating pages normally from the buddy allocator and
then converting them to shared using set_memory_decrypted().
On kexec, the second kernel is
On Tue, 2024-04-09 at 14:29 +0300, Kirill A. Shutemov wrote:
> Depending on setup, TDX guests might be 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.
>
>
On Mon, 2024-03-25 at 12:39 +0200, 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 Mon, 2024-03-25 at 12:39 +0200, 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 Mon, 2024-03-25 at 12:39 +0200, 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
>
On Mon, 2024-03-25 at 12:39 +0200, Kirill A. Shutemov wrote:
> When MADT is parsed, print MULTIPROC_WAKEUP information:
>
> ACPI: MP Wakeup (version[1], mailbox[0x7fffd000], reset[0x7fffe068])
>
> This debug information will be very helpful during bring up.
>
> Signed-off-by: Kirill A. Shutemov
On Tue, 2024-05-28 at 12:55 +0300, Kirill A. Shutemov wrote:
> 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
> kexec flows, a #VE exception will be raised which the guest kernel
> cannot handle it.
Nit:
51 matches
Mail list logo
