Re: [PATCH v2 03/12] x86/sev: Add an x86 version of prot_guest_has()
On 8/14/21 2:08 PM, Borislav Petkov wrote:
On Fri, Aug 13, 2021 at 11:59:22AM -0500, Tom Lendacky wrote:
diff --git a/arch/x86/include/asm/protected_guest.h
b/arch/x86/include/asm/protected_guest.h
new file mode 100644
index ..51e4eefd9542
--- /dev/null
+++ b/arch/x86/include/asm/protected_guest.h
@@ -0,0 +1,29 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Protected Guest (and Host) Capability checks
+ *
+ * Copyright (C) 2021 Advanced Micro Devices, Inc.
+ *
+ * Author: Tom Lendacky
+ */
+
+#ifndef _X86_PROTECTED_GUEST_H
+#define _X86_PROTECTED_GUEST_H
+
+#include
+
+#ifndef __ASSEMBLY__
+
+static inline bool prot_guest_has(unsigned int attr)
+{
+#ifdef CONFIG_AMD_MEM_ENCRYPT
+ if (sme_me_mask)
+ return amd_prot_guest_has(attr);
+#endif
+
+ return false;
+}
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* _X86_PROTECTED_GUEST_H */
I think this can be simplified more, diff ontop below:
- no need for the ifdeffery as amd_prot_guest_has() has versions for
both when CONFIG_AMD_MEM_ENCRYPT is set or not.
Ugh, yeah, not sure why I put that in for this version since I have the
static inline for when CONFIG_AMD_MEM_ENCRYPT is not set.
- the sme_me_mask check is pushed there too.
- and since this is vendor-specific, I'm checking the vendor bit. Yeah,
yeah, cross-vendor but I don't really believe that.
It's not a cross-vendor thing as opposed to a KVM or other hypervisor
thing where the family doesn't have to be reported as AMD or HYGON. That's
why I made the if check be for sme_me_mask. I think that is the safer way
to go.
Thanks,
Tom
---
diff --git a/arch/x86/include/asm/protected_guest.h
b/arch/x86/include/asm/protected_guest.h
index 51e4eefd9542..8541c76d5da4 100644
--- a/arch/x86/include/asm/protected_guest.h
+++ b/arch/x86/include/asm/protected_guest.h
@@ -12,18 +12,13 @@
#include
-#ifndef __ASSEMBLY__
-
static inline bool prot_guest_has(unsigned int attr)
{
-#ifdef CONFIG_AMD_MEM_ENCRYPT
- if (sme_me_mask)
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
return amd_prot_guest_has(attr);
-#endif
return false;
}
-#endif /* __ASSEMBLY__ */
-
#endif/* _X86_PROTECTED_GUEST_H */
diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
index edc67ddf065d..5a0442a6f072 100644
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@ -392,6 +392,9 @@ bool noinstr sev_es_active(void)
bool amd_prot_guest_has(unsigned int attr)
{
+ if (!sme_me_mask)
+ return false;
+
switch (attr) {
case PATTR_MEM_ENCRYPT:
return sme_me_mask != 0;
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2 03/12] x86/sev: Add an x86 version of prot_guest_has()
On Sun, Aug 15, 2021 at 08:53:31AM -0500, Tom Lendacky wrote: > It's not a cross-vendor thing as opposed to a KVM or other hypervisor > thing where the family doesn't have to be reported as AMD or HYGON. What would be the use case? A HV starts a guest which is supposed to be encrypted using the AMD's confidential guest technology but the HV tells the guest that it is not running on an AMD SVM HV but something else? Is that even an actual use case? Or am I way off? I know we have talked about this in the past but this still sounds insane. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v5 0/9] Add generic support for kdump DT properties
On Wed, Aug 11, 2021 at 10:50:58AM +0200, Geert Uytterhoeven wrote:
> Hi all,
>
> This patch series adds generic support for parsing DT properties related
> to crash dump kernels ("linux,elfcorehdr" and "linux,elfcorehdr" under
> the "/chosen" node), makes use of it on arm32, and performs a few
> cleanups. It is an evolution of the combination of [1] and [2].
The DT bits look fine to me. How do you expect this to be merged? I'm
happy to take it if arch maintainers can ack it.
>
> The series consists of 6 parts:
> 1. Patch 1 prepares architecture-specific code (needed for MIPS only)
> to avoid duplicating elf core header reservation later.
> 2. Patch 2 prepares the visibility of variables used to hold
> information retrieved from the DT properties.
> 3. Patches 3-5 add support to the FDT core for handling the
> properties.
> This can co-exist safely with architecture-specific handling, until
> the latter has been removed.
Looks like patch 5 doesn't have any dependencies with the series?
> 4. Patch 6 removes the non-standard handling of "linux,elfcorehdr" on
> riscv.
I thought this should be applied for 5.14?
> 5. Patches 7-8 convert arm64 to use the generic handling instead of
> its own implementation.
> 6. Patch 9 adds support for kdump properties to arm32.
> The corresponding patch for kexec-tools is "[PATCH] arm: kdump: Add
> DT properties to crash dump kernel's DTB"[3], which is still valid.
This one can be applied on its own, right?
Rob
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
RE: [PATCH 0/2] makedumpfile: fix two bugs with --dry-run
-Original Message- > Hi, > > While playing with the --dry-run option I noticed two bugs. You can find the > fixes below. > > Thanks > Philipp > > Philipp Rudo (2): > makedumpfile: Fix bad file descriptor error when using --dry-run > makedumpfile: Fix --dry-run for incomplete dumps > > makedumpfile.c | 11 +-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > -- > 2.31.1 Thank you for the fixes, applied. https://github.com/makedumpfile/makedumpfile/compare/efef023...5684d4c Kazu ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v5 1/9] MIPS: Avoid future duplicate elf core header reservation
Hi Geert,
On Wed, Aug 11, 2021 at 10:50:59AM +0200, Geert Uytterhoeven wrote:
> Prepare for early_init_fdt_scan_reserved_mem() reserving the memory
> occupied by an elf core header described in the device tree.
> As arch_mem_init() calls early_init_fdt_scan_reserved_mem() before
> mips_reserve_vmcore(), the latter needs to check if the memory has
> already been reserved before.
Doing memblock_reserve() for the same region is usually fine, did you
encounter any issues without this patch?
> Note that mips_reserve_vmcore() cannot just be removed, as not all MIPS
> systems use DT.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> v5:
> - New.
> ---
> arch/mips/kernel/setup.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
> index 23a140327a0bac1b..4693add05743d78b 100644
> --- a/arch/mips/kernel/setup.c
> +++ b/arch/mips/kernel/setup.c
> @@ -429,7 +429,8 @@ static void __init mips_reserve_vmcore(void)
> pr_info("Reserving %ldKB of memory at %ldKB for kdump\n",
> (unsigned long)elfcorehdr_size >> 10, (unsigned
> long)elfcorehdr_addr >> 10);
>
> - memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> + if (!memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)
> + memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> #endif
> }
>
> --
> 2.25.1
>
--
Sincerely yours,
Mike.
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
