All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Ashish Kalra <ashish.kalra@amd.com>
Cc: Vasant Hegde <vasant.hegde@amd.com>,
	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,  joro@8bytes.org,
	suravee.suthikulpanit@amd.com, will@kernel.org,
	 robin.murphy@arm.com, 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,  iommu@lists.linux.dev
Subject: Re: [PATCH 1/4] iommu/amd: Check SNP support before enabling IOMMU
Date: Mon, 27 Jan 2025 13:12:14 -0800	[thread overview]
Message-ID: <Z5f2rnMyBAjK88dP@google.com> (raw)
In-Reply-To: <e23a94f0-c35f-4d50-b348-4cd64b5ebb67@amd.com>

On Mon, Jan 27, 2025, Ashish Kalra wrote:
> Hello Sean,
> 
> On 1/24/2025 6:39 PM, Sean Christopherson wrote:
> > On Fri, Jan 24, 2025, Ashish Kalra wrote:
> >> With discussions with the AMD IOMMU team, here is the AMD IOMMU
> >> initialization flow:
> > 
> > ..
> > 
> >> IOMMU SNP check
> >>   Core IOMMU subsystem init is done during iommu_subsys_init() via
> >>   subsys_initcall.  This function does change the DMA mode depending on
> >>   kernel config.  Hence, SNP check should be done after subsys_initcall.
> >>   That's why its done currently during IOMMU PCI init (IOMMU_PCI_INIT stage).
> >>   And for that reason snp_rmptable_init() is currently invoked via
> >>   device_initcall().
> >>  
> >> The summary is that we cannot move snp_rmptable_init() to subsys_initcall as
> >> core IOMMU subsystem gets initialized via subsys_initcall.
> > 
> > Just explicitly invoke RMP initialization during IOMMU SNP setup.  Pretending
> > there's no connection when snp_rmptable_init() checks amd_iommu_snp_en and has
> > a comment saying it needs to come after IOMMU SNP setup is ridiculous.
> > 
> 
> Thanks for the suggestion and the patch, i have tested it works for all cases
> and scenarios. I will post the next version of the patch-set based on this
> patch.

One thing I didn't account for: if IOMMU initialization fails and iommu_snp_enable()
is never reached, CC_ATTR_HOST_SEV_SNP will be left set.

I don't see any great options.  Something like the below might work?  And maybe
keep a device_initcall() in arch/x86/virt/svm/sev.c that sanity checks that SNP
really is fully enabled?  Dunno, hopefully someone has a better idea.

diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
index 0e0a531042ac..6d62ee8e0055 100644
--- a/drivers/iommu/amd/init.c
+++ b/drivers/iommu/amd/init.c
@@ -3295,6 +3295,9 @@ static int __init iommu_go_to_state(enum iommu_init_state state)
                ret = state_next();
        }
 
+       if (ret && !amd_iommu_snp_en)
+               cc_platform_clear(CC_ATTR_HOST_SEV_SNP);
+
        return ret;
 }

  reply	other threads:[~2025-01-27 21:12 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-22  0:59 [PATCH 0/4] Fix broken SNP support with KVM module built-in Ashish Kalra
2025-01-22  1:00 ` [PATCH 1/4] iommu/amd: Check SNP support before enabling IOMMU Ashish Kalra
2025-01-22 15:22   ` Tom Lendacky
2025-01-22 17:07     ` Vasant Hegde
2025-01-24 21:46       ` Kalra, Ashish
2025-01-25  0:39         ` Sean Christopherson
2025-01-27 20:43           ` Kalra, Ashish
2025-01-27 21:12             ` Sean Christopherson [this message]
2025-01-29  9:24               ` Vasant Hegde
2025-01-22  1:00 ` [PATCH 2/4] crypto: ccp: Add external API interface for PSP module initialization Ashish Kalra
2025-01-22 15:53   ` Tom Lendacky
2025-01-22  1:00 ` [PATCH 3/4] KVM: SVM: Ensure PSP module initialized before built-in KVM module Ashish Kalra
2025-01-22 15:58   ` Tom Lendacky
2025-01-22  1:00 ` [PATCH 4/4] x86/sev: Fix broken SNP support with KVM module built-in Ashish Kalra
2025-01-22 16:07   ` Tom Lendacky

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=Z5f2rnMyBAjK88dP@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=iommu@lists.linux.dev \
    --cc=john.allen@amd.com \
    --cc=joro@8bytes.org \
    --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=robin.murphy@arm.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=vasant.hegde@amd.com \
    --cc=will@kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.