From: Brijesh Singh <brijesh.singh@amd.com>
To: Borislav Petkov <bp@suse.de>
Cc: brijesh.singh@amd.com, linux-kernel@vger.kernel.org,
x86@kernel.org, kvm@vger.kernel.org,
"Thomas Gleixner" <tglx@linutronix.de>,
"Joerg Roedel" <joro@8bytes.org>,
"Michael S . Tsirkin" <mst@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"\\\"Radim Krčmář\\\"" <rkrcmar@redhat.com>,
"Tom Lendacky" <thomas.lendacky@amd.com>,
"Herbert Xu" <herbert@gondor.apana.org.au>,
"David S . Miller" <davem@davemloft.net>,
"Gary Hook" <gary.hook@amd.com>,
linux-crypto@vger.kernel.org
Subject: Re: [RFC Part2 PATCH v3 02/26] crypto: ccp: Add Platform Security Processor (PSP) device support
Date: Fri, 8 Sep 2017 08:54:17 -0500 [thread overview]
Message-ID: <628e9dbd-77ff-b931-50b1-e72d753612ee@amd.com> (raw)
In-Reply-To: <20170908084009.tb7wzm4j63vhgem4@pd.tnic>
On 09/08/2017 03:40 AM, Borislav Petkov wrote:
> On Thu, Sep 07, 2017 at 05:19:32PM -0500, Brijesh Singh wrote:
>> At high level, AMD-SP (AMD Secure Processor) (i.e CCP driver) will provide the
>> support for CCP, SEV and TEE FW commands.
>>
>>
>> +--- CCP
>> |
>> AMD-SP --|
>> | +--- SEV
>> | |
>> +---- PSP ---*
>> |
>> +---- TEE
>
> I still don't see the need for such finegrained separation, though.
> There's no "this is a separate compilation unit because... ". At least
> the PSP branch could be a single driver without the interface.
>
> For example, psp_request_sev_irq() is called only by sev_dev_init(). So
> why is sev-dev a separate compilation unit? Is anything else going to
> use the PSP interface?
>
I don't know anything about the TEE support hence I don't have very strong
reason for finegrained separation -- I just wanted to ensure that the SEV
enablement does not interfere with TEE support in the future.
> If not, just put it all in a psp-dev file and that's it. We have a
> gazillion config options and having two more just because, is not a good
> reason. You can always carve it out later if there's real need. But if
> the SEV thing can't function without the PSP thing, then you can just as
> well put it inside it.
>
> This way you can save yourself a bunch of exported functions and the
> like.
>
> Another example for not optimal design is psp_request_tee_irq() - it
> doesn't really request an irq by calling into the IRQ core but simply
> assigns a handler. Which looks to me like you're simulating an interface
> where one is not really needed. Ditto for the sev_irq version, btw.
>
It's possible that both TEE and SEV share the same interrupt but their
interrupt handling approach could be totally different hence I tried to
abstract it.
I am making several assumption on TEE side without knowing in detail ;)
I can go with your recommendation -- we can always crave it out later once
the TEE support is visible.
-Brijesh
next prev parent reply other threads:[~2017-09-08 13:54 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-24 20:02 [RFC Part2 PATCH v3 00/26] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
2017-07-24 20:02 ` [RFC Part2 PATCH v3 01/26] Documentation/virtual/kvm: Add AMD Secure Encrypted Virtualization (SEV) Brijesh Singh
2017-09-05 17:21 ` Borislav Petkov
2017-09-05 21:39 ` Brijesh Singh
2017-09-05 22:06 ` Borislav Petkov
2017-09-06 16:41 ` Borislav Petkov
2017-09-06 20:54 ` Brijesh Singh
2017-07-24 20:02 ` [RFC Part2 PATCH v3 02/26] crypto: ccp: Add Platform Security Processor (PSP) device support Brijesh Singh
2017-07-25 8:29 ` Kamil Konieczny
2017-07-25 15:00 ` Brijesh Singh
2017-09-06 17:00 ` Borislav Petkov
2017-09-06 20:38 ` Brijesh Singh
2017-09-06 20:46 ` Borislav Petkov
2017-09-06 21:26 ` Gary R Hook
2017-09-07 10:34 ` Borislav Petkov
2017-09-07 14:27 ` Borislav Petkov
2017-09-07 22:19 ` Brijesh Singh
2017-09-07 23:15 ` Gary R Hook
2017-09-08 8:22 ` Borislav Petkov
2017-09-08 8:40 ` Borislav Petkov
2017-09-08 13:54 ` Brijesh Singh [this message]
2017-09-08 16:06 ` Brijesh Singh
2017-07-24 20:02 ` [RFC Part2 PATCH v3 03/26] crypto: ccp: Add Secure Encrypted Virtualization (SEV) " Brijesh Singh
2017-09-12 14:02 ` Borislav Petkov
2017-09-12 15:32 ` Brijesh Singh
2017-09-12 16:29 ` Borislav Petkov
2017-09-13 14:17 ` Borislav Petkov
2017-09-13 15:18 ` Brijesh Singh
2017-07-24 20:02 ` [RFC Part2 PATCH v3 04/26] KVM: SVM: Prepare to reserve asid for SEV guest Brijesh Singh
2017-09-12 19:54 ` Borislav Petkov
2017-07-24 20:02 ` [RFC Part2 PATCH v3 05/26] KVM: SVM: Reserve ASID range " Brijesh Singh
2017-09-12 20:04 ` Borislav Petkov
2017-09-12 20:24 ` Brijesh Singh
2017-09-12 20:28 ` Borislav Petkov
2017-07-24 20:02 ` [RFC Part2 PATCH v3 06/26] KVM: SVM: Prepare for new bit definition in nested_ctl Brijesh Singh
2017-09-12 20:06 ` Borislav Petkov
2017-07-24 20:02 ` [RFC Part2 PATCH v3 07/26] KVM: SVM: Add SEV feature definitions to KVM Brijesh Singh
2017-09-12 20:08 ` Borislav Petkov
2017-07-24 20:02 ` [RFC Part2 PATCH v3 08/26] KVM: X86: Extend CPUID range to include new leaf Brijesh Singh
2017-09-12 20:12 ` Borislav Petkov
2017-07-24 20:02 ` [RFC Part2 PATCH v3 09/26] KVM: Introduce KVM_MEMORY_ENCRYPT_OP ioctl Brijesh Singh
2017-09-12 20:19 ` Borislav Petkov
2017-07-24 20:02 ` [RFC Part2 PATCH v3 10/26] KVM: Introduce KVM_MEMORY_ENCRYPT_REGISTER/UNREGISTER_RAM ioctl Brijesh Singh
2017-09-12 20:29 ` Borislav Petkov
2017-09-12 20:50 ` Brijesh Singh
2017-09-12 21:08 ` Borislav Petkov
2017-07-24 20:02 ` [RFC Part2 PATCH v3 11/26] KVM: X86: Extend struct kvm_arch to include SEV information Brijesh Singh
2017-09-13 13:37 ` Borislav Petkov
2017-09-13 15:14 ` Brijesh Singh
2017-09-13 15:21 ` Borislav Petkov
2017-07-24 20:02 ` [RFC Part2 PATCH v3 12/26] KVM: Define SEV key management command id Brijesh Singh
2017-09-13 13:45 ` Borislav Petkov
2017-07-24 20:02 ` [RFC Part2 PATCH v3 13/26] KVM: SVM: Add KVM_SEV_INIT command Brijesh Singh
2017-09-13 15:06 ` Borislav Petkov
2017-09-13 16:23 ` Brijesh Singh
2017-09-13 16:37 ` Borislav Petkov
2017-07-24 20:02 ` [RFC Part2 PATCH v3 14/26] KVM: SVM: VMRUN should use assosiated ASID when SEV is enabled Brijesh Singh
2017-09-13 15:37 ` Borislav Petkov
2017-07-24 20:02 ` [RFC Part2 PATCH v3 15/26] KVM: SVM: Add support for SEV LAUNCH_START command Brijesh Singh
2017-09-13 17:25 ` Borislav Petkov
2017-09-13 18:23 ` Brijesh Singh
2017-09-13 18:37 ` Borislav Petkov
2017-09-13 18:58 ` Brijesh Singh
2017-09-13 21:02 ` Borislav Petkov
2017-07-24 20:02 ` [RFC Part2 PATCH v3 16/26] KVM: SVM: Add support for SEV LAUNCH_UPDATE_DATA command Brijesh Singh
2017-09-13 17:55 ` Borislav Petkov
2017-09-13 19:45 ` Brijesh Singh
2017-09-13 21:07 ` Borislav Petkov
2017-07-24 20:02 ` [RFC Part2 PATCH v3 17/26] KVM: SVM: Add support for SEV LAUNCH_MEASURE command Brijesh Singh
2017-09-14 10:20 ` Borislav Petkov
2017-07-24 20:02 ` [RFC Part2 PATCH v3 18/26] KVM: SVM: Add support for SEV LAUNCH_FINISH command Brijesh Singh
2017-09-14 10:24 ` Borislav Petkov
2017-07-24 20:02 ` [RFC Part2 PATCH v3 19/26] KVM: svm: Add support for SEV GUEST_STATUS command Brijesh Singh
2017-09-14 10:35 ` Borislav Petkov
2017-09-14 11:25 ` Brijesh Singh
2017-07-24 20:02 ` [RFC Part2 PATCH v3 20/26] KVM: SVM: Add support for SEV DEBUG_DECRYPT command Brijesh Singh
2017-09-14 11:08 ` Borislav Petkov
2017-07-24 20:02 ` [RFC Part2 PATCH v3 21/26] KVM: SVM: Add support for SEV DEBUG_ENCRYPT command Brijesh Singh
2017-09-14 13:32 ` Borislav Petkov
2017-07-24 20:02 ` [RFC Part2 PATCH v3 22/26] KVM: SVM: Pin guest memory when SEV is active Brijesh Singh
2017-09-14 14:00 ` Borislav Petkov
2017-07-24 20:03 ` [RFC Part2 PATCH v3 23/26] KVM: X86: Add memory encryption enabled ops Brijesh Singh
2017-09-14 14:09 ` Borislav Petkov
2017-07-24 20:03 ` [RFC Part2 PATCH v3 24/26] KVM: SVM: Clear C-bit from the page fault address Brijesh Singh
2017-09-14 14:35 ` Borislav Petkov
2017-07-24 20:03 ` [RFC Part2 PATCH v3 25/26] KVM: SVM: Do not install #UD intercept when SEV is enabled Brijesh Singh
2017-09-14 14:56 ` Borislav Petkov
2017-07-24 20:03 ` [RFC Part2 PATCH v3 26/26] KVM: X86: Restart the guest when insn_len is zero and " Brijesh Singh
2017-09-14 15:40 ` Borislav Petkov
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=628e9dbd-77ff-b931-50b1-e72d753612ee@amd.com \
--to=brijesh.singh@amd.com \
--cc=bp@suse.de \
--cc=davem@davemloft.net \
--cc=gary.hook@amd.com \
--cc=herbert@gondor.apana.org.au \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@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