technology-specific checks
to the code (e.g. if (sev_active() || tdx_active())).
Reviewed-by: Joerg Roedel
Co-developed-by: Andi Kleen
Signed-off-by: Andi Kleen
Co-developed-by: Kuppuswamy
Sathyanarayanan
Signed-off-by: Kuppuswamy
Sathyanarayanan
Signed-off-by: Tom Lendacky
---
arch/Kconfig
On 8/19/21 11:33 AM, Tom Lendacky wrote:
There was some talk about this on the mailing list where TDX and SEV may
need to be differentiated, so we wanted to reserve a range of values per
technology. I guess I can remove them until they are actually needed.
In TDX also we have similar
patch (please check following patch). But it includes
TDX changes as well. Shall I move TDX changes to different patch and just
create a separate patch for adding intel_cc_platform_has()?
commit fc5f98a0ed94629d903827c5b44ee9295f835831
Author: Kuppuswamy Sathyanarayanan
Date: Wed May 12 11:35:13
On 9/16/21 8:02 AM, Borislav Petkov wrote:
On Wed, Sep 15, 2021 at 10:26:06AM -0700, Kuppuswamy, Sathyanarayanan wrote:
I have a Intel variant patch (please check following patch). But it includes
TDX changes as well. Shall I move TDX changes to different patch and just
create a separate
Hi Tom,
On 7/27/21 3:26 PM, Tom Lendacky wrote:
This patch series provides a generic helper function, prot_guest_has(),
to replace the sme_active(), sev_active(), sev_es_active() and
mem_encrypt_active() functions.
It is expected that as new protected virtualization technologies are
added to
On 8/9/21 2:59 PM, Tom Lendacky wrote:
Not sure how TDX will handle AP booting, are you sure it needs this
special setup as well? Otherwise a check for SEV-ES would be better
instead of the generic PATTR_GUEST_PROT_STATE.
Yes, I'm not sure either. I figure that change can be made, if needed,
On 8/10/21 12:48 PM, Tom Lendacky wrote:
On 8/10/21 1:45 PM, Kuppuswamy, Sathyanarayanan wrote:
On 7/27/21 3:26 PM, Tom Lendacky wrote:
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index de01903c3735..cafed6456d45 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86
On 7/27/21 3:26 PM, Tom Lendacky wrote:
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index de01903c3735..cafed6456d45 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -19,7 +19,7 @@
#include
#include
#include
-#include
+#include
#include
On 7/27/21 3:26 PM, Tom Lendacky wrote:
diff --git a/include/linux/protected_guest.h b/include/linux/protected_guest.h
new file mode 100644
index ..f8ed7b72967b
--- /dev/null
+++ b/include/linux/protected_guest.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+
On 9/28/21 12:10 PM, Borislav Petkov wrote:
From: Borislav Petkov
Hi all,
here's v4 of the cc_platform_has() patchset with feedback incorporated.
I'm going to route this through tip if there are no objections.
Intel CC support patch is not included in this series. You want me
to address
On 9/28/21 1:31 PM, Borislav Petkov wrote:
On Tue, Sep 28, 2021 at 12:19:49PM -0700, Kuppuswamy, Sathyanarayanan wrote:
Intel CC support patch is not included in this series. You want me
to address the issue raised by Joerg before merging it?
Did you not see my email to you today:
https
On 9/28/21 1:58 PM, Borislav Petkov wrote:
On Tue, Sep 28, 2021 at 01:48:46PM -0700, Kuppuswamy, Sathyanarayanan wrote:
Just read it. If you want to use cpuid_has_tdx_guest() directly in
cc_platform_has(), then you want to rename intel_cc_platform_has() to
tdx_cc_platform_has()?
Why?
You
h is set for Intel TDX. But TDX is not the only possible
> user of the wake up method.
>
> Mark CPU hotplug as "not supported" on ACPI MADT wakeup enumeration.
Looks good to me.
Reviewed-by: Kuppuswamy Sathyanarayanan
>
> Signed-off-by: Kirill A. Shutemov
> ---
>
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 doesn't exist on some
> configurations, namely in TDX guest:
>
> unchecked MSR access error: WRMSR to 0x12 (tried
nded to replace CC_ATTR_HOTPLUG_DISABLED.
>
Looks good to me.
Reviewed-by: Kuppuswamy Sathyanarayanan
> Signed-off-by: Kirill A. Shutemov
> ---
> include/linux/cpu.h | 2 ++
> kernel/cpu.c| 17 -
> 2 files changed, 18 insertions(+), 1 deletion(-)
>
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 separate file.
> A new configuration option has been introduced to clearly indicate
> dependencies without the
e use of ifdefs.
>
> There have been no functional changes.
>
> Signed-off-by: Kirill A. Shutemov
> ---
Looks good to me.
Reviewed-by: Kuppuswamy Sathyanarayanan
> arch/x86/Kconfig | 7 +++
> arch/x86/include/asm/acpi.h| 5 ++
> arch/x86/kernel/a
version 1, the structure includes the
> reset vector address. Clear and distinct naming helps to prevent any
> confusion.
>
> Signed-off-by: Kirill A. Shutemov
> ---
Reviewed-by: Kuppuswamy Sathyanarayanan
> arch/x86/kernel/acpi/madt_wakeup.c | 4 ++--
> include/acpi/actbl2.h
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 one CPU.
>
> Now acpi_mp_wake_mailbox_paddr already has the mailbox address.
> The acpi_wakeup_cpu() will use it
makes is possible to hand over secondary CPUs over kexec,
> not limiting the second kernel to a single CPU.
>
> The change conforms to the approved ACPI spec change proposal. See the
> Link.
>
> Signed-off-by: Kirill A. Shutemov
> Link: https://lore.kernel.org/all/13356251
ly be able to use the boot CPU.
>
> This is Linux-specific protocol and not reflected in ACPI spec.
>
> Booting the second kernel with signle CPU is enough to cover the most
> common case for kexec -- kdump.
>
> Signed-off-by: Kirill A. Shutemov
> Reviewed-by: Kai Huang
> ---
L
Shutemov
> Reviewed-by: Baoquan He
> ---
Looks good to me.
Reviewed-by: Kuppuswamy Sathyanarayanan
> drivers/acpi/tables.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
> index b07f7d091d13..c59a361
A. Shutemov
> ---
Looks good to me.
Reviewed-by: Kuppuswamy Sathyanarayanan
> arch/x86/coco/tdx/tdx.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c
> index 26fa47db5782..979891e97d83 100644
> --- a/arch/x86/
Shutemov
> Reviewed-by: Baoquan He
> ---
Looks good to me.
Reviewed-by: Kuppuswamy Sathyanarayanan
> drivers/acpi/tables.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
> index b976e5fc3fbc..9e1b01c
rial, hence,
> skip accessing video RAM during decompressor stage to
> prevent guest termination.
>
> Serial console output during decompressor stage works as
> boot stage2 #VC handler already supports handling port I/O.
>
> Suggested-by: Thomas Lendacy
> Signed-off-by:
On 4/4/24 4:11 PM, Ashish Kalra wrote:
> From: Ashish Kalra
>
> Add sev_es_enabled() function to detect if SEV-ES
> support is enabled.
>
> Signed-off-by: Ashish Kalra
> ---
Looks good to me.
Reviewed-by: Kuppuswamy Sathyanarayanan
> arch/x86/boot/compressed/sev
On 4/4/24 4:11 PM, 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.
>
> Additionally during SNP guest kexec testing discovered
27 matches
Mail list logo
