public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Ashish Kalra <ashish.kalra@amd.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>,
	pbonzini@redhat.com, tglx@linutronix.de,  mingo@redhat.com,
	bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
	 hpa@zytor.com, john.allen@amd.com, herbert@gondor.apana.org.au,
	 davem@davemloft.net, michael.roth@amd.com,
	dionnaglaze@google.com,  kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org,  linux-crypto@vger.kernel.org,
	linux-coco@lists.linux.dev
Subject: Re: [PATCH v3 6/7] KVM: SVM: Add support to initialize SEV/SNP functionality in KVM
Date: Tue, 14 Jan 2025 14:31:44 -0800	[thread overview]
Message-ID: <Z4bl0D4CbtHgwGGW@google.com> (raw)
In-Reply-To: <f02fee7d-27e8-4ddc-b349-6d0f8c7919fa@amd.com>

On Tue, Jan 14, 2025, Ashish Kalra wrote:
> On 1/13/2025 9:03 AM, Kalra, Ashish wrote:
> > SNP host support is enabled in snp_rmptable_init() in
> > arch/x86/virt/svm/sev.c, which is invoked as a device_initcall().  Here
> > device_initcall() is used as snp_rmptable_init() expects AMD IOMMU SNP
> > support to be enabled prior to it and the AMD IOMMU driver is initialized
> > after PCI bus enumeration. 

Ugh.  So. Many. Dependencies.

That's a kernel bug, full stop.  RMP initialization very obviously is not device
initialization.

Why isn't snp_rmptable_init() called from mem_encrypt_init()?  AFAICT,
arch_cpu_finalize_init() is called after IOMMU initialziation.  And if that
doesn't work, hack it into arch_post_acpi_subsys_init().  Using device_initcall()
to initialization the RMP is insane, IMO.

> > Additionally, the PSP driver probably needs to be initialized at
> > device_initcall level if it is built-in, but that is much later than KVM
> > module initialization, therefore, that is blocker for moving SEV/SNP
> > initialization to KVM module load time instead of PSP module probe time.
> > Do note that i have verified and tested that PSP module initialization
> > works when invoked as a device_initcall(). 
> 
> As a follow-up to the above issues, i have an important question: 
> 
> Do we really need kvm_amd module to be built-in for SEV/SNP support ?

Yes.

> Is there any usage case/scenario where the kvm_amd module needs to be
> built-in for SEV/SNP support ?

Don't care.  I am 100% against setting a precedent of tying features to KVM
being a module or not, especially since this is a solvable problem.

Ideally, the initcall infrastructure would let modules express dependencies, but
I can appreciate that solving this generically would require a high amount of
complexity.

Having KVM explicitly call into the PSP driver as needed isn't difficult, just
gross.  But for me, it's still far better giving up and requiring everything to
be modules.

E.g.

diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 943bd074a5d3..a2ee12e998f0 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -2972,6 +2972,16 @@ void __init sev_hardware_setup(void)
            WARN_ON_ONCE(!boot_cpu_has(X86_FEATURE_FLUSHBYASID)))
                goto out;
 
+       /*
+        * The kernel's initcall infrastructure lacks the ability to express
+        * dependencies between initcalls, where as the modules infrastructure
+        * automatically handles dependencies via symbol loading.  Ensure the
+        * PSP SEV driver is initialized before proceeding if KVM is built-in,
+        * as the dependency isn't handled by the initcall infrastructure.
+        */
+       if (IS_BUILTIN(CONFIG_KVM_AMD) && sev_module_init())
+               goto out;
+
        /* Retrieve SEV CPUID information */
        cpuid(0x8000001f, &eax, &ebx, &ecx, &edx);
 
diff --git a/drivers/crypto/ccp/sp-dev.c b/drivers/crypto/ccp/sp-dev.c
index 7eb3e4668286..a0cdc03984cb 100644
--- a/drivers/crypto/ccp/sp-dev.c
+++ b/drivers/crypto/ccp/sp-dev.c
@@ -253,8 +253,12 @@ struct sp_device *sp_get_psp_master_device(void)
 static int __init sp_mod_init(void)
 {
 #ifdef CONFIG_X86
+       static bool initialized;
        int ret;
 
+       if (initialized)
+               return 0;
+
        ret = sp_pci_init();
        if (ret)
                return ret;
@@ -263,6 +267,7 @@ static int __init sp_mod_init(void)
        psp_pci_init();
 #endif
 
+       initialized = true;
        return 0;
 #endif
 
@@ -279,6 +284,13 @@ static int __init sp_mod_init(void)
        return -ENODEV;
 }
 
