On Fri, Oct 20, 2023 at 03:29:24AM +, Huang, Kai wrote:
> 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
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:
> > > > On 10/5/2023 4:28 PM, Kirill A.
On Fri, Oct 20, 2023 at 09:49:59AM +, Huang, Kai wrote:
> 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; /*
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, 2023 at 01:41:38PM -0500, Kalra,
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_mailbox_paddr = mp_wake->base_address;
> >
On 18/10/23 1:51 pm, Pingfan Liu wrote:
On Tue, Oct 17, 2023 at 6:39 PM Hari Bathini wrote:
On 17/10/23 7:58 am, Pingfan Liu wrote:
*** Idea ***
For kexec -p, the boot cpu can be not the cpu0, this causes the problem
of allocating memory for paca_ptrs[]. However, in theory, there is no
On Fri, Oct 20, 2023 at 11:21:34AM +, Huang, Kai wrote:
>
> > --- /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)
> > + /*
To prepare for the addition of support for MADT wakeup structure version
1, it is necessary to provide more appropriate names for the fields in
the structure.
The field 'mailbox_version' renamed as 'version'. This field signifies
the version of the structure and the related protocols, rather than
MADT Multiprocessor Wakeup structure version 1 brings support of CPU
offlining: BIOS provides a reset vector where the CPU has to jump to
offline itself. The new TEST mailbox command can be used to test the CPU
offlined successfully and BIOS has control over it.
Add CPU offling support for ACPI
lookup_address() only returns correct page table level for the entry if
the entry is not none.
Make the helper to always return correct 'level'. It allows to implement
iterator over kernel page tables using lookup_address().
Add one more entry into enum pg_level to indicate size of VA covered by
e820__end_of_ram_pfn() is used to calculate max_pfn which, among other
things, guides where direct mapping ends. Any memory above max_pfn is
not going to be present in the direct mapping.
e820__end_of_ram_pfn() finds the end of the ram based on the highest
E820_TYPE_RAM range. But it doesn't
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 converted this way. It only
sees E820_TYPE_RAM.
Accessing shared memory via
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 method.
Introduce cpu_hotplug_not_supported() that can be called to
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 A.
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 use it to bring up secondary cpus.
Zero out mailbox address in the
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
---
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
The patchset adds bits and pieces to get kexec (and crashkernel) work on
TDX guest.
The last patch implements CPU offlining according to the approved ACPI
spec change poposal[1]. It unlocks kexec with all CPUs visible in the target
kernel. It requires BIOS-side enabling. If it missing we fallback
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 cause the second kernel to crash when it accesses it.
On Fri, Oct 20, 2023, 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 doesn't exist on some
> configurations, namely in TDX guest:
>
> unchecked MSR access error: WRMSR to 0x12 (tried to
ACPI MADT doesn't allow to offline CPU after it got woke up.
Currently 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 method.
Disable CPU offlining on ACPI MADT wakeup enumeration.
Signed-off-by:
kvm_guest_cpu_offline() tries to disable kvmclock regardless if it is
present in the VM. It leads to write to a MSR that doesn't exist on some
configurations, namely in TDX guest:
unchecked MSR access error: WRMSR to 0x12 (tried to write
0x)
at rIP:
On Fri, Oct 20, 2023 at 11:58:58AM +, Huang, Kai wrote:
> 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,
> > >
"Kirill A. Shutemov" writes:
> kvm_guest_cpu_offline() tries to disable kvmclock regardless if it is
> present in the VM. It leads to write to a MSR that doesn't exist on some
> configurations, namely in TDX guest:
>
> unchecked MSR access error: WRMSR to 0x12 (tried to write
>
On 10/20/2023 8:12 AM, 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.
>
> There
On Fri, Oct 20, 2023, Vitaly Kuznetsov wrote:
> > ---
> > arch/x86/kernel/kvmclock.c | 12
> > 1 file changed, 8 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
> > index fb8f52149be9..f2fff625576d 100644
> > ---
On 10/12/23 17:27, Stefan Berger wrote:
On 10/5/23 14:26, Tushar Sugandhi wrote:
The window between kexec 'load' and 'execute' could be arbitrarily long.
Even with the large chunk of memory allocated at kexec 'load', it may
run out which would result in missing events in IMA log after the
On 10/20/23 16:39, Tushar Sugandhi wrote:
On 10/12/23 17:27, Stefan Berger wrote:
On 10/5/23 14:26, Tushar Sugandhi wrote:
IMA currently allocates half a PAGE_SIZE for the extra events that
would
be measured between kexec 'load' and 'execute'. Depending on the IMA
policy and the system
Thanks a lot Stefan for reviewing this series.
Really appreciate it.
On 10/12/23 17:28, Stefan Berger wrote:
On 10/5/23 14:25, Tushar Sugandhi wrote:
IMA allocates memory and dumps the measurement during kexec soft reboot
as a single function call ima_dump_measurement_list(). It gets called
On 10/20/23 14:16, Stefan Berger wrote:
No, what I mean is you should ask the user for how many extra kilobytes
(kb) to allocate - not ask for pages.
Stefan
Ok. Will do.
I will align the input config value to the PAGE_SIZE as well.
On 10/12/23 17:28, Stefan Berger wrote:
On 10/5/23 14:25, Tushar Sugandhi wrote:
In the current IMA implementation, ima_dump_measurement_list() is called
during the kexec 'load' operation. This can result in loss of IMA
measurements taken between the 'load' and 'execute' phases when the
On 10/20/23 16:33, Tushar Sugandhi wrote:
Thanks a lot Stefan for reviewing this series.
Really appreciate it.
You are welcome.
What may be a bit problematic is the fact that between the time the
buffer for the flattened IMA log is allocated (kexec 'load') and the
time it is filled
On 10/12/23 17:29, Stefan Berger wrote:
On 10/5/23 14:25, Tushar Sugandhi wrote:
Currently, the mechanism to map and unmap segments to the kimage
structure is not available to the subsystems outside of kexec. This
functionality is needed when IMA is allocating the memory segments
during
On 10/12/23 17:27, Stefan Berger wrote:
On 10/5/23 14:26, Tushar Sugandhi wrote:
IMA currently allocates half a PAGE_SIZE for the extra events that would
be measured between kexec 'load' and 'execute'. Depending on the IMA
policy and the system state, that memory may not be sufficient to
On 10/20/23 14:21, Stefan Berger wrote:
On 10/20/23 16:33, Tushar Sugandhi wrote:
Thanks a lot Stefan for reviewing this series.
Really appreciate it.
You are welcome.
What may be a bit problematic is the fact that between the time the
buffer for the flattened IMA log is allocated
37 matches
Mail list logo
