Similar to the sme_me_mask, sev_enabled must live in .data section otherwise itwill get zero'ed in clear_bss() and we will loose the value. I have encounteredthis issue when booting SEV guest using qemu's -kernel option.

I have removed your R-b since was not sure if you are still okay with the change.

+/*+ * SME and SEV are very similar but they are not the same, so there are+ * times that the kernel will need to distinguish between SME and SEV. The+ * sme_active() and sev_active() functions are used for this. When a+ * distinction isn't needed, the mem_encrypt_active() function can be used.+ *+ * The trampoline code is a good example for this requirement. Before+ * paging is activated, SME will access all memory as decrypted, but SEV+ * will access all memory as encrypted. So, when APs are being brought+ * up under SME the trampoline area cannot be encrypted, whereas under SEV+ * the trampoline area must be encrypted.+ */+bool sme_active(void)+{+ return sme_me_mask && !sev_enabled;+}+EXPORT_SYMBOL_GPL(sme_active);++bool sev_active(void)+{+ return sme_me_mask && sev_enabled;+}+EXPORT_SYMBOL_GPL(sev_active);+ /* Architecture __weak replacement functions */ void __init mem_encrypt_init(void) {diff --git a/include/linux/mem_encrypt.h b/include/linux/mem_encrypt.hindex 265a9cd21cb4..b310a9c18113 100644--- a/include/linux/mem_encrypt.h+++ b/include/linux/mem_encrypt.h@@ -23,11 +23,14 @@