+#if IS_BUILTIN(CONFIG_KVM_AMD) && IS_ENABLED(CONFIG_KVM_AMD_SEV)
+int __init sev_module_init(void)
+{
+       return sp_mod_init();
+}
+#endif
+
 static void __exit sp_mod_exit(void)
 {
 #ifdef CONFIG_X86
diff --git a/include/linux/psp-sev.h b/include/linux/psp-sev.h
index 903ddfea8585..0138d22b46ac 100644
--- a/include/linux/psp-sev.h
+++ b/include/linux/psp-sev.h
@@ -814,6 +814,8 @@ struct sev_data_snp_commit {
 
 #ifdef CONFIG_CRYPTO_DEV_SP_PSP
 
+int __init sev_module_init(void);
+
 /**
  * sev_platform_init - perform SEV INIT command
  *

  reply	other threads:[~2025-01-14 22:31 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-03 19:58 [PATCH v3 0/7] Move initializing SEV/SNP functionality to KVM Ashish Kalra
2025-01-03 19:59 ` [PATCH v3 1/7] crypto: ccp: Move dev_info/err messages for SEV/SNP initialization Ashish Kalra
2025-01-06 17:17   ` Dionna Amalie Glaze
2025-01-06 23:08     ` Kalra, Ashish
2025-01-07 14:29   ` Tom Lendacky
2025-01-03 20:00 ` [PATCH v3 2/7] crypto: ccp: Fix implicit SEV/SNP init and shutdown in ioctls Ashish Kalra
2025-01-06 18:01   ` Dionna Amalie Glaze
2025-01-06 23:48     ` Kalra, Ashish
2025-01-07 19:08       ` Kalra, Ashish
2025-01-07  3:29   ` Alexey Kardashevskiy
2025-01-07 18:53     ` Kalra, Ashish
2025-01-03 20:00 ` [PATCH v3 3/7] crypto: ccp: Reset TMR size at SNP Shutdown Ashish Kalra
2025-01-03 20:00 ` [PATCH v3 4/7] crypto: ccp: Register SNP panic notifier only if SNP is enabled Ashish Kalra
2025-01-06 19:08   ` Dionna Amalie Glaze
2025-01-03 20:01 ` [PATCH v3 5/7] crypto: ccp: Add new SEV/SNP platform shutdown API Ashish Kalra
2025-01-06 19:14   ` Dionna Amalie Glaze
2025-01-03 20:01 ` [PATCH v3 6/7] KVM: SVM: Add support to initialize SEV/SNP functionality in KVM Ashish Kalra
2025-01-07 16:42   ` Tom Lendacky
2025-01-07 18:34     ` Kalra, Ashish
2025-01-07 20:56       ` Kalra, Ashish
2025-01-08 17:22       ` Tom Lendacky
2025-01-09  0:27         ` Kalra, Ashish
2025-01-10 22:41           ` Kalra, Ashish
2025-01-11  0:40             ` Sean Christopherson
2025-01-11  0:41               ` Dionna Amalie Glaze
2025-01-11  0:49                 ` Sean Christopherson
2025-01-13 15:03               ` Kalra, Ashish
2025-01-14 21:14                 ` Kalra, Ashish
2025-01-14 22:31                   ` Sean Christopherson [this message]
2025-01-15 22:26                     ` Kalra, Ashish
2025-01-03 20:02 ` [PATCH v3 7/7] crypto: ccp: Move SEV/SNP Platform initialization to KVM Ashish Kalra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z4bl0D4CbtHgwGGW@google.com \
    --to=seanjc@google.com \
    --cc=ashish.kalra@amd.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=davem@davemloft.net \
    --cc=dionnaglaze@google.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=hpa@zytor.com \
    --cc=john.allen@amd.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.roth@amd.com \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox