From: Borislav Petkov <bp@alien8.de>
To: Jeremi Piotrowski <jpiotrowski@linux.microsoft.com>
Cc: Michael Roth <michael.roth@amd.com>,
x86@kernel.org, kvm@vger.kernel.org, linux-coco@lists.linux.dev,
linux-mm@kvack.org, linux-crypto@vger.kernel.org,
linux-kernel@vger.kernel.org, tglx@linutronix.de,
mingo@redhat.com, jroedel@suse.de, thomas.lendacky@amd.com,
hpa@zytor.com, ardb@kernel.org, pbonzini@redhat.com,
seanjc@google.com, vkuznets@redhat.com, jmattson@google.com,
luto@kernel.org, dave.hansen@linux.intel.com, slp@redhat.com,
pgonda@google.com, peterz@infradead.org,
srinivas.pandruvada@linux.intel.com, rientjes@google.com,
tobin@ibm.com, vbabka@suse.cz, kirill@shutemov.name,
ak@linux.intel.com, tony.luck@intel.com,
sathyanarayanan.kuppuswamy@linux.intel.com, alpergun@google.com,
jarkko@kernel.org, ashish.kalra@amd.com, nikunj.dadhania@amd.com,
pankaj.gupta@amd.com, liam.merwick@oracle.com,
zhi.a.wang@intel.com, Brijesh Singh <brijesh.singh@amd.com>
Subject: Re: [PATCH v1 04/26] x86/sev: Add the host SEV-SNP initialization support
Date: Tue, 9 Jan 2024 13:29:06 +0100 [thread overview]
Message-ID: <20240109122906.GCZZ08Esh86vhGwVx1@fat_crate.local> (raw)
In-Reply-To: <b5b57b60-1573-44f4-8161-e2249eb6f9b6@linux.microsoft.com>
On Tue, Jan 09, 2024 at 12:56:17PM +0100, Jeremi Piotrowski wrote:
> Can we please not assume I am acting in bad faith.
No you're not acting with bad faith.
What you're doing, in my experience so far is, you come with some weird
HV + guest models which has been invented somewhere, behind some closed
doors, then you come with some desire that the upstream kernel should
support it and you're not even documenting it properly and I'm left with
asking questions all the time, what is this, what's the use case,
blabla.
Don't take this personally - I guess this is all due to NDAs,
development schedules, and whatever else and yes, I've heard it all.
But just because you want this, we're not going to jump on it and
support it unconditionally. It needs to integrate properly with the rest
of the kernel and if it doesn't, it is not going upstream. That simple.
> I am explicitly trying to integrate nicely with AMD's KVM SNP host
> patches to cover an additional usecase and get something upstreamable.
And yet I still have no clue what your use case is. I always have to go
ask behind the scenes and get some half-answers about *maybe* this is
what they support.
Looking at the patch you pointed at I see there a proper explanation of
your nested SNP stuff. Finally!
From now on, please make sure your use case is properly explained
before you come with patches.
> The RMP in nested SNP is only used for kernel bookkeeping and so its
> allocation is optional. KVM could do without reading the RMP directly
> altogether (by tracking the assigned bit somewhere) but that would be
> a design change and I'd rather see the KVM SNP host patches merged in
> their current shape. Which is why the patch I linked allocates
> a (shadow) RMP from the kernel.
At least three issues I see with that:
- the allocation can fail so it is a lot more convenient when the
firmware prepares it
- the RMP_BASE and RMP_END writes need to be verified they actially did
set up the RMP range because if they haven't, you might as well
throw SNP security out of the window. In general, letting the kernel
do the RMP allocation needs to be verified very very thoroughly.
- a future feature might make this more complicated
> I would very much appreciate if we would not prevent that usecase from
> working - that's why I've been reviewing and testing multiple
> revisions of these patches and providing feedback all along.
I very much appreciate the help but we need to get the main SNP host
stuff in first and then we can talk about modifications.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2024-01-09 12:30 UTC|newest]
Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-30 16:19 [PATCH v1 00/26] Add AMD Secure Nested Paging (SEV-SNP) Initialization Support Michael Roth
2023-12-30 16:19 ` [PATCH v1 01/26] x86/cpufeatures: Add SEV-SNP CPU feature Michael Roth
2023-12-31 11:50 ` Borislav Petkov
2023-12-31 16:44 ` Michael Roth
2023-12-30 16:19 ` [PATCH v1 02/26] x86/speculation: Do not enable Automatic IBRS if SEV SNP is enabled Michael Roth
2023-12-30 16:19 ` [PATCH v1 03/26] iommu/amd: Don't rely on external callers to enable IOMMU SNP support Michael Roth
2024-01-04 10:30 ` Borislav Petkov
2024-01-04 10:58 ` Joerg Roedel
2023-12-30 16:19 ` [PATCH v1 04/26] x86/sev: Add the host SEV-SNP initialization support Michael Roth
2024-01-04 11:05 ` Jeremi Piotrowski
2024-01-05 16:09 ` Borislav Petkov
2024-01-05 16:21 ` Borislav Petkov
2024-01-08 16:49 ` Jeremi Piotrowski
2024-01-08 17:04 ` Borislav Petkov
2024-01-09 11:56 ` Jeremi Piotrowski
2024-01-09 12:29 ` Borislav Petkov [this message]
2024-01-09 12:44 ` Borislav Petkov
2024-02-14 16:56 ` Jeremi Piotrowski
2024-01-04 11:16 ` Borislav Petkov
2024-01-04 14:42 ` Borislav Petkov
2024-01-05 19:19 ` Borislav Petkov
2024-01-05 21:27 ` Borislav Petkov
2023-12-30 16:19 ` [PATCH v1 05/26] x86/mtrr: Don't print errors if MtrrFixDramModEn is set when SNP enabled Michael Roth
2023-12-30 16:19 ` [PATCH v1 06/26] x86/sev: Add RMP entry lookup helpers Michael Roth
2023-12-30 16:19 ` [PATCH v1 07/26] x86/fault: Add helper for dumping RMP entries Michael Roth
2024-01-10 9:59 ` Borislav Petkov
2024-01-10 20:18 ` Jarkko Sakkinen
2024-01-10 22:14 ` Borislav Petkov
2024-01-10 11:13 ` Borislav Petkov
2024-01-10 15:20 ` Tom Lendacky
2024-01-10 15:27 ` Borislav Petkov
2024-01-10 15:51 ` Tom Lendacky
2024-01-10 15:55 ` Borislav Petkov
2024-01-10 15:10 ` Tom Lendacky
2023-12-30 16:19 ` [PATCH v1 08/26] x86/traps: Define RMP violation #PF error code Michael Roth
2023-12-30 16:19 ` [PATCH v1 09/26] x86/fault: Dump RMP table information when RMP page faults occur Michael Roth
2023-12-30 16:19 ` [PATCH v1 10/26] x86/sev: Add helper functions for RMPUPDATE and PSMASH instruction Michael Roth
2024-01-12 14:49 ` Borislav Petkov
2023-12-30 16:19 ` [PATCH v1 11/26] x86/sev: Invalidate pages from the direct map when adding them to the RMP table Michael Roth
2024-01-12 19:48 ` Borislav Petkov
2024-01-12 20:00 ` Dave Hansen
2024-01-12 20:07 ` Borislav Petkov
2024-01-12 20:27 ` Vlastimil Babka
2024-01-15 9:06 ` Borislav Petkov
2024-01-15 9:14 ` Vlastimil Babka
2024-01-15 9:16 ` Mike Rapoport
2024-01-15 9:20 ` Borislav Petkov
2024-01-12 20:28 ` Tom Lendacky
2024-01-12 20:37 ` Dave Hansen
2024-01-15 9:23 ` Vlastimil Babka
2024-01-16 16:19 ` Michael Roth
2024-01-16 16:50 ` Michael Roth
[not found] ` <ZabjKpCqx9np0SEI@kernel.org>
2024-01-26 1:49 ` Michael Roth
2024-01-16 18:22 ` Borislav Petkov
2024-01-16 20:22 ` Dave Hansen
2024-01-26 1:35 ` Michael Roth
2024-01-15 9:09 ` Borislav Petkov
2024-01-16 16:21 ` Dave Hansen
2024-01-17 9:34 ` Borislav Petkov
2024-01-15 9:01 ` Borislav Petkov
2023-12-30 16:19 ` [PATCH v1 12/26] crypto: ccp: Define the SEV-SNP commands Michael Roth
2024-01-15 9:41 ` Borislav Petkov
2024-01-26 1:56 ` Michael Roth
2023-12-30 16:19 ` [PATCH v1 13/26] crypto: ccp: Add support to initialize the AMD-SP for SEV-SNP Michael Roth
2024-01-15 11:19 ` Borislav Petkov
2024-01-15 19:53 ` Borislav Petkov
2024-01-26 2:48 ` Michael Roth
2023-12-30 16:19 ` [PATCH v1 14/26] crypto: ccp: Provide API to issue SEV and SNP commands Michael Roth
2024-01-17 9:48 ` Borislav Petkov
2023-12-30 16:19 ` [PATCH v1 15/26] x86/sev: Introduce snp leaked pages list Michael Roth
2024-01-08 10:45 ` Vlastimil Babka
2024-01-09 22:19 ` Kalra, Ashish
2024-01-10 8:59 ` Vlastimil Babka
2023-12-30 16:19 ` [PATCH v1 16/26] crypto: ccp: Handle the legacy TMR allocation when SNP is enabled Michael Roth
2023-12-30 16:19 ` [PATCH v1 17/26] crypto: ccp: Handle non-volatile INIT_EX data " Michael Roth
2024-01-18 14:03 ` Borislav Petkov
2023-12-30 16:19 ` [PATCH v1 18/26] crypto: ccp: Handle legacy SEV commands " Michael Roth
2024-01-19 17:18 ` Borislav Petkov
2024-01-19 17:36 ` Tom Lendacky
2024-01-19 17:48 ` Borislav Petkov
2024-01-26 13:29 ` Michael Roth
2023-12-30 16:19 ` [PATCH v1 19/26] iommu/amd: Clean up RMP entries for IOMMU pages during SNP shutdown Michael Roth
2023-12-30 16:19 ` [PATCH v1 20/26] crypto: ccp: Add debug support for decrypting pages Michael Roth
2024-01-10 14:59 ` Sean Christopherson
2024-01-11 0:50 ` Michael Roth
2023-12-30 16:19 ` [PATCH v1 21/26] crypto: ccp: Add panic notifier for SEV/SNP firmware shutdown on kdump Michael Roth
2024-01-21 11:49 ` Borislav Petkov
2024-01-26 3:03 ` Kalra, Ashish
2024-01-26 13:38 ` Michael Roth
2023-12-30 16:19 ` [PATCH v1 22/26] KVM: SEV: Make AVIC backing, VMSA and VMCB memory allocation SNP safe Michael Roth
2024-01-21 11:51 ` Borislav Petkov
2024-01-26 3:44 ` Michael Roth
2023-12-30 16:19 ` [PATCH v1 23/26] x86/cpufeatures: Enable/unmask SEV-SNP CPU feature Michael Roth
2023-12-30 16:19 ` [PATCH v1 24/26] crypto: ccp: Add the SNP_PLATFORM_STATUS command Michael Roth
2024-01-21 12:29 ` Borislav Petkov
2024-01-26 3:32 ` Michael Roth
2023-12-30 16:19 ` [PATCH v1 25/26] crypto: ccp: Add the SNP_COMMIT command Michael Roth
2024-01-21 12:35 ` Borislav Petkov
2023-12-30 16:19 ` [PATCH v1 26/26] crypto: ccp: Add the SNP_SET_CONFIG command Michael Roth
2024-01-21 12:41 ` Borislav Petkov
2024-01-26 13:30 ` Michael Roth
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=20240109122906.GCZZ08Esh86vhGwVx1@fat_crate.local \
--to=bp@alien8.de \
--cc=ak@linux.intel.com \
--cc=alpergun@google.com \
--cc=ardb@kernel.org \
--cc=ashish.kalra@amd.com \
--cc=brijesh.singh@amd.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jarkko@kernel.org \
--cc=jmattson@google.com \
--cc=jpiotrowski@linux.microsoft.com \
--cc=jroedel@suse.de \
--cc=kirill@shutemov.name \
--cc=kvm@vger.kernel.org \
--cc=liam.merwick@oracle.com \
--cc=linux-coco@lists.linux.dev \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=michael.roth@amd.com \
--cc=mingo@redhat.com \
--cc=nikunj.dadhania@amd.com \
--cc=pankaj.gupta@amd.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=pgonda@google.com \
--cc=rientjes@google.com \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=seanjc@google.com \
--cc=slp@redhat.com \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=tobin@ibm.com \
--cc=tony.luck@intel.com \
--cc=vbabka@suse.cz \
--cc=vkuznets@redhat.com \
--cc=x86@kernel.org \
--cc=zhi.a.wang@intel.com \
/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